Puppy Linux Discussion Forum

Booting BionicPup32 rootfilesystem and now also FossaPup64 rootfilesystem via WeeDog overlayfs initrd (and also DebianDogs).

I've currently put this thread in 'Cutting Edge' section since, when it comes to Puppy, people seem to put overlayfs stuff in here, though WeeDog has been using overlayfs for a long long time now so only cutting edge in that sense if Puppy moves to use overlayfs by default (since officially supported by kernel dev whereas aufs is not).

Quote initrd/init README of official Puppy Linux:

The init script has been called the heart of Puppy Linux.
This is not because it implements a lot of Puppy stuff, but because this is where Puppy starts.

WeeDogLinux is normally built using two build scripts.

1. First a desired root filesystem is built from the upstream repo components you desire (be it upstream Void, Debian, Ubuntu, Devuan, Arch or ...) using build_firstrib_rootfs-latest.sh

2. Second, the heart of the system (the initrd) to provide all the main underlying overlayfs functionality (such as various save persistence mechanisms, use of sfs files OR uncompressed standard directories, w_copy2ram, upper_changes rollback capabilities, and more) using build_weedog_initrd-latest.sh

However, WeeDog initrd is purposively created as distro 'agnostic' to allow such a wide range of WeeDogLinux (WDL) distro flavours to be created in an almost lego-like fashion (with most basic just requiring busybox and a standalone package manager such as xbps of Void Linux, which rockedge has a particular fondness of). It is perfectly possible with WeeDog, therefore, to use pretty much ANY distro's root filesystem (stored either in an uncompressed directory OR as a squashed filesystem file) and bypass needing to use build_firstrib_rootfs-latest.sh first step. That is how I created WDL_Slitaz32, for example (and at one time a WDL_Slackware) - WeeDog is thus a convenient means of converting even a normally full-install-only distro into a very flexible frugal installable one (Puppy itself being mainly a frugal install, but can be full install).

Accordingly, I have now taken Puppy filesystems (adrv, fdrv, zdrv and pup_xxxx.sfs) and used build_weedog_initrd-latest.sh to create a WDL_BionicPup32 (actual any Puppy system could be converted to use WDL overlayfs core) but using WeeDog's overlayfs frugal install facilities INSTEAD of convention Puppy aufs PUPMODES.

Like all WeeDog booted systems it's possible to arrange session rollbacks (via user written script - I haven't written one, but is trivial to arrange, and rufwoof did some experiments with it once upon a time in WeeDog, and can also be done manually via filesystem deletes and renames) and WeeDog has also always been able to use any or all of pup_xxx.sfs, adr, fdrv, zdrv and so on as uncompressed filesystems as an optional alternative - uncompressed means more on disc storage space of course (but most have plenty available anyway) but allows quick modifications since not in read-only sfs filesystems when stored in that form. But, yeah, can use sfs, like traditional Puppy is only able to use (aside from some relatively recent experimental hacked versions). Only thing that doesn't work, with overlayfs approach, is Puppy aufs sfs-on-the-fly-load/unload capability, though there are other ways to arrange that (e.g. via symlink sfs loading that some have been experimenting with on this forum and as used in tinycorelinux). Sfs files can and are able to be included at boot time though, so not a major issue for most in practice.

Anyway, to cut long story short, see obligatory screenshot of WDL_BionicPup32 (and WDL_FossaPup64), with some details here:

Screenshot: Now in post immediately below to keep on topic.

I'm continuing to post from WDL_BionicPup32 right now - going well, nice and stable. I may try a WDL_FossaPup or whatever next... (Also now WDL_FossaPup64)

You can also see a screenshot of a WDL DebianDog (being WDL_XenialDog64) here:

viewtopic.php?p=12902#p12902

So, though WeeDog is not itself at all derived from Puppy Linux, nor any of the DebianDogs, it can certainly get married to any one of them!

and provides a convenient way for Puppy/Dog enthusiasts to experiment further with kernel-supported overlayfs frugal install layering mechanisms as an alternative to aufs.

wiak

Re-posting here since had in wrong place (was off-topic):

By the way, I couldn't resist for my Christmas fun experiment: I am currently posting from WDL_BionicPup32, being Puppy root filesystem running via WeeDogLinux overlayfs initrd (WDL_FossaPup64 also now booting without issue). One neat thing about using WDL initrd is that it can not only use the filesystem parts as squashed filesystems but also you can unsquashfs them (and simply put number at the front to identify overlayfs layer order); WeeDog has always had that unique facility. For example, I can either boot with that renamed to 01firstrib_rootfs.sfs or use the unsquashed version (similarly zdrv_xxx.sfs, can be used as 04zdr_xxx.sfs or as unsquashed fs version of that). Unsquashed takes more disc space of course but great for development work since can just modify things directly inside the uncompressed directories. Method should work with any Puppy (made using mtpaint on WDL_BionicPup32 itself, and posted from WDL_BionicPup32 'light' browser. No Pupmodes on this system of course since using upper_changes mechanisms and all the other alternative options WeeDog initrd provides (such as renaming upper_changes to, for example 50upper_changes, then next session as 51upper_changes and so on (and hence have rollback facility using some userland created script to manage it all). Or of course can use WeeDog w_copy2ram function and if wanting saved version of that just save the RAM/upper_changes to storage media upper_changes. Same applies to the WDL_XenialDog64 I created last night - the ability to use uncompressed directories is very useful for easy experimenting also...

Obligatory screenshot of WDL_BionicPup32 attached. See the folder organisation in the screenshot to basically see how I've created WDL_BionicPup32, the terminal 'mount' command shows the overlayfs mount. WDL_XenialDog64 booted on first attempt. With Puppy distros there is one trick: currently /sbin/init is a BarryK shell script - I am not using that but instead made /sbin/init a symbolic link to /bin/busybox - then it boots up without issue (using Puppy's /etc/inittab, which calls Puppy's rc.sysinit shell script and so on...).

It works fine by the way. Even the 'woof' sound barked at me on first boot and Puppy Simple Network Manager allowed me to connect via wifi straight away. Perhaps I should produce an iso for this one? Alas, tis a busy time of season (and summer here and sunny, so I should be outside...) and I shouldn't even have taken time to get this far at the moment!!! We will see, but I certainly wouldn't bother releasing WDL_DebianDog iso since wouldn't really add anything useful to what's already there and I know Fred has overlayfs set up to work the way he wants it with Porteus boot now anyway. My own focus remains WDL_Arch64 desktop and creating same for ubuntu and void flavours via modifying that firstrib build plugin. I also don't want to add too much to WeeDog initrd in terms of how to manage save persistence - I want to keep the actual implementation of that separate from the underlying lower level mechanisms required (which for the most part are already inside WD initrd/init) and leave the details of implementing the likes of rollback sessions and so on to user-level scripting rather than bloat the initrd/init itself with that (though plugins to the initrd/init would also be acceptable to me - as you know from WeeDog design, and even weX program, I have a fondness for 'plugins' to add functionality to main core).

rockedge wrote:

I have also created a WDL-Fossapup hybrid that seems to run with either a huge Puppy Linux AUFS kernel or the monolithic Void kernel. I have not yet done that much with it other than to see if it would run.

That's interesting. I never tried running it with official Void kernel/modules. Gives a lot of scope in using alternative official kernels without having to build special huge kernels. But yes, now that you mention it, WeeDog should allow the distro to work with non-huge-kernels (i.e. kernels that rely on external modules rather than having all drivers built in the way typical Puppy huge kernels do). Does mean a bigger initrd.gz size than the one usually used by Puppy (since the initrd has to include whatever kernel modules are needed), but per Fred's recent idea to use mkinitrd to get slimmed modules list, the size of initrd.gz isn't particularly large anyway (and actually is a case of size doesn't matter too much at all for initrd.gz anyway...). The core part on WeeDog initrd, being the init script that controls all the overlayfs functionality is actually much much smaller in code lines than the traditional Puppy init. I must remember to remove aufs from the list in WeeDog initrd/init - doesn't do any harm being in the list I think, but as you know WeeDog uses overlayfs and doesn't use or need aufs at all (just an accident of history I left aufs module name in since was originally contemplating building WeeDog to use aufs prior to electing to use overlayfs instead).

One thing that needs to be done for WDL_FossaPup64 (or any WeeDog Pup) is to modify shutdown routine or shutdown only gets as far as commandline prompt. Small matter though. Will be other such small issues needed to polish it up though.