So many INITramfs for Puppies, can Dracut rule them all?

[Clarity]

There has been much activity over the past 2 years in starts for PUPs across the Forum and GIT; namely various INITs for various PUP/DOGs.

For some, this is dizzying.

Today, I stumbled across this, DRACUT, where one way of reading it, it is an INIT ruler...no matter which PUP/DOG/Distro offering currently in the forum.

Says "... Unlike existing initramfs's, dracut's framework attempts at having as little as possible hard-coded into the initramfs as possible. ..."!

Could this offer an "un-thought-of" flexibility?

Almost implies it can "rule them all"

[wiak]

Could this offer an "un-thought-of" flexibility?

Almost implies it can "rule them all"

Personally I think not. Dracut isn't really about providing the likes of PUPMODE13 and so on (or w_changes=RAM2 for that matter) or handling aufs or overlayfs layers, which is what we concentrate on in terms of frugal install functionality here. These kind of flexible facilities need to be programmed into the init used inside any initramfs (which we often refer to as the initrd).

I commented about dracut briefly after a question by forum member Grey: viewtopic.php?p=21163#p21163
Grey did say something like that is being done by a group in Russia: http://neobht.github.io/uird/
So maybe it can be done, but been too busy to look into such a complex system.

So, all in all, despite being aware of dracut (and even looked through some of its module handling code) I remain no expert about it, but, no, I do not mysefl think dracut per se could be used to produce a Pup/Dog type boot initrd. Great if I am wrong. As I said, worth exploring, but I don't expect anyone will find it can make an initrd of the sort we want here - it does produce an initrd of course, which can be used to boot live or full install distros I believe (Void Linux official uses it) but the thing missing is the most important layering/save-persistence mechanisms - that's what we do here in our initrd creations. But if I'm wrong, I'm all ears to know how to do it with dracut.

Having said that, we have used it for a few useful matters, which this other comment I made some time back concerns: "using any flavour variant of mkinitrd/dracut is useful and fine for now, on a temporary shrink the initrd modules code". I was referring to the process of reducing the size of the initrd we build by slimming down the modules inside there to the bare minimum required to find the boot media. Fredx181 produced an (alternative) script to help with that process, which remains very relevant: viewtopic.php?p=36345#p36345
That doesn't use any portion of the large dracut system, however, but rather uses some routines from Tomas M of linux-live.org (and slax.org).

re: Grey's suggested UIRD (google translation):

UIRD - Unified Init Ram Disk system
Unified init system for modular Linux systems.

Join the chat at https://gitter.im/wird/discussion

Basic description of the main principles
UIRD is a kind of initrd, its task is to assemble the root file system from the aufs / overlayfs layers and transfer the load to / sbin / init (systemd) with this root file system. The implementation of UIRD is based on a set of dracut initialization scripts (modules base, kernel-modules), the uird-init initialization script and the livekitlib library of functions for it (a modified analogue of liblinuxlive, livekitlib of the Slax project).

The main differences from initrd implementations for modular systems of similar projects.
* Lack of binding to a specific distribution
* Lack of binding to specific directories to search for sources
* Ability to connect almost any source that can be mounted in linux
* Support various network protocols for network download
* Adapting UIRD to your OS comes down to writing a single configuration file
Command line options
Due to the multiplicity of kernel parameters, the 'uird' parameter prefix (Unified Init Ram Disk) has been introduced:
* uird.parameter=value - set a new value that will replace the default value;
* uird.parameter+=value - add a value to the list of default values
At the moment, there are more than two dozen parameters, most of them only expand the basic functionality with additional features.
main parameters
* uird.ro[+]= - filter for modules/directories that are mounted in RO mode
* uird.rw[+]= - filter for modules/directories that are mounted in RW mode
* uird.cp[+]= - filter for modules/directories whose contents are copied to the root
* uird.copy2ram[+]= - filter for modules/directories that are copied to RAM
* uird.load[+]= - filter for modules/directories that need to be included at the loading stage
* uird.noload[+]= - filter for modules/directories to be skipped during loading
* uird.from[+]= - sources where modules/directories for the system are located
* uird.home= - source where users' home directories are stored
* uird.changes= - source where to store persistent changes
* uird.mode=MODE - save mode (clean, clear, changes, machines)
Options for more complex configurations
* uird.cache[+]= - sources where modules/directories should be synchronized
* uird.copy2cache[+]= - filter for modules/directories that are copied to the cache
* uird.homes[+]= - sources where user home directories are stored (AUFS / OVERLAYFS combined)
* uird.mounts= - sources to be mounted to the specified mount points
* uird.find_params[+]= - parameters for the find utility when searching for modules (for example: -maxdepth,2)
* uird.help - prints a hint for UIRD options
* uird.break=STAGE - stop loading at STAGE stage and enable debug mode
* uird.scan= - search for installed OCs and components to determine uird options
* uird.swap= - list of SWAP partitions and/or files to connect, separator in the list is ";" or ","
* uird.syscp[+]= - list of files (directories) to copy from UIRD to system /path/file::/path/directory
* uird.basecfg= - location of the base configuration file basecfg.ini
* uird.config= - location of MagOS.ini system configuration file
* uird.sgnfiles[+]= - enumeration of marker files to search for sources specified in uird.from= in accordance with their enumeration order
* uird.ramsize= - RAM size
* uird.ip= - IP:GW:MASK, if not specified, DHCP is used
* uird.netfsopt[+]= - additional network file system mount options: sshfs,nfs,curlftpfs,cifs
* uird.aria2ram= - list of sources to be copied from network to RAM before searching for uird.from
* uird.freemedia - free (unmount) sources, shared with uird.copy2ram
* uird.force - continue downloading without asking if the source is not found
* uird.parallel - connecting modules in parallel mode
* uird.run[+]= - run external executable files
* uird.zram - use zram instead of tmpfs
* uird.union=overlay - use overlayfs instead of aufs
* uird.shutdown - create the /run/initramfs directory that systemd uses when shutting down the system, transferring control there
* uird.preinit - enable processing of the ini file specified in uird.config
* uird.hide - enable MEMORY mount point hiding mode (useful for kiosk mode)
* quickshell, qs - console at the initial stage of uird-init

The above certainly looks promising, but is way more than dracut itself (which is as I say a big system) and the result, I suspect, will be very similar to what we already have, but not necessarily better (it seems to be looking to provide much the same functionality - but hand-crafted initrd/init will be hard to beat for efficiency I think). However I'm not writing UIRD off - might be very good indeed and worth looking at, but at the end of the day it is not the work of this forum. Also, I can't see myself studying or using another team's initrd system - I prefer working from first principles and implementing my own simple ideas (so far so good...), and being retired I don't want to do more than I already do. But maybe someone else will familiarise themselves with UIRD since it sounds like it would be a usable alternative to what we provide here.

You might note the "Lack of binding to a specific distribution". That is also a feature of the really incredibly simple WeeDogLinux initrd build system, which is how I am able to use it in, for example, weedogit.sh to boot countless other distros and give them the full funtionality of the WDL initrd.gz. But the build_weedog_initrd script is a single simple script... nothing like the complexity of dracut plus linux-live, which is really many multiple scripts - much like debootstrap from Debian, though that is for the different purpose of building Debian root filesystem. WeeDog uses its own method for building a root filesystem, which is via a simple single script called build_firstrib_rootfs... simplicity in design/build is what WeeDog's main two build scripts are all about. And build_firstrib_rootfs script uses a simple user plugin, which is what rockedge writes (to use via build_firstrib_rootfs script) to build his own KLV-Airedale root filesystem - really WeeDog build system is simplicity itself, but it works.