RC7 (STABLE) WeeDogLinux Arch 64 now released

[rufwoof]

Maybe better would be to simply embed 01firstrib_rootfs inside the initramfs build followed by switch_root to it

That's exactly what my firstrib00.plug is now doing.

Download it (less than 6MB), gzip -d ... decompress it, chmod +x it if necessary; Edit the top section of the file to set your ssid and password and also the password to use for root and user userid's; Then run it with the 'build' parameter

Code: Select all

./firstrib00.plug build

... and go off for a coffee break and return to have vmlinuz and initramfs all ready to go.

I'm using grub4dos menu.lst entry of

Code: Select all

title VOID4
   root (hd0,0)
   kernel /VOID4/vmlinuz-5.2.14_1 bootfrom=/ changes=RAM inram_sz=100% copy2ram
   initrd /VOID4/initramfs05

On first boot, login as root (default password 'root' unless changed as indicated above). At the command line prompt run 'startx'. Once X is running I tend to maximise the tilda terminal window by mousing into that area and pressing F11, thereafter its F1 to toggle showing/hiding that terminal window. If you run demoapp.sh command then that makes terminal life easier (ncurses menu). As before mousing into the top or bottom left corners or using win+space or alt+space ... to show the window manager and program launcher.

If booted from usb, then adding usbwait=12 kernel boot parameter is recommended.

My firstrib plug is all encompassing, all of the scripts build files etc are all contained within itself. Other than needing quite a bit of tidying up that works very well.

Currently the save.sh (and merges.sh) wont work, because it can't store the 02changes.sfs alongside the 01firstrib_rootfs.sfs ... because that's inside the initramfs. Thinking of changing the build scripts so that in addition to bootfrom= another changes= parameter might be included from/to where changes are read/stored. However it would be better if the main (your) scripts were modified to include that rather than having different sets of build scripts. Basically if changes= parameter exists then that device/folder needs to be mounted/accessible and NNxxx.sfs's located there also being layered/loaded in addition to any NNxxx.sfs's in bootfrom= folder location. Or perhaps union joining changes= folder with bootfrom= folder ??

[rufwoof]

Booting with humongous initramfs (main sfs inside initrd) from usb (2.0) and it seems I don't need any usbwait= kernel boot parameter when also copy2ram is being used ... as its all copied into ram anyway

[rockedge]

I need the usbwait for some usb hdd's..they just need time to spool up to speed. Others that do not.

It would be cool if I could use a firstrib00.plug along with a firstrib01.plug and so on and so forth. To make the plug system with easy management and even more modular than it is.

[wiak]

It would be cool if I could use a firstrib00.plug along with a firstrib01.plug and so on and so forth. To make the plug system with easy management and even more modular than it is.

Thinking of changing the build scripts so that in addition to bootfrom= another changes= parameter might be included from/to where changes are read/stored. However it would be better if the main (your) scripts were modified to include that rather than having different sets of build scripts. Basically if changes= parameter exists then that device/folder needs to be mounted/accessible and NNxxx.sfs's located there also being layered/loaded in addition to any NNxxx.sfs's in bootfrom= folder location. Or perhaps union joining changes= folder with bootfrom= folder ??

Okay, I'll look into incorporating both of these. Rufwoof, I tried downloading your plug but seemed to be something amiss at the download site. I'm going out now but will try again later.

EDIT: I need to see what you mean since there is already a changes=parameter, where parameter can be one of:

changes=RAM
changes=readonly
changes=path2dir, where path2dir specifies where upper_changes is to be stored

The above is documented part of current build_weedog_initramfs05 script; as I describe above it certainly worked in previous version but hasn't been tested that I haven't broken its functionality in current version.

EDIT2: I managed to download your plugin now rufwoof, but as I said, I'm just going out, but will look at its contents later. You should say 'busybox tail +25 firstrib00.plug' since normal tail has different options I think. Also I note you are using previous build_weedog_initramfs05_s102.sh (unless I have accidentally mixed up firstrib00.plug files and I am looking at one of your earlier ones). Could you kindly test with latest _s103u since it really needs these tests so I can rename it as stable. Your MAKE via uuencode and doit.sh is an interesting arrangement.

Okay, did quick read of your doit.sh, and see it does, as expected, copying in of 01firstrib_rootfs.sfs and cpio back up again with result the 'huge' initramfs05.gz and so on. I need to think further on your:

Basically if changes= parameter exists then that device/folder needs to be mounted/accessible and NNxxx.sfs's located there also being layered/loaded in addition to any NNxxx.sfs's in bootfrom= folder location.

Currently this part:

Code: Select all

if changes= parameter exists then that device/folder needs to be mounted/accessible

is already in the existing/current build weedog initramfs script. At the moment, as you know, any existing NNfiles are being copied/layered from bootfrom location only; its really the key chunk of code in that build script so I have to be careful not to mess it up. To do what you would like (including NNfiles stored in changes partition) would indeed better being integrated directly into main script routines that does that layering - I will look into that sometime soonish to see how easy/hard/best-way to do it.

wiak

[rufwoof]

Yes changes= ... bad choice of name. Ideally need bootfrom=/ i.e. main sfs is inside initramfs, changes=ram so changes are lost at shutdown, additionals= ... (or whatever choice of parameter name) where additional sfs's are stored and layered when booting i.e. perhaps additional periodic mksquashfs copies of upper_changes so that the changes are persistent across reboots. More usually with the main sfs outside of initramfs 01firstrib_roots.sfs is loaded, then 02somefile.sfs, 03anotherfile.sfs ...etc. sitting alongside 01firstrib_root.sfs also get layered/loaded. But when bootfrom=/ i.e. 01firstrib_rootfs.sfs is inside initramfs then the 02somefile.sfs 03anotherfile.sfs .... need to stored/loaded from another location outside of initramfs

My firstrib00.plug is working with a older version of the build_weedog... script, but using a snippet from that as a example the current code snippet is ...

Code: Select all

cd "\${mountfrom}"  # Since NNsfs_files and NNdirs are there (i.e. bootfrom dir or /mnt/layers/RAM)
lower="";
for addlayer in *; do
        NN="\${addlayer:0:2}" # gets first two characters and below checks they are numeric (-gt
00)
        if [ "\$NN" -gt 0 ] 2>/dev/null; then
                if [ "\${addlayer##*.}" == "sfs" ]; then
                        # layer to mount is an sfs file
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount "\${addlayer}" "/mnt/layers/\$NN"
                elif [ -d "\$addlayer" ]; then
                        # layer to mount is an uncompressed directory
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount --bind "\${addlayer}" "/mnt/layers/\$NN"
                fi
        fi
done

If the main sfs is inside initramfs (so bootfrom=/) and I have a bunch of other sfs's I want layered, then there's nowhere for them to be stored/loaded from as-is ... unless I cpio open up the initramfs and drop them into there alongside the main 01firstrib_rootfs.sfs, which becomes nonviable other than for relatively small/limited filesizes (otherwise initramfs grows to be too large to actually get loaded by BIOS).

Needs a

Code: Select all

lower="";
for loadfrom in $mountfrom $additionals 
  for addlayer in *; do
        NN="\${addlayer:0:2}" # gets first two characters and below checks they are numeric (-gt
00)
        if [ "\$NN" -gt 0 ] 2>/dev/null; then
                if [ "\${addlayer##*.}" == "sfs" ]; then
                        # layer to mount is an sfs file
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount "\${loadfrom}/\${addlayer}" "/mnt/layers/\$NN"
                elif [ -d "\$addlayer" ]; then
                        # layer to mount is an uncompressed directory
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount --bind "\${loadfrom}/\${addlayer}" "/mnt/layers/\$NN"
                fi
        fi
  done
done

type additional loop (untested), so that kernel parameters of bootfrom=/ additional=/mnt/sda1/savesfss changes=RAM ... will have 02changes.sfs, 03changes.sfs stored in /mnt/sda1/savesfss layered on top of the content of 01firstrib_rootfs that is stored inside initramfs. $additionals (such as /mnt/sda1/savesfss) would of course also have to be mounted/accessible.

[wiak]

Yes changes= ... bad choice of name. Ideally need bootfrom=/ i.e. main sfs is inside initramfs, changes=ram so changes are lost at shutdown, additionals= ... (or whatever choice of parameter name) where additional sfs's are stored and layered when booting i.e. perhaps additional periodic mksquashfs copies of upper_changes so that the changes are persistent across reboots. More usually with the main sfs outside of initramfs 01firstrib_roots.sfs is loaded, then 02somefile.sfs, 03anotherfile.sfs ...etc. sitting alongside 01firstrib_root.sfs also get layered/loaded. But when bootfrom=/ i.e. 01firstrib_rootfs.sfs is inside initramfs then the 02somefile.sfs 03anotherfile.sfs .... need to stored/loaded from another location outside of initramf.

Well, changes=parameter does describe its designed purpose, which is to indicate simply where upper_changes would be stored, be it RAM or wherever. And bootfom= does describe where vmlinuz and initramfs location is. The issue is that NNfiles are not themselves changes files (even if they are rollbacks renamed from earlier upper_changes files). Actual changes file always gets loaded in upper rw layer. So, with these rollback files being loaded, as in your scheme, from a different location, provision needs added probably for that, which would not be addressed by changes= but probably I'll create new additional parameter for that need EDIT: since the needs are mutually exclusive: one, changes= to specify where rw layer upper_changes is to be located, and the other ...= to specify alternative/additional location for NNfiles to be loaded into appropriate NN layers. I hope my thoughts there match the facility you need for your merge/save/load utilities.

wiak

[wiak]

I'll also look into a more flexible firstrib00.plug mechanism, rockedge, since it's true that current simple inclusion into chroot's /tmp isn't convenient/flexible when it comes to chaining such plugins.

The more a script can handle general purpose use the more flexible it becomes but making any algorithm more general-purpose is often the hard part... Same in general research, specific case algorithms/theories are relatively easy to implement but absolute all-cases formulas much trickier to devise, and in computing practice some happy-medium compromise is often the best we can get without huge bloat. Still, there remains scope to get nearer to the ideal that would cater for most users' specific ideas whilst allowing for alternative schemes.

wiak

[wiak]

But when bootfrom=/ i.e. 01firstrib_rootfs.sfs is inside initramfs

To help keep the code simple, I'll provide that part of the functionality in subtle alternative way that does not effect existing reserved parameters. I'll used the same method currently already used by the initramfs/init script to determine if a 00firstrib_firmware_modules.sfs is to be loaded (being simply its existence or non-existence). Otherwise I'd really need yet another parameter since bootfrom is essential in telling initramfs/init where the vmlinuz and initramfsXX.gz is.

The method I am implementing is simple - if no 01filesystem is found in bootdir, (where it would generally be required), or in new alternative location for NN{sfs,dir} files, then initramfs/init will load a 01firstrib_rootfs.sfs from the 'boot' directory inside the initramfs itself (if it exists). I'm choosing to use boot subdirectory rather than / to account for possibility of chroot version of WeeDog initramfs also being developed further, in which case it wouldn't be 'tidy' to have 01firstrib_rootfs.sfs sitting in main / location, but boot subdir is fine since that's appropriate to when it is used.

EDIT1: For the sake of separation will actually use /boot/NNstore. Also, whilst I think 01firstrib_rootfs.sfs enough in initramfs, I plan to make it a user decision how many NNsfs in there and also to again allow any NN value for firstrib_rootfs there too. That way users have full control over which layers to put read-only items in.

EDIT2: Rather than use "if it exists" logic (as explained before) I instead hope to allow external copies of NNsfs files to override initramfs contained versions. I have been working on that implementation this evening and so far it is looking good in terms of not much extra code required whilst offering fullest flexibility in terms of usage. The next paragraph is thus now a bit behind actual progress, though if my current plan becomes too complex to finalise I may compromise on scope of that flexibility whilst still allowing for the various specific needs already discussed.

The reason I say "if it exists" is, if you remember, the system is already more flexible generally than to 'require' the firstrib_rootfs to always be at layer 01: you can in fact use any layer for NNfirstrib_rootfs, which allows for possibility you might want some sfs below it and some above it. Layer 01 is of course the lowest layer, and the layer 'normally' used for firstrib_rootfs in practice. So, if no 01firstrib_rootfs (sfs or dir) found in bootdir or in initramfs then that's fine; but of course it would then have to be provided but with some other NN value for placement in that other NN layer position. I don't think it would be good to include more than 01firstrib_rootfs in the initramfs for the reason you touched upon concerning the end-size/loading-time and more of the resultant 'huge' initramfs, but I will consider that matter further to see how general-purpose I can make the modified load-layer algorithm without bloat.

Anyway, working on all that and more - such alterations will take some time and mega further testing of course. I'll report progress now and again as I get on with that (sooner or later). Such algorithms can end up appearing nice and simple-looking (and surprising flexible) 'in the end', but that end simplicity hides the amount of consideration (and oft-flawed attempts) that go into finding something reasonably satisfying (with alas many a kernel panic inbetween...).

One thing I'm not prepared to do is to destroy the simplicity in FirstRib/WeeDog build system. It woud be relatively easy to add functionality via hacking-in extra-logic/functions/external-files and so on, without caring about the resultant extra bloat. However, it is not so easy to increase functionality whilst endeavouring to keep the code simple to read and follow whilst endeavouring to improve its overall efficiency and flexible functionality, so that end-apparent-simplicity actually needs a lot more careful consideration and takes longer thus to code. But that's what I will try to do. I've still to further consider firstrib00.plug implementation, but will come up with something to allow easier chaining of that too.

wiak

[rufwoof]

Nice idea wiak!

I've been building with the 3u build script and that all seems to be working for me, with the exception that if I do put 01firstrib_rootfs.sfs inside the initramfs and use bootfrom=/ ... then it crashes on bootup. Other than that and its building my firstrib00.plug fine

[wiak]

It would be cool if I could use a firstrib00.plug along with a firstrib01.plug and so on and so forth. To make the plug system with easy management and even more modular than it is.

I'll also look into a more flexible firstrib00.plug mechanism, rockedge, since it's true that current simple inclusion into chroot's /tmp isn't convenient/flexible when it comes to chaining such plugins.

Actually I hadn't looked at how to chain firstrib plugins before so took a quick look tonight and no longer agree with my own statement above: it is actually relatively easy to do as things stand. One problem is the surprising one of how to determine partition the current directory is in. You might think pwd command would do the job but you can't rely on that. For example, if in /mnt/home in a DebianDog, pwd command just says /mnt/home, which does not therefore reveal current dir (/mnt/home on DD is a symlink to actual /mnt/partition where booted from).

There is also a problem that opening terminal at partition booted from on Dogs results in something like /mnt/live/mnt/sda5 rather than simply /mnt/sda5 (assuming booting from sda5). This complicates matters further.

I think I have solution to above. I'll come back to this tomorrow since late now. Once I have that simple matter determined from script point of view, chaining firstrib plugins is easy to do.

wiak

[wiak]

Progress report:

Working on build rootfs firstrib plugin changes first, since easier and less to test. I hope to post new build_firstrib_rootfs script within a day from now if not earlier. All going well, should be no limit in plugin scripts that can be sourced.

EDIT: There will be a delay of a day or two. My partner was given a relatively modern laptop she needs OS installed on. It had been Windows 10 booting via secure UEFI but the Windows account was removed... I know/knew nothing about UEFI since always used old machines......
Anyway, to cut a long story short, in my usual fashion, I removed all Windows and repartitioned the hard drive, used a BionicDog64 iso to install grub4dos in MBR and tried a quick frugal install of that Dog. Oops, wouldn't even think about booting (no matter Legacy Mode, Secure Boot off, or whatever...). Luckily I could still (with effort) boot from usb. So after hours of reading up on UEFI, I understood I needed GPT partitioning scheme, so read up on that, and then installed gdisk and partitioned with first small 100MB partition of efi sort required and rest linux ext4. But still didn't know how to get BionicDog64 booting... Oh well, I thought, if any Linux distro I know is likely to sort this out for me, it is likely to be pristine Ubuntu install iso. So I downloaded that (2GB) and dd'd it to a usbflash stick and after setting BIOS to UEFI native again, I tried installation, and it worked... thank goodness. My partner may want to keep Ubuntu (the machine is fast and powerful enough, and it has a touch screen) or maybe, I expect, I can now install other distros frugally on same partition (I am familiar with grub2 configs). So maybe back to FirstRib WeeDog developments some time tomorrow...

EDIT2: Success... dual-booting full Ubuntu install with BionicDog64 frugal install now. Could put WeeDog on here now... HP Elitebook Folio 1020 G1

wiak

[rockedge]

Hello wiak, (can you please test this)

Successful run of a ZoneMinder build script in a Void Linux WeeDog built from a firstrib00-32.plug and a firstrib00-64.plug.


Using these 4 files:

Code: Select all

build_firstrib_rootfs_101.sh
build_weedog_initramfs05_s103u.sh
firstrib00-64.plug
build_ZM.sh

Download here -> weedog-ZM scripts & build_ZM.sh

I created a directory in a boot partition called weedog-zm and copied these

build_firstrib_rootfs_103.sh
build_weedog_initramfs05_s203.sh
firstrib00-64.plug

used a small script to run both scripts and create WeeDog
run_all.sh (64 bit)

Code: Select all

#!/bin/sh
./build_firstrib_rootfs_101.sh void rolling amd64 firstrib00-64.plug
./build_weedog_initramfs05_s103u.sh void

run_all.sh (32 bit)

Code: Select all

#!/bin/sh
./build_firstrib_rootfs_101.sh void rolling i386 firstrib00-32.plug
./build_weedog_initramfs05_s103u.sh void

set up menu.lst for Grub4Dos double check that the correct vmlinux-XXX_1 is configured

Code: Select all

title weedog-zm (Void Linux)
  root (hd0,0)
  kernel /weedog-zm/vmlinuz-5.2.14_1 net.ifnames=0 bootfrom=/mnt/sda1/weedog-zm
  initrd /weedog-zm/initramfs05.gz

the network connection is set to use eth0
change this in the firstrib00.plug or manually change after boot. eventually I will add a mechanism to choose either eth0 or wlan

Now booted into the new weedog-zm logged in then started the desktop with startx and on the safe side opened a terminal and did:

Code: Select all

xbps-install -y cpanminus

I copied build_ZM.sh to /root/Build and changed into that directory "cd /root/Build"

open a terminal and run the script ./build_ZM.sh

after the script is finished you should see :

Code: Select all

All done
done setting up ZoneMinder and the LHMP....

open /etc/hiawatha/hiawatha.conf and go into the virtualhost block and modify the block for the LAN address to match yours subnet IP (i.e. 192.168.0.13)

open a terminal type

Code: Select all

hiawatha
zmpkg.pl start

run firefox and open http://localhost/zm

please refer to zoneminder docs for further information.

Downloads of the files are here
https://github.com/techrockedge/weedog-ZM

[rockedge]

ZoneMinder default user=admin passwd=admin

WeeDog user=root passwd=root
zoneminder configuration files are here -> /etc/zm
zoneminder database .sql are here -> /usr/local/share/zoneminder/db
main zoneminder web console components are here -> /usr/share/zoneminder/www
Error logs are here -> /var/log/zm

start Hiawatha -> hiawatha
stop Hiawatha -> killall hiawatha
starting and stopping zoneminder ->
Usage: zmpkg.pl {start|stop|restart|status|logrot|state|version}
starting mysql -> mysqld --user=root
stopping mysql -> killall mysqld


zoneminder documentation -> https://zoneminder.readthedocs.io/en/stable/

zoneminder github -> https://github.com/ZoneMinder/zoneminder

ZoneMinder web site -> https://zoneminder.com/

Hiawatha server -> https://www.hiawatha-webserver.org/

Hiawatha server manual -> https://www.hiawatha-webserver.org/manpages/hiawatha

Hiawatha How-To -> https://www.hiawatha-webserver.org/howto

Here is a script to easily manage start,stop,status,restart of ZM. Place it in
/usr/local/bin/zoneminder and

Code: Select all

chmod +x /usr/local/bin/zoneminder

Code: Select all

#!/bin/sh
### BEGIN INIT INFO
# Provides:          zoneminder
# Required-Start:    $network $remote_fs $syslog
# Required-Stop:     $network $remote_fs $syslog
# Should-Start:      mysql
# Should-Stop:       mysql
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description:  Control ZoneMinder as a Service
# Description: ZoneMinder CCTV recording and surveillance system
### END INIT INFO
# chkconfig: 2345 20 20

# Source function library.
#. /lib/lsb/init-functions

prog=ZoneMinder
ZM_PATH_BIN="/usr/local/bin"
RUNDIR="/var/run/zm"
TMPDIR="/tmp/zm"
command="$ZM_PATH_BIN/zmpkg.pl"

start() {
	echo -n "Starting $prog: "
	export TZ=:/etc/localtime
	mkdir -p "$RUNDIR" && chown www-data:www-data "$RUNDIR"
	mkdir -p "$TMPDIR" && chown www-data:www-data "$TMPDIR"
	$command start
	RETVAL=$?
	[ $RETVAL = 0 ] && echo success
	[ $RETVAL != 0 ] && echo failure
	echo
	[ $RETVAL = 0 ] && touch /var/lock/zm
	return $RETVAL
}
stop() {
	echo -n "Stopping $prog: "
	#
	# Why is this status check being done?
	# as $command stop returns 1 if zoneminder
	# is stopped, which will result in
	# this returning 1, which will stuff
	# dpkg when it tries to stop zoneminder before
	# uninstalling . . .
	#
	result=`$command status`
	if [ ! "$result" = "running" ]; then
		echo "Zoneminder already stopped"
		echo
		RETVAL=0
	else
		$command stop
		RETVAL=$?
		[ $RETVAL = 0 ] && echo success
		[ $RETVAL != 0 ] && echo failure
		echo
		[ $RETVAL = 0 ] && rm -f /var/lock/zm
	fi
}
status() {
	result=`$command status`
	if [ "$result" = "running" ]; then
		echo "ZoneMinder is running"
		RETVAL=0
	else
		echo "ZoneMinder is stopped"
		RETVAL=1
	fi
}

case "$1" in
'start')
	start
	;;
'stop')
	stop
	;;
'restart' | 'force-reload')
	stop
	start
	;;
'status')
	status
	;;
*)
	echo "Usage: $0 { start | stop | restart | status }"
	RETVAL=1
	;;
esac
exit $RETVAL

use it like this ->

Code: Select all

bash-5.0# zoneminder
Usage: /usr/local/bin/zoneminder { start | stop | restart | status }

example:

Code: Select all

bash-5.0# zoneminder status
09/16/2019 16:18:12.023741 zmpkg[11939].INF [main:310] [Sanity checking States table...]
09/16/2019 16:18:12.057970 zmpkg[11939].INF [main:95] [Command: status]
ZoneMinder is running

_

[rockedge]

any one who tests please check the build_ZM.sh script over and make changes where it fits.
the script can be also be done manually in a terminal or just used as a guide

let me know if anyone has any success....

if it works I will start a new thread for the WeeDog plug and build_ZM.sh script

[wiak]

Hello wiak, (can you please test this)

Successful run of a ZoneMinder build script in a Void Linux WeeDog built from a firstrib00-32.plug and a firstrib00-64.plug.

That's great rockedge. You've been very busy I see. I'll download and give it all a try. (Just finishing off installation job on my partners machine and after that will be back to FirstRib/WeeDog work). I'm excited to try out Zoneminder.

wiak

[rufwoof]

Sorry rockedge, been busy tidying up and adding/changing things in my own firstrib http://murga-linux.com/puppy/viewtopic. ... 78#1035078

Program launcher (mouse into top left corner or alt-space) has a few more programs now, ssr ...etc.


(clickable thumbnail)

The installed android file transfer works OK, but I might swap that out for something else as its not as intuitive as I'd like.

I've stuck to the single file setup, where wiaks scripts are all integral to that i.e. just run "./firstrib00.plug build" ... and it does all the rest (output is the vmlinuz, initramfs and main sfs (01firstrib_rootfs.sfs) all ready to add to menu.lst (grub4dos).

I do intend to get around to trying/testing yours however over the next couple of days and will report back.

[wiak]

Hello wiak, (can you please test this)

Successful run of a ZoneMinder build script in a Void Linux WeeDog built from a firstrib00-32.plug and a firstrib00-64.plug.


Using these 4 files:

Code: Select all

build_firstrib_rootfs_101.sh
build_weedog_initramfs05_s103u.sh
firstrib00-64.plug
build_ZM.sh

Building it per your instructions right now rockedge. Will report back later. Also started work on improving firstrib00.plug handling (to allow easy chaining) - new version for that build rootfs shouldn't be too far away. Thereafter will get back to new build initramfs script which, as I described previously, will also account for huge initramfs builds.

Meanwhile rockedge zoneminder firstrib plug build config scripts buzzing away doing their job preparing things whilst I'm typing this and generally relaxing...

wiak

[wiak]

Congratulations rockedge. That system is great!

Well... I don't actually have monitor working yet, but I'm talking about the build itself. Took ages on my slow rural broadband, but whole build completed fine by following your instructions. Did have a couple of minor glitches (basically caused by myself):

I build the basic system using the build rootfs and build initramfs with the firstrib00.plug, but didn't realise I was to use ethernet connection on booting it... (you should mention that in case someone else dumb like me tries it).

Of course I had to do a chmod +x on the downloaded build_ZM.sh script (no problem there). Wow, it was fascinating watching that in action - so much stuff done till it reached the All done message (I really doubted after so much going on it could possibly be okay...). Then I was daft again:

I went to /etc/hiawatha and edited hiawatha.conf. However, I forgot your system had X and geany and so on, so I used vi to do the editing... sigh... oh well, that was fine - I have (basically) used vi many times... and changed the IP to that of my machine (I determined that using command "ip address").

Then I ran the: hiawatha; zmpkg.pl start

It was then I read you next instruction to use firefox (which is when I realised I hadn't needed to use vi!!!...). So did a startx, and ran firefox and opened url http://localhost/zm

and there it was! Zoneminder Console and so on. I also clicked on the link to Zoneminder Documentation and read some quick start stuff. Anyway, long story short - I added a monitor: Local and /dev/video0 and went for 640x480 hoping to capture from machines webcam. Alas, when I clicked on the Monitor-1, ZM said that monitor wasn't capturing so couldn't display images... Oh well - close enough for now - I'm sure just something I need to do and will know doubt work it out after reading more ZM docs.

Looks like a great system. Just using a bit over 500MB RAM on my system and running very efficiently more generally.

Any pointers or likely reason webcam didn't display would be appreciated. I should manage to work it out - afterall I did write pAVrecord once upon a day (and weX) later and they all used /dev/video0 (along with ffmpeg).

Anyway, I see what you mean about your need to chain plugins. Good news is that the next version I talked about will allow you to fully automate the whole thing since you will be able to access whatever config scripts you wish in your plugin(s). I'll get on to working on that tomorrow (late here now).

Many thanks for that zm build - I'll keep that one for further experiments with ZM. It certainly makes an easy way to build a custom and very efficient/full-featured Zoneminder Surveillance system. (I'm hoping to use an old android phone as a simple IP camera - I did used to use an old B/W video camera, with capture card with simple 'Motion' vid surveillance program, but no longer have that camera orold desktop PCI capture card).

wiak

[rockedge]

Hello wiak,

glad it worked! You can see it is somewhat involved to create a working version. The documentation needs a lot of work and there is much more in docs for zoneminder, I only listed the one source and only made the briefest instruction set.

I would recommend building the WeeDog then booting and login use "startx" then running the build_ZM.sh

In the folder "applications" there are .desktop files for pmcputemp and retrovol...a simple click will start those 2 programs and they will appear on the jwm tray. Eventually I will add a mechanism that will give the option to auto start those 2 programs. The desktop also features midnight commander so "mc" will work in any shell or terminal. I use the mc editor instead of vi. Or use geany or leafpad which are both present as are viewnior and xarchive....which I just use rox to "Set run action" to associate tar.gz or .zip and which ever to xarchive and the image files to viewnior so when I click on them they open up.

Now as far as your web cam goes it usually occurs when the user www-data has no rights to /dev/video0....so in a terminal try:

Code: Select all

chown www-data /dev/video0

also add www-data to the video group by:

Code: Select all

usermod -a -G video www-data

this should eliminate the need to chown every time on /dev/video*

then in the camera configuration window use "save" again to restart the camera.
But as always the ZM's "Log" menu option will help. Plus I added the xdebug PHP module that is a powerful PHP debugger for those who want to really jump into the machinery.

the firstrib00.plug creates a desktop for many uses and is intended for any user to look it over and modify and improve it as well as the build_ZM.sh script.

I need to add a WLAN option so I most likely will "borrow" rufwoof's script code or yours for the WiFi connections.

Also the ability selecting the root password, network connection and which mounted partition is displayed on the rox pinboard at startup could use some refinement.

But as keeping with the spirit of the project I leave a lot of choices and setup to the individual user and attempt to keep it simple enough to follow so others can modify and improve the scripts and plug. The desktop is pretty basic but all the tools are there to really make a full featured use it everyday desktop or a specialty system built for a specific purpose.

The system is such that this is possible for anyone willing to try it out and be successful...enough to brave charting their own course and experiment or those just interested in having a really powerful camera security system with network video recording across multiple servers if required.

now I need to make some documentation to at least add some trouble shooting tips but I am not straying far from standard Void Linux stuff to keep this in line with all the documentation that exists already.

@rufwoof I am about to embark on a setup using your firstrib00.plug and build system...and then try to run the build_ZM.sh script in that!!! should be cool...I would like to show the developers of ZoneMinder a working system using your creation. This is more for the home user with just a few cameras and older machines....most commercial applications of ZoneMinder involve hundreds of cameras and run on Ubuntu servers headless.

any way rufwoof I like the ideas of your desktop and want to mess around with it to write documentation as a reason to do it.

thanks for the test wiak and definitely try to chown the /dev/video0 to www-data


_

[rufwoof]

The desktop also features midnight commander so "mc" will work in any shell or terminal. I use the mc editor instead of vi. Or use geany or leafpad which are both present as are viewnior and xarchive....which I just use rox to "Set run action" to associate tar.gz or .zip and which ever to xarchive and the image files to viewnior so when I click on them they open up.

Been otherwise preoccupied today, so haven't yet started with your build. Out again shortly so hopefully if I'm home early enough will be able get going with that later today.

I set mc to use both the Open and View options for a range of file types, for instance for mp3 Open will open it in vlc, whilst view opens it in audacity. In other cases I just use the command line, i.e. navigate to highlight a particular file and action it using the mc command line using %f as the substitute for the filename. i.e. if over "somefile" then on the mc command line geany %f opens that file in geany. On the command line you can use the usual tab completion, but you do have to press the <esc> key beforehand. Do that twice <esc><tab><esc><tab> and it presents a full list of all possible autocomplete choices.

In mc editor if you press shift before making a mouse drag selection then that uses the standard clipboard buffer (otherwise it uses the mc' internal buffer).

I was raised on vi so often use that, but mc and its internal editor are great. But for multiple files and much movement I use geany.

mc automatically opens tar files in the pane, so you can just copy files as usual using F5 (copy).