RC7 (STABLE) WeeDogLinux Arch 64 now released

[rufwoof]

Doh! It didn't install cpanminus because for whatever reason my fingers had opted to type cspanminus.

Will try again tomorrow. In the meantime there is always ...

Code: Select all

#!/bin/sh
while :; do
   F=`date +%s`
   ffmpeg -f video4linux2 -s 640x480 -i /dev/video0 -ss 0:0:2 -frames 1 /root/$F.jpg
done

... captures a frame every 2.5 seconds or so, storing it in /root as a .jpg with the number of seconds since 1970 filename. The -ss 2 seconds value of pre video capture before the single frame is recorded is needed if your webcam is like mine and has a fade-in type startup, as without that the image captured is dark.

[rockedge]

added a zmpkg.pl management script here -> zoneminder

[rockedge]

@rufwoof

Glad to report I ran your firstrib00.plug successfully which created an OS that booted correctly and quickly.

I then installed cpanminus

Code: Select all

xbps-install -Sy cpanminus

I created a /root/Build, copied the build_ZM.sh to that directory and I ran it.

after a while the script reported it was finished. I checked that the timezone settings matched in the /etc/php/php.ini with the system clock. And ran
hiawatha
zmpkg.pl start

open Chrome and wow there is was...zoneminder running....I set up one network camera and it is working!

rufwoof's WeeDog with Zoneminder with one net camera is running in 574 megs


So in summary, the build_ZM.sh script ran successfully in 2 differently structured WeeDog's (Void Linux).
these WeeDogs have very different desktop interfaces but the core is similar.

I would say these tests on my end at least have all successfully run and created a running OS and Zoneminder

[wiak]

EDIT: Sorry, had an error on build so withdrew upload and will re-upload once I fix it. Late here unfortunately, so probably tomorrow... Hmmm... it's just a 'spelling error' sigh... I'll re-upload in ten minutes after a retest...

EDIT2: NOT re-uploading, since mount inside chroot is too risky (refer to my next post below as to why).

CANCELLED THIS ONE: Uploaded new build_firstrib_rootfs_102.sh to download post:

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

Code: Select all

Usage:
./build_firstrib_rootfs_XXX.sh distro release arch [filename.plug]
NOTE WELL that the plugin is not a script, simply a list of commandlines
without any hash bang shell header. Also, note that filename.plug can
itself access any plugin, file, or subdir inside the build directory 
via the following variable for access:
"${plugins_dir}" : absolute path to current build directory
For example:  . "${plugins_dir}"/plugin2.plug     # sourcing 2nd plug
              "${plugins_dir}"/mydir/myscript.sh  # running a script

Whilst it was easily possible in previous build rootfs script to mount the build directory from inside a firstrib00.plug, the problem was that someone else using the plugin would quite probably be using a different build partition/directory so the one referred to in the plugin wouldn't work... Hence I instead previously copied firstrib plugin to the firstrib_rootfs/tmp and so was able to access (source it) from there from inside the chroot. But that didn't allow convenient 'chaining' of plugins. So in this new version, the build directory is automatically mounted within the chroot, and firstrib plugin creators can then access that build directory in a non-fixed way, via variable contents: "${plugins_dir}"; the main build script, in other words, now auto-determines what the contents of plugins_dir should be (i.e. depends on where build is started). You can therefore now source other files/plugins and/or run scripts all within your main firstrib plugin.

e.g. inside a firstrib00.plug you might have a line such as:

Code: Select all

...
. "${plugins_dir}"/plugin2.plug
...

which would source that plugin at that point in your firstrib00.plug

or you could run a separate script from within your firstrib00.plug, which can even be in a subdirectory of the main build directory if you wish:

Code: Select all

...
"${plugins_dir}"/mydir/myscript.sh
...

So very flexible now, but hardly been tested... Please let me know if all is well so I can fix it if not. I've only done a quick test using void and amd64, so i386 and debian/ubuntu/devuan not tested (but same features added to all of these and hopefully fine...).

I also added a signal trap so if you ctrl-C during a build the script should automatically cleanup most choot mounts (but you should still check manually thereafter, since it doesn't try to cleanup the mount build_partition also now done later inside the chroot itself).

wiak

[wiak]

Well... I'm frustrated. The script referred to above works, perfectly and flexibly, but I remember now why I didn't previously adopt this 'mount_the_underlying_build partition_whilst_within_the_chroot' method...

Think about it... if during a build you decided to delete directory firstrib_rootfs when underlying partition was mounted 'inside the chroot to that' then you would end up deleting the whole partition (not just the firstrib_rootfs directory). So whilst the method is working and very well and no problem if I leave it to complete the build, that awful and intolerable danger remains. So back to the drawing board, sorry. What a pity.

So, with above in mind, it is not a good idea to mount any build host disk filesystems whilst inside the chroot (despite huge advantages doing so). The current copy of firstrib00.plug to firstrib_rootfs/tmp for use within the chroot, on the other hand, is safe (but not particularly flexible...). Anyway, I'm now instead looking to pass-by-copy other plugins/scripts into firstrib_rootfs/tmp and using them from there, since that is a safe method, rather than risk anyone deleting their system by accident!

What I've decided to do, therefore, is to have the build script copy a plugins directory into firstrib_rootfs/tmp/plugins and you will then be able to safely access anything you have put into there from within the main firstrib plugin script (including other plugins or executable scripts). At the end of the build the main build script will simply automatically delete that firstrib_rootfs/tmp/plugins directory. Simple to modify existing script to do that and also flexible result. I'll try and post that new version tomorrow sometime.

wiak

[rufwoof]

Hi rockedge. ZM build and running for me OK. Know zero about it however and struggling to even get it capturing using my laptops webcam. Did try adding a source of /dev/video0 but not capturing that. i.e. works but my ignorance (need to go off and do some reading up about zoneminder setup/usage).

[rockedge]

rufwoof try to

Code: Select all

chown www-data /dev/video0

as far the webcams go it usually is a permissions issue, with the web server and zoneminder running under some user other than root
WeeDog is among those OS's that we can add the zoneminder user to the video group or at boot run something that will chown

stay with simple configurations and stay with the defaults until you begin to experiment.The following pages are also informative:
https://wiki.zoneminder.comUnderstanding_ZoneMinder's_Zoning_system_for_Dummies

In all cases it is important that the camera resolution (height, width) is correctly configured to what the actual camera output res is.

VLC is excellent for discovering what the true resolutions are. Open the camera stream in VLC and use menu Tools->Codec Information to find the information. This is one reason I included VLC in my firstrib00.plug.

https://forums.zoneminder.com/
https://zoneminder-chat.slack.com

[rufwoof]

Your webcam screenshots were a great help thanks rockedge. After replicating those it worked. Prior to that I was stumbling around in the dark, reading things, trying settings, and on the verge of just giving up.

I did also add www-data to video group and made the chown to www-data userid of /dev/video0 as you indicated.

After having made several saves I ran my merge-changes.sh script and that revealed issues with the code within that (my save.sh also wasn't saving anything under /var which I've also changed as hiawatha and zm both save/use folders under /var), so its screwed up my setup , but at least I know that ZM installs and works outside of that .

[rockedge]

during past attempts of creating remasters of Puppy Linux with a complete ready to go zoneminder installation, /var also was an issue being copied during the process as was the top layer of /etc so none of the current addition of users would also fail to be copied. At some point nic007 created a remaster-experimental that specifically will make a BionicZone remanster that does the trick.

I just did a setup using Bionic32-8.0+12 did nothing but what it takes to install zoneminder from the Ubuntu PPA for it then remastered.....and it actually works..so I will release an Alpha version on another thread.

The ISO is 531 megs : http://rockedge.org/kernels/data/iso/Bi ... +12-ZM.iso

It can be installed in any way a stock Puppy can be installed, including burning the ISO to CD or DVD and running it as a Live OS.

once booted set the timezone to match the system clock in /etc/php/7.2/cgi/php.ini

recommend to restart the mariadb server to sync the system clock with the mysql server with

Code: Select all

killall mysqld
mysqld_safe --user=root &

more details will be in the thread about the remastered BionicZone32

-

[rockedge]

WeeDog (Void) runs Zoneminder at cooler temps and with less cpu loads than Bionic32-8.0+12 does. I notice the fan on this particular Dell laptop will eventually run continuously with Bionic but in WeeDog the fans barely run. This is with the same cameras configured and streaming

I am enjoying rufwoof'd desktop! Runs great and once I got rid of the UK keyboard (the "@" key is totally different!) I was moving along smoothly.
Runs ZM well and once you get used to the basic fundamentals on how the desktop works it is pretty cool

probably should start for WeeDogZM a new thread and also one for the BionicZone32 if there would be any interest in using it.

the best overall on my Optiplex 990 at this point is a 64 bit version of WeeDog using the Void kernel 5.2.14_1 or 5,2,15_1

now going to try a firstrib00.plug that will allow running the build_ZM.sh script once it is booted, that has no X server and is completely run from the shell. I'll add Dropbear and run it as a headless server. See how that looks.......I'll use ./build_weedog_initramfs05_s103u.sh for this test of concept.

P.S. no idea why I am complaining...I used a German keyboard for many years

_

[rufwoof]

I am enjoying rufwoof'd desktop! Runs great and once I got rid of the UK keyboard (the "@" key is totally different!) I was moving along smoothly. Runs ZM well and once you get used to the basic fundamentals on how the desktop works it is pretty cool

Good to know, thanks rockedge.

mc's likely the greatest learning curve part, but once its second nature its quick and flexible.

If for instance you create a .mc.menu in a folder then it will run that when you press F2/menu instead of the default one. This is a good guide http://www.softpanorama.org/OFM/MC/user_menu.shtml for that. With for instance a .mc.menu file in a folder having a content of

Code: Select all

P  Play all mp3 and mp4 files
    vlc *.mp3 *mp4 &

Then pressing F2 will pop up a window offering to play all mp3 and mp4's in the current folder. And of course you can have multiple different menu items in a single .mc.menu file ... and different .mc.menu files in different folders.

One downside of my setting F1 to show/hide toggle tilda does mean that mc's F1 help is in effect unavailable because of that. You either have to redefine the tilda F1 launch key to another key (right click inside a tilda window and select Preferences and then the Keybindings tab, and change the 'Pulldown tilda terminal' option) or search-for/use online mc help.

Fundamentally

F1 for terminal/file-manager (TUI)
Bottom left hot corner for window selector (or WIN + SPACEBAR)
Top left corner for program launcher (or ALT + SPACEBAR)
Ctrl + up or down arrow key for volume level

works well IMO and soon becomes instinctive and very quick to use.

[rockedge]

I used to use Norton Commander on MSDOS in the 80's then I really like and used Total Commander. I still use Norton Commander on DOSBox set ups.
I liked the 2 panel file manger and I can use mc.in the familiar way

[wiak]

Much of this post remains the most informative and relevant, but see the latest release notes in following link for a few extra new changes:

http://www.murga-linux.com/puppy/viewto ... 39#1037639
---------------------------------------------------------------------------------------------------------

build_firstrib_rootfs_102.sh uploaded to usual download post:

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

This new version is backwards compatible with old 101 version. Please always use this new 102.sh version in new builds. Testing appreciated.

CHANGES

You can now chain plugins and run other scripts during build.

You can still use a simple, single firstrib00.plug on its own if you wish, but if you want the extra chaining functionality you should create a firstrib00.plug.tar.gz (or .tgz) file containing two side by side components:

1. The firstrib00.plug file itself (or can use other plugin filename as before).
2. A 'plugins' directory containing other plugins and/or scripts you may wish to be sourced or executed during the build.

Assuming you have these ready, you could create the tar.gz file using command:

Code: Select all

tar czvf firstrib00.plug.tar.gz firstrib00.plug plugins/

You would then start the build with command (void example):

Code: Select all

./build_firstrib_rootfs_102.sh void rolling amd64 firstrib00.plug.tar.gz

The tar.gz file then gets auto-extracted into your firstrib_rootfs/tmp location and the firstrib00.plug file itself gets sourced, as usual, during the build. However you could now add commands, inside your firstrib00.plug, such as:

Code: Select all

. /tmp/plugins/firstrib01.plug  # sourcing plugin firstrib01.plug

which chains-in/sources another plugin (example being firstrib01.plug) at that point,

or, for example, executing an executable shell script called myscript.sh

Code: Select all

/tmp/plugins/myscript.sh

Once the build rootfs has completed, the build script auto-deletes the contents of firstrib_rootfs/tmp. Note that I have also added a trap inside the script such that if you stop a build using Ctrl-C, the errortrap function auto-umounts the chroot mounts that were made, though it is always good to check manually that nothing unwanted is left mounted thereafter.

Here are the build script help notes:

Code: Select all

# ./build_firstrib_rootfs_102.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/

Not much testing done my myself so all tests appreciated. With this new facility, if you want to have unattended WeeDog Linux builds, recommended method is simply to create a small two line wrapper script that first calls: build_firstrib_rootfs_102.sh <chosen_options> and then build_weedog_initramfs05_s103u.sh <chosen_options>

If you encounter any problems please let me know.

EDIT: I'm now also partly through writing the code changes for next build_weedog_initramfs05 script (to allow for alternative locations for NNsfs/dir files, including inside initramfs). One or two bits to check and one or two pitfalls I've thought of that I'll have to consider further and address, but should be fine, I think, once I've done that. Will however be a good few days (assuming nothing else comes up) before I'm likely to complete testing though and thereafter uploading it.

wiak

[rockedge]

Hello!

I used build_firstrib_rootfs_102.sh and build_weedog_initramfs05_s103u.sh along with a firstrib00.plug that is stripped of all the X server and the graphical programs which built quickly and correctly;

I ended up with :
01firstrib_rootfs.sfs of 626556 kilobytes
initramfs.gz with 58972 kilobytes
vmlinuz-5.2.15_1 549616 kilobytes

I booted the OS and it was running in 31 megs of RAM. I added the build_ZM.sh script and ran it in the shell and it completed successfully.
Made the small changes to the hiawatha.conf to reflect the new subnet IP for this machine and started the Hiawatha server, mariaDB (mysql) and Zoneminder.

I opened up firefox on another machine and used http://192.168.0.14/zm and there it was! I configured a net camera and it works!

free -h reports 167 megs of RAM being used!
htop reports 191 megs of RAM in use

these numbers are pretty amazing. Since I did this all while I slept basically, I ran xbps-install -Suy this morning and the updates available where done, and I installed htop

the responsiveness and performance at this point is hard to match and I am running it on a DELL INSPIRON E1505 laptop from 2006 and looking at the ZM web console on a WeeDog-ZM in firefox on an DELL Optiplex 990.

good stuff wiak! looks like the newest version, firstrib_rootfs_102.sh, is running well. I have not tried chaining the plugs yet....next test will be this and it may be fraught with failure until I get the hang of it!

Also I will be adding Dropbear for SSH capabilities to run this WeeDog-ZM-nox headless.

_

[rufwoof]

Hi wiak. Moved all my scripts over to the new plug script format/style and it all built OK (build_firstrib_rootfs_102.sh and build_weedog_initramfs05_s103u.sh)

[rufwoof]

The (function) code snipped I'm using for voidlinux autologin (as root) ...

Code: Select all

_autologin () {
  echo Setting up autologin and auto start X
  cp -R /etc/sv/agetty-tty1 /etc/sv/agetty-autologin-tty1
  echo "GETTY_ARGS=\"--autologin root --noclear\"" >>/etc/sv/agetty-autologin-tty1/conf
  rm /var/service/agetty-tty1
  ln -s /etc/sv/agetty-autologin-tty1 /var/service
  # Above is as per https://wiki.voidlinux.org/Automatic_Login_to_Graphical_Environment
  # however for live-boot that doesn't work alone, we also need to ...
  cd /etc/runit/runsvdir/default
  rm agetty-tty1
  ln -s /etc/sv/agetty-autologin-tty1 agetty-autologin-tty1
  # Auto start X
  cat <<'EOF' >> /root/.profile
# autologin on tty1
if [ -z "$DISPLAY" ] && [ "$(fgconsole)" -eq 1 ]; then
  exec startx
fi
EOF
}

I've also added masterpdfeditor5 to the core set

[Keef]

I've already managed a 32bit build with previous versions, but build_weedog_initramfs05_s103u.sh is not working with the 'void' parameter, to use its kernel.
I get:

Code: Select all

 firstrib_rootfs needs to at least include xbps-install:
linuxX.XX, ncurses-base, and linux-firmware-network,
and optional small extra wifi-firmware.
Or simply install ncurses-base, and template: linux
(which also brings nvidia, amd, i915 and more graphics drivers)

It works without using 'void', but no kernel or firmware of course.

EDIT I've just checked firstrib_rootfs. Kernel is there in boot/ but not in boot/kernel.
If I move it (kernel) to the kernel folder it works then. I'll have to try a previous version again and check if there is a difference that is not just my own doing.

[wiak]

I've already managed a 32bit build with previous versions, but build_weedog_initramfs05_s103u.sh is not working with the 'void' parameter, to use its kernel.
I get:

Code: Select all

 firstrib_rootfs needs to at least include xbps-install:
linuxX.XX, ncurses-base, and linux-firmware-network,
and optional small extra wifi-firmware.
Or simply install ncurses-base, and template: linux
(which also brings nvidia, amd, i915 and more graphics drivers)

It works without using 'void', but no kernel or firmware of course.

EDIT I've just checked firstrib_rootfs. Kernel is there in boot/ but not in boot/kernel.
If I move it (kernel) to the kernel folder it works then. I'll have to try a previous version again and check if there is a difference that is not just my own doing.

Keef, I haven't had any such problems and no other such reports so I suggest you redownload the build scripts in case you have accidentally modified your own copy wrongly. The section of code in build_weedog_initramfs05_s103u.sh that copies the kernel and modules over into initramfs is as follows and you should note that it expects to find the kernel at firstrib_rootfs/boot and NOT at firstrib_rootfs/boot/kernel. Are you sure you have not installed two different kernels into firstrib_rootfs(?) - that would also cause that error I think. If so you need to delete one of the kernels manually. Void will download the current default kernel usually, which is now up to 5.x and no longer 4.19:

Code: Select all

# Modules need to be loaded by initramfs/init if distro_name kernel being used
case "$kernel" in
	void)
		# Copy in Void Linux kernel modules and firmware from firstrib_rootfs,
		# and copy out Void kernel vmlinuz for later copying to /mnt/bootpartition/bootdir
		echo "Copying Void Linux modules to initramfs build. Please wait patiently..."
		cp -af firstrib_rootfs/usr/lib/modules firstrib_rootfs_for_initramfs_sNNN/usr/lib/
		cp -a firstrib_rootfs/boot/vmlinuz* .

		# initramfs/init needs to load sufficient modules to boot system
		_modprobe_modules
	  ;;

Per the following link, to keep the code simple I don't have any logic in the build script to account for possibility the user has installed two kernels in firstrib_rootfs.

http://www.murga-linux.com/puppy/viewto ... 28#1036728

wiak

[rufwoof]

I hit a similar problem a couple of weeks back and indeed it was because I was specifying a kernel version, modifying it to just install 'linux' (meta-package) resolved the issue for me. This is my current install set ...

Code: Select all

xbps-install -y linux base-system shadow xorg xinit xbitmaps \
                terminus-font squashfs-tools alsa-utils jwm \
                tilda mtpaint mc galculator adwaita-icon-theme \
                ccrypt xdotool skippy-xd xlunch bmon iftop \
                calcurse htop ncdu curl chrony xterm geany qt5ct \
                cryptsetup inxi android-file-transfer-linux dbus \
                alsa-plugins dunst inetutils dhclient alsa-tools \
                gvfs polkit usbutils p7zip usbmuxd wireless_tools \
                alsaequal gkrellm yad encfs wkhtmltopdf fzf \
                octoxbps guvcview libreoffice chromium vlc audacity \
                gparted kdenlive ssr master-pdf-editor

[Keef]

Yes it is probably just me. I usually delete everything and start from fresh, but there were two kernels in there for some reason (perhaps I had forgotten the last time).
Anyway, all working well now, apologies for flagging up a non-existant problem.

EDIT - looks like it is definitely because I have a specific (older) kernel identified in the plugin, and the current one is being downloaded too. I'll know to avoid that now.