Older Experimental Bionic32 using Overlayfs

[rockedge]

From the topic thread by gyro here -> https://oldforum.puppylinux.com/viewtop ... 01043d355e

Using the instructions outlined in the topic, I have built and packaged as an ISO a version of Bionic32 that uses overlayfs instead of AUFS.
This 32 bit system is for demo and testing out ideas. SFS-Load-on-the-fly is not available but the system can load SFS's during the boot process.

The persistence save mechanism works well in the limited testing I have done.

perhaps this Bionic32-OL will be of some insight but at least a look at a Puppy using overlayfs and not AUFS.

Bionic32-OL.iso
SHA1-MD5.txt

Screenshot(24).jpg (13.43 KiB) Viewed 1282 times

[ally]

I'd managed to miss that one

mirrored in the archive

[wiak]

Yes, that was the first pup attempt at using overlayfs I think. I knew nothing about configuring aufs or overlayfs in 2017 as far as I recall. I wondered why it was left as 'experimental' though my own feeling was that Puppy initrd/init was very (unnecessary) complex overall and should have been re-drafted to maybe include overlayfs in a leaner less long-time hacked piece of coding (and aufs as option, since only a few extra lines of code difference really).

The current woof-CE boot init (inside initrd) is 1480 lines of code. I am sure the same functionality could be achieved in half that amount of code if redone with hindsight, but maybe not. Current WDL initrd/init+w_init using overlayfs and with very similar overall functionality is only a total of 669 lines of code including the ability to use either compressed (sfs) or uncompressed (directories) as layers (and I am almost certain I could slim that down a bit at least whilst keeping the code relatively nice and simple to read/study). I'm not mentioning this to criticise Puppy (as a user-friendly and efficiently working distro) - its initrd/init certainly works fine, and that's the most important matter in the end...

However, personally I've never had the patience to work out how Puppy initrd/init does what it does - I once looked in hope it could be useful, but abandoned looking almost immediately because I found it a nightmare of so many lines of code - instead I just read the kernel overlayfs docs and tried a few overlayfs tutorial examples and set out to make my live boot WDL_initrd/init via trial and error and luck as it turns out. If only the Puppy initrd/init could be even halved in size for the same functionality it would be so much better for its maintenance and development IMO. Indeed, I admire gyro for managing to get overlayfs working with such a complex original aufs-based initrd/init design - but not too surprised that his experimental overlayfs support stayed as experimental, and not just because of sfs-load issues I think. Using aufs does not make an init bigger, so it is something else that makes Puppy initrd/init so big and complex. More recently of course both dimkr and mistfire have created overlayfs-capable pups (whilst keeping aufs backwards compatibility); I don't know if they have managed to slim down the size of the resulting init though.

Bionic32 was so long ago now... what a pity for all of us that nothing much came, back then, from that development of five years ago. Unfortunately the Puppy community seemed to develop resistance to 'change', whereas original Puppy was more famous for 'innovation' - I think that innovation mode is returning now though (it had to), but there remains some resistance to change from some older Puppy users. Old dogs can learn new tricks though... even new image formats (rather than iso ) sometimes... To be honest and fair, Claytihe resulting init though.

Bionic32 was so long ago now... what a pity for all of us that nothing much came, back then, from that development of five years ago. Unfortunately the Puppy community seemed to develop resistance to 'change', whereas original Puppy was more famous for 'innovation' - I think that innovation mode is returning now though (it had to), but there remains some resistance to change from some older Puppy users. Old dogs can learn new tricks though... even new image formats (rather than iso ) sometimes... To be honest and fair, Clarity, aside from his continual insistence about iso-booting researches and requests more newest Linux/computing-generally technology introduction to Puppy than most anyone else - he is very future-aware on the whole compared to the rest of us really. Maybe he is correct about the continuing importance of iso format - not keen on it myself though.

Human nature to favour our own designs, so no attempt by me to deny bias in my comments above. I still wish Puppy initrd/init was slimmer and thus more readable and understandable and easier to modify to my worsening brain and eyesight though. Puppy (to a great extent rightly) prouds itself on its small and efficient size - but that Puppy initrd/init is an example of the opposite to me. Not a problem to Puppy users of course, and probably not to those Puppy devs that already understand Puppy initrd/init inside out (though maybe still tricky to modify/hack it for extra or different functionality). No hrm starting with a clean piece of paper and hindsight to redraft something a bit long in the tooth - in fact after so many years of hacking away at it I feel that would be a good exercise for whoever is interested to take on such an admittedly difficult task. That initrd/init is referred to as the 'heart' of how puppy works afterall, so it is a critical component to mess with for sure.