RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

I've included

QUICK BUILD/TEST INSTRUCTIONS

in addition to a firstrib00.plug that installs the needed Void kernel components for those wishing to use Void Linux kernel/modules etc. It's contents are as follows:

Code: Select all

xbps-install -y ncurses-base linux4.19 linux-firmware-network wifi-firmware shadow
pwconv # set up passwd system
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"

# you can add as many valid commandlines as you want in here

Note that the plugin also sets up default root passwd to simply "root", which you can change later of course.

I just noticed, that sometime since posting above instructions, some time back, on how to make firstrib00.plug to include kernel and set passwd for root automatically, I accidentally over-wrote the associated first-post-provided firstrib00.plug with an old simple one... That may have caused some perplexity to some people trying a build - sorry about that - I have re-uploaded the described firstrib00.plug with the important code in it.

I have also now tested newest build_firstrib_rootfs_100.sh successfully, and currently completed draft of the associated build initramfs script, which I am now testing. All going well I should upload these, with instructions, in a few hours time, or tomorrow if I run into any problems I need to address.

Main change you will have to make yourself aware of is simply the extra commandline arguments you must provide when running the two new build scripts. Otherwise, all should work as before, including firstrib00.plug etc for void flavour firstrib build.

wiak

[rufwoof]

For running in ram a script I've knocked up to create a NNchanges.sfs copy of upper_changes where NN is 02, 03, 04 ...etc generated each time a 'save' is run is ...

Code: Select all

#!/bin/sh
# save.sh

# Create a sfs of upper changes in ram so that changes persist across reboots
# nnchanges.sfs where nn is 02, 03 ... etc.  Starts from 02changes.sfs as
# 01.. filename is reserved for the main sfs layer filename

NEXT=1
for nextlayer in `ls *changes.sfs | sort -V | cut -c1-2`; do
       	if [ "$nextlayer" -ge 0 ]; then NEXT=$nextlayer; fi
done
NEXT=$(expr $NEXT + 1)
NEXT=$(printf "%02dchanges.sfs" $NEXT)  # add leading 0 if 2 to 9
mksquashfs /mnt/layers/RAM/upper_changes $NEXT -comp lz4 -Xhc -e var run mnt

i.e. those 02changes.sfs, 03changes.sfs ...etc. get loaded at bootup so changes are persistent across reboots.

That supports up to 99 saves (no checking of whether it rolls over to 100+), so rather than getting anywhere near that number of NNchanges.sfs files, periodically we might merge them all back to a single 02changes.sfs file using ...

Code: Select all

#!/bin/bash
# merge-changes.sh

# Merge multiple xxchanges.sfs into one (02changes.sfs and all prior NNchanges.sfs
# changes sfs files are removed once merged)

# format of what we're looking to achieve .. (note that c is the lowest (first)
# i.e. should correspond to 02changes.sfs, b is the next lowest (03changes.sfs)
# and a is the highest (04changes.sfs)) ...
#    mount -t overlay overlay -o lowerdir=/mnt/L/a:/mnt/L/b:/mnt/L/c /mnt/L/m
# As we're mounting read only (to create a sfs from) we don't need upper or work
# Note that we mount each NNchanges.sfs to a mount point named the same
# i.e. /mnt/L/NNchanges.sfs, which are all merged into /mnt/L/m ... and
# we use that /mnt/L/m to create the new 02changes.sfs 

mkdir /mnt/L 
mkdir /mnt/L/m
unset lower

for addlayer in `ls *changes.sfs | sort -Vr`; do # sorted in reverse order
	[ -z $lower ] && lower=/mnt/L/${addlayer} || lower="${lower}:/mnt/L/${addlayer}"
	mkdir -p "/mnt/L/$addlayer"
	mount $addlayer /mnt/L/$addlayer
done
sync
mount -t overlay overlay -o lowerdir=$lower /mnt/L/m
mksquashfs /mnt/L/m CHANGES.sfs -comp lz4 -Xhc
sync
umount /mnt/L/m
umount /mnt/L/*changes.sfs  # release all mounted sfs's
sync
rmdir /mnt/L/*changes.sfs
rm -rf /mnt/L
rm *changes.sfs
mv CHANGES.sfs 02changes.sfs

Both save.sh and merge-changes.sh should be stored and run from where your 01firstrib_rootfs.sfs is stored.

Haven't tested it at all other than cursory checks and it runs/produces/loads sfs's OK on my voidlinux kernel based HDD frugal setup.

[rockedge]

rufwoof..... cool script..I'm testing it out

[rufwoof]

Thanks.

Also just uploaded a replacement firstrib00.plug in post http://murga-linux.com/puppy/viewtopic. ... 78#1035078 with much more comprehensive tweaks - such as setting up mc program association/launching and right mouse click in skippy-xd now closes the program/window (left click switches to window). I have reversed the hot corner so that top left now launches xlunch and bottom left launches skippy-xd as unintentional launches tend to more often occur in the top left corner - where xlunch is easier to close (mouse remains near top corner) compared to skippy where the mouse tends to be positioned centrally over a window. i.e. clicking on the background rather than a icon/window for both xlunch and skippy results in the xlunch/skippy window being closed.

Once you're more natural with xlunch/skippy and F1 for terminal (along with mc for file manger), it a alternative desktop combination that works very well IMO.

[wiak]

For running in ram a script I've knocked up to create a NNchanges.sfs copy of upper_changes where NN is 02, 03, 04 ...etc generated each time a 'save' is run is ...

That's nice. I'll also check it out sometime when I have time. New build scripts are working but I'll still tweaking with a few alterations here and there so keep having to do long tests. So should be uploaded hopefully tomorrow.

wiak

[wiak]

LATEST RELEASES ARE:
build_weedog_initramfs05_s207.sh
Previous Release Announcement (21Sept2019) and details remain very relevant:
http://www.murga-linux.com/puppy/viewto ... 92#1037492

build_firstrib_rootfs_104.sh
The earlier release (17Sept2019) details remain very relevant:
http://www.murga-linux.com/puppy/viewto ... 51#1037251
-------------------------------------------------------------------------------------------------------

NEW MULTI-DISTRO WeeDog Release announcement. Currently builds flavours: void, ubuntu, debian, devuan (Arch Linux flavour under development)
where:

distro can currently be one of: ubuntu, debian, devuan, void

release can currently be one of: oldstable, stable, testing, unstable; or xenial, bionic, dingo; stretch, buster, sid; ascii, ceres, beowulf

arch can currently be one of: amd64, i686 (i386 for debian/ubuntu/devuan), arm64 (though build_weedog_initramfs needs modded for arm64 use).
If you plan to boot this via WeeDog initramfs05.gz, then you definitely need to supply a suitable firstrib00.plug_*** in (like the provided exemplars) during the build.

Downloads for the Main Build Scripts are at the foot of current post.

DOWNLOAD locations for some useful build system utilities such as for modifying initramfs and others for facilitating chroot alterations of firstrib_rootfs are at this post:

http://www.murga-linux.com/puppy/viewto ... 57#1028957

DOWNLOAD locations for additional/optional USER-CONTRIBUTED firstrib plugins, utilities and howtos are at this post:

http://www.murga-linux.com/puppy/viewto ... 29#1029029
===============================================

For latest CHANGES, including optional inram00.plug use for zram swap, see here:

http://www.murga-linux.com/puppy/viewto ... 69#1035869

New versions of the two main scripts released. As you'll see some big changes (read the commandline args carefully).

Otherwise works the same though so old void firstrib00.plug should work fine on WeeDog Linux void flavour builds.

It is IMPORTANT to test with the relevant firstrib00.plug_distro_release_arch files attachedl

Note, for grub config, that the initramfs is now model 05. i.e. initramfs05.gz

Also, NOTE WELL that build initramfs no longer uses arg kernel=void, now it simply is <distro_name>, for example: void, ubuntu, debian, or devuan

So much to test and I've only had limited time testing so far, so need lots... Ubuntu proved tricky... turned out needed --no-install-recommends when apt installing its kernel (or ran into lots of trouble with ubuntu updating its own initramfs and grub2 nonsense). Anyway, currently added that option to all debian-based plugin files (though debian and devuan didn't care). Currently devuan using sysvinit, and debian and ubuntu using their default systemd (but you can change that).


Here is quick info on the two new scripts:

Code: Select all

# ./build_firstrib_rootfs_XXX.sh --help

Usage:
./build_firstrib_rootfs_XXX.sh distro release arch [filename.plug] or
./build_firstrib_rootfs_XXX.sh distro release arch [filename.plug.tgz]
NOTE WELL that primary plugin (e.g. firstrib00.plug) is not a script,
it is simply a list of commandlines without any hash bang shell header.
Also NOTE that a tgz (or tar.gz) form of plugin must contain the primary
plugin. It can also contain a plugins directory, which itself contains
other plugins and/or executable scripts. These get copied into 
firstrib_rootfs/tmp so that primary plugin can subsequently source or
execute the plugins dir contents from /tmp/plugins/*
A primaryplug.tar.gz plugin should contain two first level items in its
archive: primaryplug.plug plugins/
For example, firstrib00.plug.tar.gz should contain firstrib00.plug
alongside directory plugins/

-v --version    display version information and exit
-h --help -?    display this help and exit

FOR EXAMPLE: NOTE: I 'think' I tested ubuntu bionic amd64 with WeeDog initramfs, but I've been doing so many tests I can't remember - hopefully fine. I certainly tested debian buster amd64 and devuan beowulf amd64. I did not test any i386 builds (but did build an arm64 firstrib_rootfs, but can't as yet build initramfs for that till I modify the script further with arm64 busybox alternative - anyway, I don't have any arm64 hardware myself)...

Code: Select all

./build_firstrib_rootfs_XXX.sh ubuntu bionic amd64 firstrib00.plug_ubuntu_bionic_amd64

FOR SOME EXTRA DETAILS on build_firstrib_rootfs, see post:

http://www.murga-linux.com/puppy/viewto ... 51#1037251

Code: Select all

# ./build_weedog_initramfs05_s204.sh --help

Usage:
./build_weedog_initramfs05_sNNN.sh [OPTIONS]

-v --version    	display version information and exit
-h --help -?    	display this help and exit
distro_name		(i.e. void, ubuntu, debian, or devuan)
			auto-insert Linux distro modules/firmware into
			initramfs and output associated Linux kernel;
			all of which must be pre-installed into
			firstrib_rootfs build.

Optional second argument is mksquashfs compression (or "default")
Optional third argument is "huge" (or "default") initramfs
"huge" includes 01firstrib_rootfs.sfs inside initramfs/boot/initramfsNN
Optional fourth argument is busybox_url (in case, e.g. arm64 required)

EXAMPLES: 
./build_weedog_initramfs05_sNNN.sh void  # or debian, ubuntu, devuan etc
./build_weedog_initramfs05_sNNN.sh void "-comp lz4 -Xhc"
./build_weedog_initramfs05_sNNN.sh void default huge

Once booted, set up shadow passwords with pwconv and grpconv and
REMEMBER to set: passwd root

FOR SOME EXTRA DETAILS on build_weedog_initramfs05, see post:

http://www.murga-linux.com/puppy/viewto ... 92#1037492

I'm currently just posting the new scripts (along with the importand firstrib00.plug_distro_release_arch exemplars) on this post (consider them alpha/beta) since not tested enough quite yet.

So FirstRib/WeeDog a multi-distro build system now, and will be adding Arch Linux flavour later.

Please let me know how any tests go. Take care not to mix up kernels and plugins and avoid the mistake I made today, which was to forget to delete my upper_changes folder between tests (and left me wondering for hours why my config changes didn't work as I expected!...).

ADDITIONAL INFO

i.e. The optional plugin_name needs to be fourth arg if used.

Note that, for any distro_build (be it ubuntu, debian, devuan, or void), if the plugin name is simply and exactly firstrib00.plug, you do not need to include the plugin name in the build line (though you can if you wish).

You can also of course do the likes of Ubuntu Dingo release:

Code: Select all

./build_firstrib_rootfs_NNN.sh ubuntu dingo amd64 <filename.plug>

and can modify the firstrib00.plug_ubunt_XXX to suit.

Of course, for many of these distro's you can also use alternative arch of i386.

Example grub4dos menu.lst entry:

Examples show using (hd0,0) i.e. /dev/sda1 boot partition of harddrive
Change following to the drive boot partition you are actually using
This example is for slow boot device, hence using optional usbwait value
The bootfrom parameter is required and must be accurate:

For grub4dos
Example shows using (hd0,0) i.e. /dev/sda1 boot partition

Code: Select all

title WeeDog Linux (Multi-Distro-Flavour)
root (hd0,0)
kernel /firstrib/vmlinuzX.XX bootfrom=/mnt/sda1/firstrib # optional changes=RAM copy2ram; optional altNN=path2dir
initrd /firstrib/initramfs05.gz

NOTE (revision s205 plus): If no usbwait parameter given (best) then weedog waits on bootpartition being successfully mounted, otherwise the delay is fixed at usbwait=NN value in seconds.

EDIT. NOTE WELL. The Linux host used for the build DOES NOT need debootstrap or perl installed on it should you be building a debian-based system - I do that all inside firstrib using a specially static uClibc compile of pkgdetails that I made (for debootstrap to not require perl). So should build anywhere, even on small distros like tinycore with nothing much installed on it.

[wiak]

re: my above post. Multi-distro version of FirstRib WeeDog.

I was so busy explaining how to run the scripts for ubuntu, debian, or devuan, that I forgot to say that Void Linux should work as normal too, except you need to give a dummy value for 'release' since it is a rolling distribution.

That is, for build_firstrib_rootfs_100.shm, for Void builds you can use:

Code: Select all

./build_firstrib_rootfs_100.sh void default amd64 <plugin_name>

or even

Code: Select all

./build_firstrib_rootfs_100.sh void rolling amd64 <plugin_name>

ii.e. The optional plugin_name needs to be fourth arg if used.

Note that, for any distro_build (be it ubuntu, debian, devuan, or void), if the plugin name is simply and exactly firstrib00.plug, you do not need to include the plugin name in the build line (though you can if you wish).

You can also of course do the likes of Ubuntu Dingo release:

Code: Select all

./build_firstrib_rootfs_100.sh ubuntu dingo amd64 <filename.plug>

and can modify the firstrib00.plug_ubunt_XXX to suit.

Of course, for many of these distro's you can also use alternative arch of i386.

wiak

[rufwoof]

Newer scripts working fine for me

sda1 hdd based frugal install using grub4dos to boot with menu.lst entry of

Code: Select all

title FirstRib later version of build scripts
   root (hd0,0)
   kernel /VOID/vmlinuz-4.19.68_1 bootfrom=/mnt/sda1/VOID changes=RAM copy2ram
   initrd /VOID/initramfs05.gz

made /VOID folder on hdd

Downloaded my firstrib00.plug.gz script from http://murga-linux.com/puppy/viewtopic. ... 78#1035078 to that folder and gzip -d firstrib00.plug.gz to decompress it (edit it to search for and change the NETWORK section for your ssid and psk along with changing the wireless device name from wlp2s0 with whatever is indicated by running ifconfig).

Downloaded (from post http://murga-linux.com/puppy/viewtopic. ... 24#1035524)
build_firstrib_rootfs_100.sh.tar
build_weedog_initramfs05_s100.sh.tar
firstrib00.plug_void_default_anyarch.tar
also to that folder and renamed each of those to drop the fake .tar suffix, and chmod +x build* ... to make them executable

Created a doit.sh script that I also made executable containing

Code: Select all

#!/bin/bash

./build_firstrib_rootfs_100.sh void current amd64 firstrib00.plug
./build_weedog_initramfs05_s100.sh void

and executed that script. Left it running whilst off doing other things and half hour or so later on checking it had finished and booted/using that now. 01firstrib_rootfs.sfs is indicating 1257MB filesize which IME is reasonably close to a Puppy by the time you also install libreoffice, kdenlive, audacity ...etc.

The latest version of my firstrib00.plug now supports WIN + space and ALT + space invocation of skippy and xlunch respectively. In both cases once launched you can use the arrow keys to navigate to a selection, or <esc> to exit without making a selection. Or continue to use the top left and top right hot corners (clicking on the background and not on a item is like <esc> and closes without doing anything). F1 tilda drop down and running mc for file manager and single mouse click to navigate, double mouse click to run works ok. Sound volume up/down using ctrl up/down arrow key combination. Haven't checked LibreOffice, audacity, kdenlive etc. yet but as they worked before likely they're OK, vlc is certainly working as is chromium.

There are save.sh and merge-changes.sh scripts in the latest firstrib00.plug for creating saves of upper_changes and merging all of those save sfs's back into a single sfs. Both of those scripts are stored in the usual /usr/local/bin folder alongside other scripts such as temp.sh and weather.sh to show cpu temperature and (my local) weather. mc has been set so any file with a .sh suffix will be run when selected. Similarly .txt files are opened in geany, .mp3/.mp4 ...etc are opened in vlc ...etc. (use mc's Command, Edit Extension File to change any file associations as desired).

Note that my setup as outlined above does require 4GB ram in order to fully run in ram. It's also optimised to best fit/run on a 1366x768 laptop layout.

Default passwords for root is 'root' and for user is 'user'. Once logged in run startx (I usually set tilda (terminal) to full screen after startup using F11 and toggle it to show/hide using F1). Mouse into top left corner to see programs, bottom left corner to show current windows. Note that in the windows view (skippy) its been set so left click opens that window, right click closes the window.

xlunch program listings are stored in /etc/xlunch/entries.dsv where the syntax of that content is semi colon delimited values of
program label
program icon
program launch command
i.e.
mtpaint;/usr/share/pixmaps/mtpaint.png;mtpaint

[wiak]

Following my uploaded the new multi-distro build scripts yesterday, I've been taking a rest and doing a bit of WeeDog-related browsing.

In the process I found another interesting new Void-related project here:

https://github.com/LinArcX/VoidConf

(I see you've already noticed it rufwoof).

Useful, also in providing further X-windows-related xbps-install ideas for WeeDog via FirstRib firstrib00.plug since LinArcX provides lists of apps used in its chroot build.

I haven't tried it yet but if it creates a Void root filesystem (I don't know if it does... I guess I should run his script and see - looks like need git installed since clones repo - seems to be a void linux configuration script rather than a rootfs builder though), then of course we can WeeDog-it using build_weedog_initramfs05_100.sh.

It's developer has more interesting stuff at following link:

https://git.sr.ht/~linarcx/

Actually, I must get back to Slackware similarly, since WeeDog provides useful way to create a frugal installation of that too (but first I'm going to research Arch Linux more since I believe its package manager is a good standalone candidate so would work like FirstRib Void, rather than need big skeleton OS download such as done by debootstrap).

Main thing then is always to find a nice root filesystem that WeeDog initramfs can use - utterly simple at the end of the day - no messing around with non-native package managers and so on - might as well let the big development teams do the upstream grunt work I say! Then we can have lots of time free to produce flexible initramfs/init frugal install facilities - a far better use of always too short development time available to us mere humans, in my opinion.

Root filesystems are ready available pre-built - main development task really is the initramfs/init functionality, which defines so much about how the distro behaves in a frugal install configuration, and X desktop build/features/user-space-functionality creation via firstrib00.plug (including creation of user-space utilities, which the members of this forum were once upon a time so very good at - but not so much opportunities in recent years with guarded, complex, Puppy build system). And being designed as a short simple un-convoluted script (unlike so many others), WeeDog initramfs build reveals the simplicity of what often otherwise seems like some black magic mystery, and is easy thus to modify and enhance. Hopefully helps everyone become 'gurus' and thus encourages lots of new developments (and potential new developers) and interesting alternative projects.

EDIT: re-reading, I have to admit, any changes to even simple scripts can often break things(!) so I acknowledge it remains challenging adding new features to anything, hence that old maxim: "'If it ain't broke, don't fix it'". And it's a fact that over time we tend to add more and more and all things become a bit of a jungle, despite our best intentions. Hence, I really hope to not add much more. When things do get too complex, after years of development, I still think it is better to restart with a blank page.

Learning how to use FirstRib build system, is simply a matter of trying it. Short though the scripts are, they do embody a lot of technical knowledge, but all in one place - hopefully, easy to read, google, and understand by those who wish to enhance the WeeDog-initramfs Linux result. Truth to tell, it has been three months of hard work even though the final scripts look so simple - there were actually many an issue to solve to get it into that all-functioning state, but now ready for the pleasant creative part - making individually diverse firstrib00 plugins, please!

Also, looking forward to test reports using the new multi-distro build scripts. Since I'm taking that rest at the moment, I haven't done any further testing myself so any tests from others are much appreciated.

wiak

[rufwoof]

Just tried out using encfs under voidlinux build. That needs encfs to be installed (xbps-install encfs) and also requires fuse, which is already installed under my firstrib00.plug, but the module needs to be activated (modprobe fuse)

Then to create a encrypted folder content

Code: Select all

cd /mnt/sda1
mkdir .testing testing
encfs /mnt/sda1/.testing /mnt/sda1/testing

(I just press enter to accept the 'standard' method and enter a password (twice)

That sets up and opens /mnt/sda1/testing ready for you to store files

When you're done, run

Code: Select all

umount /mnt/sda1/testing

and the folders encrypted access is closed. To reopen again just repeat the
encfs /mnt/sda1/.testing /mnt/sda1/testing
command and enter the password

The .testing folder stores the encrypted versions of files/folders, so just leave that alone.

I had expected there to be problems mixing overlay with fuse, but seemingly not

If you also install yad (xbps-install yad), then creating a script file called testing-open.sh containing

Code: Select all

#!/bin/sh
if [ -d /mnt/sda1/testing ]; then
        modprobe fuse
        PASS1=$(yad --title="Password" --center --entry --hide-text)
        echo "$PASS1" | encfs --stdin "/mnt/sda1/.testing" "/mnt/sda1/testing" -- -o nonempty
fi

and that can be directly run from within mc and a yad prompt for the password pops up. Entering the password and pressing OK and the /mnt/sda1/testing folder is available.

Another script testing-close.sh containing just ...
fusemount -u /mnt/sda1/testing
or even just
umount /mnt/sda1/testing
...will close access to the /mnt/sda1/testing folder content

Most of the data files on my laptop aren't of concern to me if the laptop was stolen. Notes, data, charts ...etc. Some files however contain more sensitive data that if the laptop was stolen would be more of a concern, addresses, personal details etc. and storing those files within a encrypted sub folder is a comfort.

Of course I opted for folder names of .testing and testing in the above, but you'll use folder names of your own choosing (and amend the script code accordingly in reflection of that). Perhaps using a dot name (hidden file) choice for the main folder, perhaps mkdir ..data .data folders instead of .testing and testing. It's nice IMO to have the encrypted folder as a sub folder within your data folder and where there is just those two folders and the two scripts to open/close the encrypted folder - keeps it more altogether.

If you want to change the password at any time then ...

Code: Select all

encfsctl passwd /mnt/sda1/.testing

will prompt you for the current password and then prompt you for the new password.

[rockedge]

I ran a successful run of the latest build scripts for a Void type distro....using the simple firstrib00.plug I posted earlier.

I ran then a "in development" script (set of instructions) to install Hiawatha, mariaDB, PHP 7 and set those up for the following install of the needed PERL modules and clones ZoneMinder from github then complies it. The script is a work in progress and needs modification to truly automate it.

Actually it's easy to manually follow the steps as well.

Strange bug encountered! When running udhcpc -i eth0 it fails and releases the lease and halts. This is the second time I ran across the error

Code: Select all

 /usr/share/udhcpc/default.script: 62: arithmetic expression: expecting primary: "metric++"

which after tracking down the problem I was able to fix with this -> https://lists.debian.org/debian-boot/20 ... 00851.html

Code: Select all

The problem is that dash does not understand arithmetic increment, like
$((metric++)). The attached patch uses metric=$((metric+1)) instead.

weird is I have /bin/sh linked to /usr/bin/bash

Code: Select all

diff --git a/debian/tree/udhcpc/usr/share/udhcpc/default.script b/debian/tree/udhcpc/usr/share/udhcpc/default.script
index d0ffcd7..105bb74 100755
--- a/debian/tree/udhcpc/usr/share/udhcpc/default.script
+++ b/debian/tree/udhcpc/usr/share/udhcpc/default.script
@@ -19,7 +19,8 @@ case $1 in
 
 	    metric=0
 	    for i in $router; do
-		/sbin/route add default gw $i dev $interface metric $((metric++))
+		/sbin/route add default gw $i dev $interface metric $metric
+		metric=$((metric+1))
 	    done
 	fi

which fixed it. I ran across this a couple of days ago and remembered I had stumbled across the fix for my case and used it again, which works great.

I will post the the general zoneminder script/steps in just a few hours after some tests and then figure out what to automate or not. This way anyone interested in building WeeDog (Void) into a camera security / NVR system, can go ahead and set it up easily and experiment or use it for home / business camera security system.

I will be using rufwoof's firstrib.00.plug to create that verison and then run the ZM script on it to see if it will build a LHMP / zoneminder system

here is the script / steps although not quite complete yet.
It builds a web server with Hiawatha, mariadb, php 7.3
with all the PERL modules to compile a zoneminder package
from https://github.com/ZoneMinder/zoneminder

Code: Select all

#!/bin/sh

xbps-install -Suy
xbps-install -y base-devel git cmake python
export PATH=/usr/bin:$PATH

# code to add password automatically
# user = www-data, passwd = admin
useradd -p $5$ZD7UxW8YWCY0j8BG$ywRxCi3QK1p1oi2vA071UIgZ0Vp41/T2fLnoepHp6V1 -s /bin/bash www-data


xbps-install -Sy ffmpeg-devel polkit-devel polkit libmysqlclient libmysqlclient-devel x264 x264-devel
xbps-install -y hiawatha
xbps-install -y mariadb

#start mysqld and set mysql root user
mysqld_safe --user=root &

# Make sure that NOBODY can access the server without a password
mysql -e "UPDATE mysql.user SET Password = PASSWORD('admin') WHERE User = 'root'"
# Kill the anonymous users
mysql -e "DROP USER ''@'localhost'"
# Because our hostname varies we'll use some Bash magic here.
mysql -e "DROP USER ''@'$(hostname)'"
# Kill off the demo database
mysql -e "DROP DATABASE test"
# Make our changes take effect
mysql -e "FLUSH PRIVILEGES"


xbps-install -y libressl libressl-devel 
xbps-install -y perl-YAML
xbps-install -y php-cgi php-apcu php-gd php-mysql xdebug curl

xbps-install -y libjpeg-turbo-devel libjpeg-turbo
xbps-install -y vlc-devel
xbps-install -y libmp4v2 libmp4v2-devel
xbps-install -y gnutls-devel gnutls 
xbps-install -y libcurl-devel libcurl

mkdir /root/Build
cd /root/Build
git clone https://github.com/ZoneMinder/zoneminder.git
cd zoneminder
git submodule update --init --recursive 


cpan install DBD::mysql
cpan install Date::Manip
cpan install LWP::UserAgent 
cpan install Sys::Mmap
cpan install Device::SerialPort
cpan install MIME::Entity
cpan install MIME::Lite
cpan install Net::SMTP
cpan install Crypt::Eksblowfish::Bcrypt
cpan install Data::Entropy::Algorithms
cpan install Sys::MemInfo
cpan install Number::Bytes::Human

cmake CMAKE_INSTALL_PREFIX=/usr  -DCMAKE_SKIP_RPATH=ON  -DCMAKE_VERBOSE_MAKEFILE=OFF  -DCMAKE_COLOR_MAKEFILE=ON  -DZM_RUNDIR=/var/run/zm  -DZM_SOCKDIR=/var/run/zm  -DZM_TMPDIR=/var/tmp/zm  -DZM_LOGDIR=/var/log/zm  -DZM_WEBDIR=/usr/share/zoneminder/www  -DZM_CONTENTDIR=/var/cache/zoneminder  -DZM_CGIDIR=/usr/lib/zoneminder/cgi-bin  -DZM_CACHEDIR=/var/cache/zoneminder/cache  -DZM_WEB_USER=www-data  -DZM_WEB_GROUP=www-data  -DCMAKE_INSTALL_SYSCONFDIR=etc/zm  -DZM_CONFIG_DIR=/etc/zm  -DCMAKE_BUILD_TYPE=Release .
make 
make install

/root/Build/zoneminder/zmlinkcontent.sh
cd /var/cache/zoneminder
mkdir cache
chown -R www-data:www-data /var/cache/zoneminder
ln -s /var/cache/zoneminder/cache /usr/share/zoneminder/www/cache

chown -R www-data:www-data /etc/zm

# check where  sql file is
# it may land in /usr/local/share/zoneminder/db or it should go to  /usr/share/zoneminder/db
# or the "source zm_create.sql" will fail 

cd /usr/share/zoneminder/db
mysql -u root -padmin -e "grant lock tables,alter,drop,select,insert,update,delete,create,index,alter routine,create routine, trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"
mysql -u root -padmin -e "create database new_db; GRANT ALL PRIVILEGES ON new_db.* TO zmuser@localhost IDENTIFIED BY 'zmpass';"
mysql -u root -padmin -e "source zm_create.sql"

missing are the steps to construct the hiawatha.conf and the modification in php.ini needed for time sync and the php module links in the right place.
as is the automation

[wiak]

I ran then a "in development" script (set of instructions) to install Hiawatha, mariaDB, PHP 7 and set those up for the following install of the needed PERL modules and clones ZoneMinder from github then complies it.

Hello rockedge,

Funnily enough I was thinking whilst out driving yesterday how good it would be if you were able to produce a zoneminder-capable firstrib00.plug. I presume zoneminder needs to be compiled on user's local machine to work? Otherwise, you could compile it and make it available for download (e.g. you could open a github account or similar and store the compiled zoneminder there) after which, like in the main build script itself, you could use wget -c, in your firstrib00.plug, to download it to wherever it or its parts needs to be put.

Anyway, good to hear you are finding a way!

wiak

[wiak]

which after tracking down the problem I was able to fix with this -> https://lists.debian.org/debian-boot/20 ... 00851.html

Thanks for that. I haven't had such problems but good to know there is a fix for when it occurs.

wiak

[wiak]

https://lists.debian.org/debian-boot/20 ... 00851.html

Code: Select all

The problem is that dash does not understand arithmetic increment, like
$((metric++)). The attached patch uses metric=$((metric+1)) instead.

weird is I have /bin/sh linked to /usr/bin/bash

I have to say that dash does have it annoying limitations. Busybox ash is funnily enough a lot better in most scenarios; and $((metric++)) works fine with busybox ash. It is however weird you are having the problem when /bin/sh is linked to bash though, since that makes bash the system shell that other apps should be calling internally (e.g. C code system() call uses whatever /bin/sh is), so should be bash the way you have things linked. No idea why patch should be needed in that case.

EDIT: come to think of it, since default.script is a shell script whose header is #!/bin/sh there is no way it should be calling dash when /bin/sh in a link to bash on your system, so $((metric++)) should be fine for that case. However, should be made to work with dash too, so good to simply use metric=$((metric+1)) next line down as you say (since metric++ is post operator, i.e. adds 1 after using).

I'll auto fix that on next build script, thanks.

wiak

[rufwoof]

The more generic
metric=`expr $metric + 1`
runs slower as it starts a separate expr process per increment, but when the number of increments is low, having a script that is more inclined to work if deployed across different shells ???

[rufwoof]

2nd build using the new scripts but with build_weedog_initramfs05_s100.sh patched to mount with size=100% and to mount my sda3 swap partition ...

Code: Select all

--- build_weedog_initramfs05_s100.sh.orig	2019-08-29 22:07:34.784867156 +0100
+++ build_weedog_initramfs05_s100.sh	2019-08-29 22:10:31.740861058 +0100
@@ -145,7 +145,11 @@
 # Create tmpfs in RAM should grub kernel line request copy2ram or changes=RAM
 if [ \$copy2ram -eq 0 ] || [ "\$changes" == "RAM" ]; then
 	mkdir -p /mnt/layers/RAM
-	mount -o mode=1777,nosuid,nodev -n -t tmpfs inram /mnt/layers/RAM # might prefer size limit
+	mount -o mode=1777,nosuid,nodev,size=100% -n -t tmpfs inram /mnt/layers/RAM # might prefer size limit
+	# Rufwoof
+	swapon /dev/sda3
+	mount -o remount,size=13G /mnt/layers/RAM
+	# /Rufwoof
 fi
 
 cd "\${bootfrom}" # where the NN files/dirs and rdshN.plug files are

... so its more stable when running solely in ram/swap.

Video editing (kdenlive, editing a 1 hour long recording) in just ram/swap seems to be working fine

[wiak]

The more generic
metric=`expr $metric + 1`
runs slower as it starts a separate expr process per increment, but when the number of increments is low, having a script that is more inclined to work if deployed across different shells ???

Yes, maybe, but I think it is only the old Bourne shell that can only evaluate maths that way, so recommended patch $((metric+1)) should be fine and who knows some issue may not otherwise somehow crop up with 'expr' ...? Debatable I suppose.

wiak

[wiak]

https://lists.debian.org/debian-boot/20 ... 00853.html

The easy solution is to use $((metric=metric+1)) instead.

[wiak]

2nd build using the new scripts but with build_weedog_initramfs05_s100.sh patched to mount with size=100%

I'll also add the kernel line "option" to set size in next build_weedog_initramfs script.

I'll also create a linked post that contains submitted firstrib00.plug files, or maybe better simply links to where people post them (since I realise such plugins tend to get regularly updated/added-to).

EDIT: Also, a complex firstrib00.plug often needs its creator to provide extra usage instructions, so linking to firstrib00.plug contributions is better. The main scripts have licence MIT, but since the plugins are separate and only sourced if wished. Good if you put header line comments in your plugin to at least author name, revision number, and date them.

I want to give plugin contributions high prominence on this threads main first post since, aside from WeeDog initramfs provided facilities, the final distro behaviour, integration, utilities, and look and feel depends on the plugin created and used.

wiak

[wiak]

First page of thread now contains links, as below to both build script downloads, and also to user-contributed downloads/information, per below:
===============================================

NEW MULTI-DISTRO WeeDog Release announcement. Currently builds flavours: void, ubuntu, debian, devuan (Arch Linux flavour under development)

For downloads, see here:

http://www.murga-linux.com/puppy/viewto ... 24#1035524

distro can currently be one of: ubuntu, debian, devuan, void

release can currently be one of: oldstable, stable, testing, unstable; or xenial, bionic, dingo; stretch, buster, sid; ascii, ceres, beowulf

arch can currently be one of: amd64, i386, arm64 (though build_weedog_initramfs needs modded for arm64 use).

Download locations for additional/optional USER-CONTRIBUTED firstrib plugins:

Please contact me concerning omissions and updates thereafter, wiak

http://www.murga-linux.com/puppy/viewto ... 29#1029029
===============================================