Puppy Linux Discussion Forum

So been quite a flurry trying out weedogging a number of upstream distros, some working out of the box, some needing a greater or smaller number of tweaks of course. I'm surprised the Internet hasn't slowed down from all the extra bandwidth being used (my rural copper-wire household broadband certainly almost fell to its knees with my other family members asking me to release some bandwidth for their youtube viewing demands...).
So lots to get on with - pick a distro - try it. Like rockedge, I continue to recommend Void Linux, though Arch-based is my personal mainstay, for various reasons.

I'm taking a break now (been almost too hectic/exciting - i must be getting too old - feeling tired out), except I'll look out the associated utility scripts and main two basic build scripts and get back to re-assembling the old github pages with the latest for those who want these further experiments.

NOTE: Yes, there are NO good docs on WDL overall. Somebody needs to write the book. There is plenty to write about beyond the WDL skeleton initrd kit.

wiak

wiak wrote: ↑Wed Sep 08, 2021 11:05 am

NOTE: Yes, there are NO good docs on WDL overall. Somebody needs to write the book. There is plenty to write about beyond the WDL skeleton initrd kit.

But there is the quick 'cheat cheat' under WeeDog -> HowTos here also:

viewtopic.php?f=168&p=36426#p36426

Muchos Luck.

wiak wrote: ↑Tue Sep 07, 2021 11:47 am

dancytron wrote: ↑Tue Sep 07, 2021 11:05 am

wiak wrote: ↑Tue Sep 07, 2021 4:59 am

Oh I see. Nice to know and experiment with anyway. Should be able to make an actual arm Rasp PI WDL boot by substituting in arm busybox and arm modules/kernel and arm-compiled rootfilesystem components, but I won't know till I have such a system to try it on.

I've messed around with it to see what they are using to teach programming to kids more than anything else.

I'll see if I can get the ram mode 2 and savetoflash rsync thing working.

Is there any way to "remaster" or merge the changes folder with the .sfs file (mainly to uninstall some stuff to make it a more manageable size)?

Actually Fredx181 wrote a small remaster script for it long time back. May or may not need slight modification now. I'll have to look it out and report back once I find it. Off the top of my head, the resulting filesystem in /mnt/layers/merged should pretty much be the remaster required straight away now (though maybe I'm not thinking straight it being late at night here). However, you'd want to --exclude some stuff not required in the remaster. Anyway, I'll look for the remaster script Fred contributed way back. That probably used a separate temporary overlayfs just to collect all the pieces together before excluding bits and applying mksquashfs.

EDIT: just found it, but don't have time to check if will work. I remember reading it back after it was submitted, but didn't have time to test back then either and it is possible that a few things now need changed. Maybe I'll look at it again later. Attached in original form here anyway (just remove dummy tar and chmod +x and use at own risk...).
EDIT2: Just had a quick look at that old script. I believe it was for early WDL_Arch64 so not sure how many alterations it would require (definitely need the script internal 01firstrib_rootfs changed appropriately and more besides). Might be useful to someone though. Sorry I'm not able to look into making it work myself in near future.

I took a look at Fred's script. Modifying that is beyond my ability/amount of time I have to figure it out.

I think I'll make an sfs out of the changes folder instead and then try the rsync save from ram.

dancytron wrote: ↑Wed Sep 08, 2021 12:42 pm

I took a look at Fred's script. Modifying that is beyond my ability/amount of time I have to figure it out.

I think I'll make an sfs out of the changes folder instead and then try the rsync save from ram.

Yes, I don't have time (or inclination) to attempt any script modifications at the moment either, but I think the sfs out of changes folder and rsync saves is a good strategy. I think there could be alternative way to remaster but not something I'm thinking further about just now really.

wiak wrote: ↑Tue Sep 07, 2021 11:21 pm

fredx181 wrote: ↑Tue Sep 07, 2021 5:08 pm

Here's a way to create a much smaller initrd, attached cr-initrd script that I made.
cr-initrd.gz
Code for copying only required kernel modules to the initrd (for booting) taken (but modified) from "initramfs_create" script by Tomas M <http://www.linux-live.org/>

That's great Fred! Improves matters greatly and actually a weight off my mind.

I was always planning to implement that same Thomas M method after the suggestion forum member gumanzoy made to you to some months back (below link),
....
....

Great that it works for you too. Yes, I read here and there you had the idea of implementing the Tomas M method, for me it wasn't very difficult to modify it to work with WDL.
Actually, a few years ago I already experimented with it for DebianDog, tested by rcrsn51 on several hardware and worked on most but not on on all.
Member gumanzoy recently stimulated to try it again and test results from rcrsn51 were positive to work on all hardware he tested.

As for the boot WDL slow down you were experiencing - I don't myself think the size of the modules swelling the initrd has much importance in terms of that (slight delay to load 100Mb initrd) but I've always thought that loading unneeded modules might cause such issues from time to time - was just living with it for now (i.e. waiting for the time-outs...) - of course that matter is better to be addressed properly.

A bit mysterious why the slimmed down initrd makes such a big difference for me in loading time at start of boot (more than a minute with the large initrd vs. just a few seconds it takes with the small initrd).

Ok, keep up the good work, but take it easy, don't get a burn-out

EDIT: A few more modules gumanzoy and me added to the Tomas M code, one of them is: copy_including_deps /$LMK/kernel/crypto
I added it for support of encrypted savefile, if not needed for WDL, comment it out and the generated initrd will be even smaller.

Fred

@wiak I finally got Zoneminder installed and working on a WDL_manjaro-xfce!

In a root owned terminal first I installed Hiawtha, and PHP 8 with pacman on the command line. Followed by mariadb then initialized the mysql database.

mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql 2> /dev/null

To test out the mysql server (mariadb) I set the root password, created a new user and password for zoneminder's database. Then created a database called zm and initialized the tables with an import with zm_create.sql

mysql -u root -p < /usr/share/zoneminder/db/zm_create.sql
mysql -u root -p -e "grant select,insert,update,delete,create,drop,alter,index,lock tables,alter routine,create routine,trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"

All of these steps were done in a root owned terminal.

I used pacman to install the base-devel, git , cmake packages. Then installed yaourt which uses the Arch AU repos to install Zoneminder. This takes care of loading the many dependencies.

ffmpeg (ffmpeg-semifull-git, ffmpeg-tmblock-git, ffmpeg4.0, ffmpeg-cuda, ffmpeg-v4l2-request-git, ffmpeg-svt, ffmpeg-gl-transition, ffmpeg-svt-av1-git, ffmpeg-nox-git, ffmpeg-svt-vp9-git, ffmpeg-headless, ffmpeg-git, ffmpeg-full, ffmpeg-libfdk_aac, ffmpeg-ndi, ffmpeg-full-git, ffmpeg-nocuda, ffmpeg-amd-full-git, ffmpeg-intel-full-git, ffmpeg-amd-full, ffmpeg-vulkan, ffmpeg-vp9-timestamp, ffmpeg-mmal, ffmpeg-decklink)
perl-archive-zip
perl-crypt-eksblowfish
perl-data-dump
perl-data-entropy
perl-data-uuid
perl-date-manip
perl-datetime
perl-dbd-mysql
perl-device-serialport
perl-file-slurp
perl-image-info
perl-io-socket-multicast
perl-json-maybexs
perl-libwww
perl-lwp-protocol-https
perl-mime-lite
perl-mime-tools
perl-net-sftp-foreign
perl-number-bytes-human
perl-php-serialization
perl-soap-wsdl
perl-sys-cpu
perl-sys-meminfo
perl-sys-mmap
perl-uri-encode
perl-xml-parser
php-apcu (php70-apcu, php56-apcu, php71-apcu, php72-apcu, php80-apcu, php74-apcu, php73-apcu)
php-fpm (php55-fpm, php53-fpm, php72-fpm, php56-fpm, php-zts-fpm)
php-gd (php55-gd, php53-gd, php72-gd, php56-gd, php-zts-gd)
polkit (polkit-no-script-git, polkit-git, polkit-consolekit, polkit-duktape)
cmake (cmake-git) (make)
git (git-git, git-vfs) (make)

This method never really got ZM installed correctly so with git cloned the master branch from Zoneminder on Github into a directory /home/manjaro/Build I created. Then using cmake with the necessary options, created a makefile and compiled and installed Zoneminder using the cutting edge master branch, version 1.37.1.

Difficulty Rating : 8 (1 = easy - 10 = hard)

rockedge wrote: ↑Thu Sep 09, 2021 2:28 am

@wiak I finally got Zoneminder installed and working on a WDL_manjaro-xfce!
...
All of these steps were done in a root owned terminal.

I used pacman to install the base-devel, git , cmake packages. Then

Thanks rockedge. What happened after the 'Then'?

wiak wrote:

What happened after the 'Then'?

I think I finished the first part! Can you see it?

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

rockedge wrote: ↑Thu Sep 09, 2021 3:01 am

wiak wrote:

What happened after the 'Then'?

I think I finished the first part! Can you see it?

I see it. That's excellent! I will link to that in my WDL cheatcheat even though special purpose Zoneminder - good post to go back to. Any final other info added later will be great too of course.

EDIT. Note (nothing to do with WDL skeleton initrd, so users of that can just ignore): Now that the skeleton WDL initrd kit seems to be working without issue, I'm back developing my build_firstrib_rootfs f_build_plugin for my WDL_Arch64 distro. Mainly just re-organising the plugin. I've tried that several times before, but each time I've broken it and ended up going back to the original, but today at last I'm managed.

In the process I'm trying to see if I can make it work better even when upstream repos are timing out or whatever (you know the problem), and for Arch builds at least, I may have managed... turns out pacman has an option (I should have checked before...):

--disable-download-timeout
Disable defaults for low speed limit and timeout on downloads. Use this if you have issues downloading files with proxy and/or security gateway.

"Time" will tell if that really has worked, but certainly had a faultless build couple of times today.

Actually, I've just taken a look at Void Linux xbps man page... and turns out you can set an environmental variable for that, which hopefully might fix things there too!!! We should have noticed really:

CONNECTION_TIMEOUT
Sets connection timeout in milliseconds instead of default value of 5 minutes. When -1, waits indefinitely.

Debian apt seems to have some timeout settings that can be applied in apt.conf for http and ftp, though I've never noticed any problems when using Debian/Ubuntu repos. From man apt.conf page:

The option timeout sets the timeout timer used by the method, this applies
to all things including connection timeout and data timeout.

I was mainly wanting the pacman install files all to be done near the top so I could more easily comment out packages or add in extras. I'm also wanting to add a few minor desktop access tweaks for our home business-use WDL_Arch64 setup and the new arrangement makes it easier. Of course, once I have the newer build plugin tested as stable I'll be uploading it for anyone interested. Instead of using the build_weedog_initrd script, I'm simply also utilised the skeleton initrd (albeit a special one containing actual kmod+libs to account for Arch using .zst-compressed modules). I'm also planning to relegate wiakwifi for use as secondary network connection mode and install NetworkManager since that works in far more complex network scenarios. wiakwifi is pretty useful in quick build tests though - within the limits of its capability.

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

dancytron wrote:

Is there any way to "remaster" or merge the changes folder with the .sfs file (mainly to uninstall some stuff to make it a more manageable size)?

Re: remaster script, it was at that time made for Weedog Arch https://weedoglinux.rockedge.org/viewto ... p=216#p216
But I see no reason why it wouldn't work on other WDL variants (but TBH, I didn't test yet), just run it (as root) from the system you want remastered, standing in the WDL frugal install directory.
EDIT: Note that it depends on gtkdialog (EDIT: and Xdialog, included in the .sfs), attached 10gtkdialog64_libvte.sfs

I see that wiak added a note (in wd_remaster_fredx181 script attached here: viewtopic.php?p=36319#p36319):

 # IMPORTANT NOTE (by wiak): edit MAINSFSxxx if you are using 
# firstrib_rootfs at layer other than 01
# (e.g. MAINSFS="08firstrib_rootfs" and so on)
MAINSFS="01firstrib_rootfs.sfs"
MAINSFSDIR="01firstrib_rootfs"

Indeed that's important to set the MAINSFS= to the existing NNfirstrib_rootfs.sfs in the frugal install dir (backup .bak will be made e.g. 01firstrib_rootfs.sfs.bak)
EDIT: In case of Manjaro, or any other with multiple .sfs modules, these will be merged into one (e.g. 01firstrib_rootfs.sfs or e.g. 04firstrib_rootfs.sfs, as specified as MAINSFS=...) the others should be disabled (e.g by renaming to *.bak)
For the rest, if you want to exclude doc, man, locale files etc.., uncomment the preferred line(s) around line 90 (and further on according to what you prefer):

# create excludelist,
cat /dev/null > excludelist 
# uncomment or comment to exclude or not, man doc locales
find /var/cache/pacman/pkg -type f 2> /dev/null | sed 's|/||' >> excludelist
#find /usr/share/doc -type f 2> /dev/null | sed 's|/||' >> excludelist
#find /usr/share/man -type f 2> /dev/null | sed 's|/||' >> excludelist
#find /usr/share/info -type f 2> /dev/null | sed 's|/||' >> excludelist
#find /usr/share/gnome/help -type f 2> /dev/null | sed 's|/||' >> excludelist
#find /usr/share/gtk-doc -type f 2> /dev/null | sed 's|/||' >> excludelist
#find /usr/share/locale -maxdepth 1 -mindepth 1 -type f 2> /dev/null | sed 's|/||' >> excludelist

EDIT: Something else: anyone has seen the ridiculous amount of downloads of the cr-initrd script ? (now 317) viewtopic.php?p=36345#p36345
Cannot be correct IMO, not a problem of course, just wondering what can be wrong. (I also informed @rockedge through PM about it)
Must be Tomas M going crazy downloading it 300 times because he noticed that his code was "stolen"

Fred

@fredx181
I just found out that if you click on the file, but then cancel the download dialogue, the download count still goes up. I've added two to the total without completing a download (although I have done it previously - works fine for me).

Keef wrote: ↑Thu Sep 09, 2021 6:35 pm

@fredx181
I just found out that if you click on the file, but then cancel the download dialogue, the download count still goes up. I've added two to the total without completing a download (although I have done it previously - works fine for me).

Thanks, yes, but it's normal AFAIK when cancelling download the amount is increased by one, but someone did that 300+ times ?
Perhaps...
EDIT: As I asked rockedge, could it be some "bot" that does it, don't know, but never seen earlier such excessive number in a short time, btw.

fredx181 wrote: ↑Thu Sep 09, 2021 6:58 pm

Keef wrote: ↑Thu Sep 09, 2021 6:35 pm

@fredx181
I just found out that if you click on the file, but then cancel the download dialogue, the download count still goes up.

Thanks, yes, but it's normal AFAIK when cancelling download the amount is increased by one, but someone did that 300+ times ?
Perhaps...
EDIT: As I asked rockedge, could it be some "bot" that does it, don't know, but never seen earlier such excessive number in a short time, btw.

WDL skeleton initrd had only been downloaded a couple of dozen times, so clearly 300+ times for cr_initrd is for some other reason. That is certainly a lot of downloads for what is quite a specialist purpose (slimming boot modules).

fredx181 wrote: ↑Tue Sep 07, 2021 5:08 pm

Here's a way to create a much smaller initrd, attached cr-initrd script that I made.
...
And IMO it would be good if this or similar would be somehow part of wiak's "modify_initrd_gz.sh"

Yes, WDL systems are more usually built by two scripts rather than downloading any upstream iso for the rootfilesystem, and, as illustrated for WDL'd Manjaro XFCE case, then bolting on a modified WDL initrd. The more traditional WDL build system scripts are:

build_firstrib_rootfsXXX and build_weedog_initrdXXX

The first of these does what it says: build a firstrib_rootfs ready to be made into the likes of 08firstrib_rootfs.sfs

It is the second that is then used to 'process' the firstrib_rootfs and produce the final WDL initrd for use with it (moving modules into the initrd and also completes the mksquashfs firstrib_rootfs process along with excluding any unwanted parts in the root filesystem that was built).

So rather than alter the simple modify_initrd.sh utility, which is useful more generally for decompressing initrd and making quick changes of any sort, I am likely to alter the build_weedog_initrd to add in a call to cr_init.

I haven't yet published the newest (400-rc1) versions of these two main WDL build scripts but was planning to soon with new github uploads I'm working on.

Will release build_firstrib_rootfs very soon, but build_weedog_initrd was delayed anyway because (as I've said elsewhere) I discovered it didn't work with WDL_Arch rootfs builds any more because Arch had adopted zst-compressed modules and the official static busybox compile I'm currently using can't modprobe these (so temporary fix I'm using at home is a special initrd containing standalone kmod+lib dependencies for that).

Yes, an alternative (perhaps optional addition) will be a simple tweaked/renamed modify_initrd script that includes an appropriate cr_initrd call (maybe with cr_initrd 'slim' as an extra commandline argument), which I might also adopt.

Manjaro is the first of 2 Linux distros that have put GTK3+ behind them. They have moved to the, now, current GTK4+ which is expected to remain in current supported development for the next 5 years.

A leader & one less worry to contend in their future.

Merely FYI for this thread's knowledge.

Clarity wrote: ↑Thu Sep 09, 2021 11:58 pm

Manjaro is the first of 2 Linux distros that have put GTK3+ behind them. They have moved to the, now, current GTK4+ which is expected to remain in current supported development for the next 5 years.

A leader & one less worry to contend in their future.

Merely FYI for this thread's knowledge.

Well I know GTK4 is available via Arch repos (and a major advantage of Arch-based distros is that releases of software tend to be very up-to-date - 'bleeding-edge' availability), but I can't find any announcement from Manjaro that they have put GTK3+ behind them Clarity. The link you gave is just their DIstrowatch entry, but says nothing about GTK versions supported.

Yes Arch and Manjaro
On the distrowatch page noted, it shows in their package list.

My current WDL-manjaro-xfce is equipped with gtk2, gtk3 and gtk4.

managed to test out the desktop version of the zmNinjaPro appimage which installed while attempting to use yaourt to install Zoneminder as an option.

rockedge wrote: ↑Fri Sep 10, 2021 1:14 am

My current WDL-manjaro-xfce is equipped with gtk2, gtk3 and gtk4.

managed to test out the desktop version of the zmNinjaPro appimage which installed while attempting to use yaourt to install Zoneminder as an option.

Lovely. (I see zmNinja-Pro is a client for Zoneminder that can also be used on Android phones). It's a lot of fun playing with Manjaro XFCE. It really is great to be able to test out bleeding-edge stuff so easily via Manjaro (or Arch itself). The 'unofficial' Arch AUR repo is generally very good for finding most apps not yet in main Arch repos and Manjaro makes that easy to use.

Yes. its nice to know that it is built-in to the distro...not as an aftermarket thought.

@Rockedge what you share is totally remarkable. I hope it will result in a complete release containing the ZM. Then all forum users would need to do is attach cameras either to their PCs or via their LANs and have them working via your solution.

Really nice work and a very useful application.

Clarity wrote: ↑Fri Sep 10, 2021 12:57 am

Yes Arch and Manjaro
On the distrowatch page noted, it shows in their package list.

Oh I see now. Nice to know, thanks.

NEW (alternative but not replacement) DOWNLOAD (10Sept2021): Occasionally a distro can't be booted with 'standard' WDL initrd.gz because busybox modprobe cannot load the module format provided by that distro. In particular, Arch Linux itself (not yet Manjaro) has moved to using zst-compressed modules so this effects my own distro WDL_Arch64. Currently I am booting WDL_Arch64 with an alternative WDL initrd that includes full Arch kmod (+ its deps). I've thus included that alternative, larger (3.5MiB), skeleton initrd as a download via newly attached script get_WDLskelinitrd_kmod400rc1.sh.tar (remove dummy tar and make executable as usual). The previous (much smaller) skeleton WDL initrd.gz remains best for distros that do not have that issue.

The fetch/download script for the initrd_kmod version is also here: https://weedoglinux.rockedge.org/viewto ... p=355#p355

Note this also downloads a copy of modify_initrd_gz.sh and w_init_v400rc1 for those who want an external copy for quick modifications.

That external w_init file will be used in preference at boot time to the initrd internal one if you rename it to simply w_init, but you otherwise don't need this file at all since initrd.gz contains an identical copy that is automatically sourced by initrd/init if no external file named exactly as "w_init" exists. Note I accidentally called it w_init_v400rc1.sh when downloaded by the 'standard' get skeleton initrd script; it does contain shell script code but is sourced by initrd/init and is not itself a script per se and does not need to be made executable therefore. It won't be used at all unless renamed to w_init and can be safely deleted. Nevertheless, that external w_init capability is very powerful and convenient for those wishing to customise the boot/frugal-install functionality, but if you make a mistake in it... your boot may well suffer from the dreaded "Kernel panic"..., which generally occurs when the initrd/init cannot find the external root filesystem (NNxxx.sfs or NNuncompressed firstrib_rootfs for example) - often meaning that the bootpartition/bootdir has failed to mount. That kernel panic type message is exactly what you'd see if trying to boot an official recent Arch Linux rootfilesystem with the 'standard' WDL initrd - hence my supplying the special kmod-included alternative.

wiak

@wiak

I was trying out weedogging the fossapup iso, but get a kernel panic error. Is there another step which needs to be done for puppy distros. I followed the steps outlined by @fredx181, but without copying any modules to the decompressed initrd and copying all the sfs files found in the iso and numbering them. See attached image.

@gabtech I think you just need to add the kernel modules from the zdrv.sfs to the decompressed initrd_v400rc1.gz in /lib/modules and re-compress. The kernel panic is caused by the lack of the kernel modules..I think.....

@wiak I accidentally erased and deleted almost the entire contents of the WDL-manjaro-xfce with Zoneminder and other goodies installed and running! A real bummer. My unfamiliarity with the Thunar file manager caught me while I thought I was deleting a single file while messing around with the perfectly fine initrd-skeleton.gz trying to run Fred's script to make it even smaller and better, ended up killing all the files in the frugal WDL-manjaro directory. Watched all the desktop icons suddenly go into emergency.
So what an opportunity to redo the whole thing like install Zoneminder AND document a How-To while I see if I can repeat the success.

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

---------------------------------------------------------------------------------------------------

Ah, Puppy is an interesting one... Most distros /sbin/init just start up the distro... Not with Puppy... Anyway, I'm in WeeDogged Fossapup64 as I post this so will explain the mysteries somewhat. Of course to really use it with WDL initrd overlayfs facilities you will later need to fix a few bits and pieces because Puppy was designed to expect its aufs initrd pupmodes and so on, which WDL itself doesn't need or want. However, it actually boots okay and works quite well without any alterations. If you know Puppy operation well, you can no doubt easily make any alterations required for better WDL practical use, or someone like rockedge can no doubt help, but actually it is working fine (except for the shutdown issue I mention at the end of this post).

Sorry this is rough, but here is how to WeeDog FossaPup64... Very slightly more is involved than just the modules (still just takes 5 minutes to make the adjustments required):

In Puppy /sbin/init is in fact a script that checks Pupmode. We don't want that of course, and simply want to bypass that script.

Fortunately that is very easy to do with WeeDogLinux - we just need to tell it not to use Puppy's /sbin/init but instead use /bin/busybox init. Then that part of the problem will be solved. Modules I'll come to in a minute...

Changing WDL init to point to /bin/busybox init:
------------------------------------------------

This is a good test of a special WDL feature - its external w_init file. When you downloaded the WDL skeleton init you should also have received a w_init_400rc1 file (name might not be exactly that). Simply rename it to w_init
If you don't have that external w_init file you can copy it out of the uncompressed initrd.gz - its the same (or even edit the one in there before recompressing it if you wish, but an external w_init will take precedence):

Then using geany modify the very last code line of w_init from:

exec switch_root merged /sbin/init

to

exec switch_root merged /bin/busybox init

That's that part DONE then once modules copied from the zdrv.sfs(lib/modules) into initrd/usr/lib/modules it will boot fine.

-------------------

Now about Modules required by initrd:
-------------------------------------

Actually since Puppy uses a huge kernel there is only one really needed, which is 'overlay' since Puppy by default uses aufs not overlayfs. However, just to get you going I suggest copying all of the modules into the initrd per fredx181's howto. Where are the modules to copy from? They are in the zdrv.sfs in dir /lib/modules, so open that up to copy them into the initrd_decompressed /usr/lib/modules (per Fred's howto viewtopic.php?p=36144#p36144).

Puppy should then boot with the resulting re-compressed initrd.gz and kernel vmlinuz and the sfs files renumbered as you did (or alternatively as I did per my attached screenshot).

But DISCLAIMER: Once booted by WDL initrd you are using WDL overlay facilities so all that Pupmode stuff isn't used and some Puppy inbuilt scripts will get upset. In particular, if you try to shutdown, Puppy will get only as far as a console root prompt. That's because it ends up calling /etc/rc.d/rc.shutdown and that would need modified for WDL shutting it down more conveniently - also save facilities will be those of WDL, not Puppy (i.e. WDL upper_changes and so on).

HOW TO SHUTDOWN FOR NOW:
------------------------

Luckily that is easy. At the # prompt, simply enter command:

busybox poweroff

or if you want instead to reboot:

busybox reboot

Hope that helps. Let me know if still doesn't boot (in case I missed something above). Good Luck, its a fun exercise.

On my old laptop I was using grub4dos menu.lst stanza (use own uuid of course):

title WDL_FossaPup64
find --set-root uuid () b812c597-8099-4bee-9bb3-8b9c10f1e902
kernel /FP/vmlinuz w_bootfrom=UUID=b812c597-8099-4bee-9bb3-8b9c10f1e902=/FP
initrd /FP/initrd.gz

I'm not sure if I have the sfs load order correct per Puppy, but worked anyway - you can always change it (and have 100 layers available in WeeDog at boot time...).

EDIT: Like I say, the only module actually needed in the initrd.gz when booted by Puppy huge kernel is kernel/fs/overlayfs/overlay.ko
For a small initrd.gz you could therefore just leave the overall initrd/usr/lib/modules/ structure in place but remove all the modules other than that kernel/fs/overlayfs/overlay.ko one, which is needed... If you do that, the resultant initrd.gz is only 1.3MB in size. There are other possible tricks but I'll leave it at that just now.

rockedge wrote:

...Fred's script to make it even smaller and better, ended up killing all the files in the frugal WDL-manjaro directory.

Hmm... sounds bad, I like to understand what happened exactly, do you think there's something faulty in my script that caused this for you ?

@wiak

Thanks for the guidance. WeeDogged Fossapup64 booted fine as per your instructions. Posting from it.

@fredx181 Nothing wrong with the script at all!
It was all my fault, I was using Thunar and not paying attention and I accidentally deleted the upper_changes directory and some of the SFS files

Before I start up a new WDL-manjaro I reached for a firstrib_rootfs and Void Linux kernel 5.9.13_1 from a WeeDog64-Void created with wiak's build_firstrib_rootfs-400rc1.sh script. I have both the uncompressed firstrib_rootfs and the 01firstrib_rootfs.sfs to work with. For the first run I chose 01firstrib_rootfs.sfs since it already is named correctly for the WDL scheme and by using the mount tool script I can directly update/upgrade packages in the uncompressed 04firstrib_rootfs.

I added the /lib/modules to the skeleton initrd.gz and I have now a running a "WeeDogged" WeeDog-Void technically speaking.
Here the frugally installed WeeDogged WeeDog. Notice the symlink firstrib_rootfs, this is needed by the mount_chrootver007.sh to work with 04firstrib_rootfs. Instead of modifying the wiak's script I just use a symlink.
In most cases I would use the 04firstrib_rootfs.sfs which is 655 M. Also present is fredx181's script which I am getting ready to run to reduce the initrd.gz size and see how it goes.

This WeeDog64-Void is equipped with the JWM - ROX desktop combo. And uses xdgmenumaker to generate the menus for JWM and also xlunch as an alternative menu system

Also good news is 10gtkdialogGTK3_filemnt64.sfs loads at boot up and provides gtkdialog which is no longer in the Void Linux repos. I use a gtkdialog binary compiled for WeeDog from source gotten from the woof-CE github repo but now I can simply add this file to the /WDL-Void-skeleton directory and I have again have Mochimoppel's mm_view working PLUS filemnt does work to mount/umount squash files!

@wiak the filemnt set as run action works great but the notifications on mounting shows an empty box and also an empty text field in the notification box. I might need to install a dependency for the message to render correctly.