New initrd seems to be working... All the chess playing must have done my brain some good.
There are lot of new 'modes' almost all of which I will probably never use, but put them in for that unexpected need whilst I'm on top of the design.
I have added a considerable number of extra lines to the init script so it is a bit longer than I'd like being now a total of 470 lines of code including tons of comments. However, that's far far less than most other distro initrd/init scripts and can do things most can only dream of (current mainline Puppy init script being 1,370 lines of code, for example)...
The recent additions have resulted in a lot of duplicated code so I can or could no doubt trim it down quite a bit through a few functions, but sometimes that is more trouble than it is worth and doesn't improve efficiency at all so have to look at it and see if I want to do that (I find shell script painful when it comes to minimising close duplication - indirection is so easy in the likes of C, but not busybox ash...).
Like I say, most of the new operating modes are to provide crazy flexibility so many esoteric dreamed file arrangements can be accommodated with ease. For example, here are three grub.cfg stanzas I'm been using in testing a couple of the many available 'modes':
1.
menuentry "WDL_arch64" {
insmod ext2
search --no-floppy --fs-uuid --set 78683fe5-0323-4030-9ddd-39464a8fbf80
echo "Loading vmlinuz"
linux /WDL_arch64/vmlinuz-linux w_bootfrom=UUID=78683fe5-0323-4030-9ddd-39464a8fbf80=/WDL_arch64
echo "Loading initrd.gz"
initrd /WDL_arch64/initrd.gz
}
2.
menuentry "WDL_arch64" {
insmod ext2
search --no-floppy --fs-uuid --set 78683fe5-0323-4030-9ddd-39464a8fbf80
echo "Loading vmlinuz"
linux /WDL_arch64/vmlinuz-linux w_bootfrom=UUID=78683fe5-0323-4030-9ddd-39464a8fbf80=/WDL_arch64 w_changes=RAM1
echo "Loading initrd.gz"
initrd /WDL_arch64/initrd.gz
}
3.
menuentry "WDL_arch64" {
insmod ext2
search --no-floppy --fs-uuid --set 78683fe5-0323-4030-9ddd-39464a8fbf80
echo "Loading vmlinuz"
linux /WDL_arch64/vmlinuz-linux w_bootfrom=UUID=78683fe5-0323-4030-9ddd-39464a8fbf80=/WDL_arch64 w_changes=RAM2
echo "Loading initrd.gz"
initrd /WDL_arch64/initrd.gz
}
4.
menuentry "WDL_arch64" {
insmod ext2
search --no-floppy --fs-uuid --set 78683fe5-0323-4030-9ddd-39464a8fbf80
echo "Loading vmlinuz"
linux /WDL_arch64/vmlinuz-linux w_bootfrom=UUID=78683fe5-0323-4030-9ddd-39464a8fbf80=/WDL_arch64 w_changes=UUID=b9b2cdea-9f5c-4234-ad99-9d9c44f8fa69=/WDL_arch w_changes1=RAM2
echo "Loading initrd.gz"
initrd /WDL_arch64/initrd.gz
}
Number 1 has no w_changes= kernel line. That is the old standard where upper_changes folder gets directly read/write to on the bootfrom media.
Number 2 uses w_changes=RAM1. That mode copies the media upper_changes folder to RAM and that becomes the read/write upper overlay. I then use a special rsync script to copy back any changes (assuming I decide I want to keep the session). DIsadvantage is that whole media upper_changes takes up RAM so only useful for small upper_changes use if you don't have much RAM. In practice, once my system is built the way I want, I either remaster and hence thereafter have tiny upper_changes folder or I rename old upper_changes as NNupper_changes, which makes it a read only overlay for next boot.
Number 3 uses w_changes=RAM2. That's similar to RAM1 mode except the media upper_changes doesn't get copied up into RAM, instead it is simply mounted read-only as second-to-top overlay. That mode is pretty much the same as say DebianDog uses for changes=EXIT. Again a special rsync program is used to merge back the changes as and when desired.
Number 4 is as unusual as the grub.cfg stanza looks. Here the w_changes=specifies a different device/partition from the one booted from (hence different UUID). The additional w_changes1=RAM2 then instructs WeeDog to read-only mount the upper_changes on that device onto RAM (i.e. tmpfs). Number 4 could be used, for example, for putting upper_changes onto a usb flash stick (whilst main boot files are kept on main hard drive) and being able to use any of above RAM modes can per the usual fashion be used to protect the usb stick from too many write cycles.
All in all, with WDL init you can use sfs addon modules, or uncompressed folders as the addon modules, and you can store them anywhere on the system (they don't need to be on the bootfrom folder or partition) and similarly for the upper_changes folder - you can arrange for it to be anywhere, and independently use RAM for it if that is desired. Super flexible... Me? I'm likely to stick with either RAM1 or RAM2 upper_changes. There is also RAM0 mode which is a 'fresh' mode that uses RAM for upper_changes but ignores any previous upper_changes. That's particularly useful mode too since previous upper_changes can always still be used simply by putting a two-digit number on the upper_changes folder name (or turning it into a numbered sfs) - i.e. incremental rollback system).
Don't yet know when public release of this new work will be - too busy at the moment and more to do on overall system, and don't want to encourage the taking-without-acknowledging cherry-picker(s) further.
@rockedge I'll push early version for WDL_Void dev testing soon to you though.
wiak