So a few months ago, I implemented WeeDogLinux early "split-init" initrd along with a supporting WDL_arch64 f_00 build plugin along with the new build scripts: build_firstrib_rootfs and build_weedog_initrd.
The downloads for these have been available since that time for anyone who wanted, but I haven't till now announced the links other than to rockedge, who develops WDL_Void versions using the scripts. To be honest, I wasn't too happy at some 'cherry-picker' devs taking WeeDog ideas without the decency of acknowledging the long existing WDL implemented ideas - so publishing contributions became less of an interest for me personally. Also, I've been busy since, working on WDL server implementations for my family (including vncserver/virtualGL remote access additions). However, since these latest WDL builds have proved stable for several months now I think it is time I announced download links more widely. I'll just double-check the files are all correct on public github site prior to now doing so.
As I indicated in that earlier post of May 18, WeeDog now includes implementation of several new creative ideas and save persistence features. In particular:
A. The early (on boot), initrd/init, is split into two parts: the earliest part of that init simply sets things up so that it can read the second part (named w_init) from external mediai. i.e. w_init, is stored on external media as a simple text file (or code to be sourced) rather than hidden away inside the initrd.gz itself. Beauty of the arrangement is that users can now contribute their own w_init files as plugins for different layering functionality and features. Additionally, it makes initrd init development easy since there is no need to uncompress the initrd.gz to try out new ideas (I have been using this new feature a lot in the past few months - it's great).
wiak wrote:By the way, clever thing is that though I keep a copy of w_init in the initrd.gz, it isn't needed in there at all... you just need the small init script, which looks for and finds the main w_init script, which is stored simply as an executable text file (chmod +x) in the main bootfrom partition/directory. i.e. a user can modify WeeDog boot behaviour now without needing to open the initrd.gz at all - just use geany on the external w_init part. If there is no external bootpartition w_init script the one stored inside the initrd.gz gets used instead. This facility was great during development getting it all working.
Actually, w_init doesn't have to be set executable, it is simply sourced by the early initrd/init.
B. The second major development is in the addition of several new initrd/init features. In particular some new save persistence modes including further w_changes in RAM modes/mechanisms. These were also described back in May:
wiak Tue May 18, 2021 wrote:1. In newest dev initrd/init, simplest w_changes mode is: w_changes=media (or simply w_changes="", which is default anyway if not included on grub kernel line), which results in direct writes to the boot media (read/write top layer) upper_changes folder.
2. Next simplest is w_changes=RAM0, which puts an empty (read/write top layer) upper_changes folder onto tmpfs, but ignores the boot media upper_changes folder altogether.
3. The next one, w_changes=RAM1, I've been using in practice for a month or two now. That one is a very simple way of combining media upper_changes with RAM upper_changes; all that happens is that at boot time the whole of boot media upper_changes folder gets copied as is into RAM byte by byte, so that is RAM expensive (it uses RAM so only intended for cases where media upper_changes folder is kept small such as when using alongside regular NNupper_changes.sfs rollback snapshots). Despite that actual RAM usage, the method does have the advantage that there is no merging needed at end of session - the whole RAM stored (read/write top layer) upper_changes can simply be rsync'd (basically the delta of changes) back to the permanent copy stored on the boot media.
...
4. RAM-saving mode:Of course, it is not necessary to copy whole media upper_changes up to tmpfs RAM. Instead the media upper_changes can itself simply be mounted read-only in the second from topmost layer (i.e. not copied into RAM at all, simply mounted ready for use), and the top layer can then be a read/write empty upper_changes folder in RAM. Then at end of session (or whenever required) that top layer can get merged into the on-disk upper_changes version: That's mode w_changes=RAM2.
Once I've double-checked build from public github I'll announce details further for anyone else wishing to try out the new split init and other features. Cherry-picking is fine as long as due credit given (else future publication will likely cease altogether, sorry).
The WDL split-init creation allows WDL users to easily contribute their own early boot init implementations since most of the code providing the features and overlays is implemented in that external w_init, so different w_init(s) can be used for different features/purposes (e.g. aufs instead of overlayfs, or alternative layer arrangements or save persistence mechanisms). Being simply a directly editable text file, w_init makes development of these init features much easier since no need to uncompress the initrd.gz to get at the code... It's proven to be a really great and effective WDL implementation idea.
The usual WDL layering algorithm/code remains the most powerful feature though, especially since the system will load ordinary folders as layers, and/or sfs module layers. During development I often leave everything as folders since can easily hand-edit their contents, or sometimes just squashfs some of them to save space. As long as the filename begins with a number they will be used (in numeric layer position) as one of the overall filesystem overlay layers, whether they are an sfs file of a numbered folder.
Cheers,
wiak