Can Aufs and overlayfs Exist in the Same Kernel and Work?

[rockedge]

Thinking of what the technical requirements would be for a hybrid Puppy-Void to be fully versatile. Can Aufs and overlayfs exist in the same Kernel and both work?

[fredx181]

Yes, in theory it can work, aufs and overlayfs can exist both in the kernel, but to make it work both is another story.
Then the init script (in e.g. initrd.gz) should be constructed in a way that can make both work.
As an example: with the very advanced Debian "live-boot" it works, with the option "union=aufs" that can be added to the bootloader kernel line to boot with aufs (without it, the default "overlay" will be used).
To make similar working with Weedog or Puppy, I guess it requires major modification of the init script.

Fred

[wiak]

Of course it is also possible to use aufs (or overlayfs) in various merge-directory-type arrangements after booting has already taken place:

http://murga-linux.com/puppy/viewtopic. ... 96#1025496

Not sure of any advantages of doing so though. My interest back then was in using either aufs or overlayfs for the case of a full install distro - though mainly I was just interested in experimenting with overlayfs (and remain more interested in that - especially since works with pretty much all kernels).

[wiak]

Originally I had planned to allow either aufs or overlayfs as layer mechanism in WeeDog init. In early version it was just a one line change to get the layer order correct (as far as I remember), but then I added some extra changes options, so a few more alterations would be required now, including taking xino into consideration. Not difficult to implement (except for checking xino operation with aufs) but definitely low-priority for me.

I have however posted elsewhere

viewtopic.php?p=13074#p13074

about how simple it is to make both a WDL_BionicPup32 and a WDL_FossaPup64 using WeeDog standard overlayfs initrd. When I make these I only put overlayfs module, from Puppy zdrv, inside the WeeDogLinux initrd - so it is tiny... (but keep the full Puppy module set in the zdrv itself of course).

I'm too busy working on WDL_GO system at the moment (also using Puppy kernel with only overlayfs modules in the initrd for that on the first version), but still may post WDL_BionicPup32 iso and WDL_Fossa64 iso later (with modified shutdown routine), but no hurry, and I noted from one of your posts that you made, I think it was WDL_FossaPup64. anyway rockedge(?).

[rockedge]

Yes I made a working WDL_FossaPup64. I want to try to further pursue this soon in a more concrete fashion. Once I have the WeeDog64-Void-1.6 far enough to offer with the Zoneminder build script ready to go, I am going to use the WDL build scripts to construct a better WDL-Bionic64 since I have at this moment a more stable platform in Puppy Linux Bionic than with Fossapup.

I plan on using a Puppy huge kernel to start but will also test using a Void kernel if at all possible.

[wiak]

I am going to use the WDL build scripts to construct a better WDL-Bionic64 since I have at this moment a more stable platform in Puppy Linux Bionic than with Fossapup.

I plan on using a Puppy huge kernel to start but will also test using a Void kernel if at all possible.

Yes, that sounds useful, and also for anyone in Puppy-user community to experiment with alternative overlayfs layer and save persistence control.

[rockedge]

I have upupBB-18.05+8-OL that someone constructed that uses overlayfs instead of aufs that seems to work like a Bionic32. I can't find the ISO but I have a frugal install of it.

I can't find the post on the old forum and I'm not 100% on who made it. I think gyro perhaps?

I was checking this out as well -> http://murga-linux.com/puppy/viewtopic.php?t=99376

[wiak]

Personally, unfortunately, I've always found Puppy initrd/init script an almost unreadable mess and I get the, admittedly uninformed, impression that, like woof-CE, it is more than somewhat convoluted/hacked-together over many years (in code lines it is huge compared to WD initrd/init). Considering all the possibilities it neglected to incorporate (or wasn't modularised enough to allow easy additions), it would be simpler now to redesign it from scratch rather than continually trying to patch it up like an old bike tube. However, Its main failing, in my opinion, is that it has not been created in a distro-agnostic manner, so its code is tightly tied into Puppy rootfs design/distrospec variables/modes etc. Not that I've anything against Puppy - it remains quite an efficient user-friendly system (up to a point), and I still run Pups in order to provide dotpets of some app/utils I've written. It is certainly conceptionally easier to assemble dotpets than say Void packages or deb packages - though utilities have been written by various people that make the deb side of things easy nowadays (so I even included deb package extraction/creation in WDL_Arch64 since I find it useful).

I've actually been working on WeeDog initrd/init today as part of my WDLGO developments and I'm on a bit of a roll with my first (ubuntu-based) variant (actually I think the build scripts I've just completed can build both bionic and focal variants for both i386 and amd64). One thing that you've used in the past was 00firstrib-firmware-modules.sfs. That bit of the code was written so long ago (and for chroot, rather than switch_root, initrd version originally I think) that I wasn't sure if it still worked; but it does (once I remembered how to use it...). However, for the LGO system I had a particular use for it such that I've modified that part of init a little bit - now it can be named 00<anything> and like all other layers be either an sfs file or a raw uncompressed directory. Took just an extra three or four extra lines of code and doesn't effect efficiency in any way since alternatives done via an if then else selection. Main reason I wanted to use that 00fwmods facility is similar to original reason: making it easy to use a huge kernel from Puppy along with related fdrv/zdrv firmware/modules - for small system WDLGO variant.

Result now is that after I have constructed appropriate 00fwmods dir or sfs, using Puppy huge kernel, I don't need to include any modules in initrd itself, nor any in firstrib_rootfs (since that init code results in that same fwmods contents being accessible both to the initrd and to the firstrib_rootfs (though needs huge kernel to access the storage media). Hence resulting LGO firstrib_rootfs is small (current ubuntu base, which includes all dependencies up to and including dpkg is only 8MiB in size (EDIT: now 01firstrib_rootfs.sfs is 12.3MiB - additions were needed to get dpkg working 'correctly', which was tricky...) with a 600kiB initrd.gz; so pretty much all the size of that simplest base LGO ubuntu system ends up in the 00fwmods addon layer (my current fwmods sfs is 36MiB). Using that base (which connects to internet via ethernet, using wiakwifi/udhcpc) my next step is to create the various component addons I've planned out in detail - about four of them, including openssl/certs, wpasupplicant for wifi, and apt for dependency-resolving package management. This new WeeDog system is an alternative to the usual debootstrap-created variants; no debootstrap being used at all.

What on earth am I doing so much computer work at this summer time of year?! That is not my usual behaviour (or plan)... I will publish latest stuff soon but then all but vanish till autumn at which time I will focus only on WDL_UbuntuXXX64 clone of current WDL_Arch64 release...! But this WDLGO creation has captured my interest and all your fault @rockedge for keeping my attention here via your WDL_Void32 developments...!

wiak