The Dracut Initramfs Generator Is Slow - Could Be Much Faster As Shown By Distri's Minitrd

[BwackNinja]

Also, what I find really interesting about distri is its use of fuse to manage merging compatibility directories. It's a lot like gobolinux in that regard, where the tradeoff is a little less performance in order to have a dynamic merged tree instead of maintaining symlinks.

https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/

https://github.com/distr1/distri/blob/master/cmd/distri/internal/fuse/fuse.go

[skeevy420]

You must have an old PC as my 2018 mid-range laptop generates initramfs in less than 30 seconds.

Compiling ZFS dkms modules adds the most time. Everything else is done really fast.

[Etherman]

This initramfs stupidity needs to go away.
Things were a lot better when we booted straight to root fs.

[cl333r]

initrd generation has been the slowest part of the whole package management infrastructure since forever. Every time I've seen this step during an Ubuntu update I've asked myself why it would take so long.

Not only that but the update process might trigger it several times which is really annoying.

[skeevy420]

Having initrd gives the flexibility to have the rootfs in many different configurations. It could be encrypted, remote, selectable, require drivers not in the kernel, or not even exist. it isn't strictly necessary, particularly in a standard desktop system, but is normally easier and more generic than the alternatives.

/srv traditionally included files for services, like /srv/http or /srv/ftp, the former is /var/www in debian-based systems.

As for big changes to the filesystem hierarchy, you'll have a good amount of software to patch. To start with:

• /etc/passwd, /etc/hosts, /etc/resolv.conf and a few others are hardcoded into the libc and other programs
• #!/bin/sh or #!/bin/bash is often the shebang in shell scripts, and you'd have similar problems with python whether you use #!/usr/bin/env python or #!/usr/bin/python
• /etc/mtab is often used because it's not Linux-specific like it's normal symlink end, /proc/mounts
• /var/run is similarly used by software, and normally a symlink to /run on the filesystem
• You'll need to set your include dir for building software because its normally expected in /usr/include by the compiler
• /lib/ld-linux.so.2 is the linker hardcoded in most binaries, so no 3rd-party binaries can be expected to work without it

Beyond that there's also deeper philosophical questions like:

• Where is the line between data and configuration? - This is more visibly blurred where software has its default configuration in /usr/share, and overrides (by the distro or user) in /etc
• How do you organize configuration and other data? Particularly in the case where it is shared by multiple programs. (again, /etc/resolv.conf and others come to mind)
• Is there a separation between the base system and applications? As it is with the FHS, there isn't really a notion of a core system -- all packages installed are integrated into the system rather than being treated as an addon to the system.

I have also put a lot of thought into. My main conclusion is that if a standard works well enough, it won't be changed by any big player because of the costs vastly outweigh the benefits. The filesystem is just another implementation detail, people care more about how everything works on top of it and how easy those things are to use. A small project can certainly make those changes because they can explicitly ignore compatibility concerns.

A standardized /boot/whatever would offer the same flexibility for the rootfs as an initramfs would. Instead of a duplication of efforts by placing everything into the initramfs for every kernel installed, only the kernel & modules would need to be copied over to the boot volume since the rest of the tools would be standardized and already be there on the file system.

The big changes to the file system hierarchy and the software to patch...I'm not saying it wouldn't be a big pain in the ass, because it would, but, there are the options of shims, legacy compat layers, symlink fustercluck, and more. The scripts are more of a non-issue and you know it because system scripts would be changed and non-system legacy Linux scripts maybe covered by the previous sentence or they may be considered dropped from support.

/etc is the hard one to deal with because so much decided to use it...wait a minute...

Before I go any farther, I'd think I should say that if one wanted to do that then they should pull an Android and say "screw legacy Linux and let's try to become standardized Linux 1.0". When you think about it, distributions are the Wild, Wild West and Android is the closest thing to Standardized Linux 1.0 and that's because they said "screw Legacy compatibility" and I'm fine with that because we can chroot into Legacy and it works so people who need Legacy are already covered. Saying "screw Legacy Linux" is the only way to define your own FSH. From there you'd want to just use containers, chroots, and VMs for traditional Linux systems like we do for Windows or BSD on current Linux systems.

Trying to redefine the FSH while supporting the traditional/current FSH would be a riddled with nightmares like you point out. Unless one really wanted to redefine the traditional GNU/Linux into New/Linux like Google did with Android/Linux, I don't think it would be worth doing.

The line between data and configuration isn't so bad. Defaults under /usr/share and overrides under /etc or $HOME/.config never bothered me nor have I ever considered stuff under /usr/share to even be writable in that context or even to be used as system-wide configuration files. Defaults that shouldn't ever be used go here, root/system wide goes here, per user goes here, with permissions to define config precedence makes sense to me. IMHO, that's pretty simple to define...but I'm also assuming a clear separation and distinction between the base system and applications.

On your conclusion -- which is really why only Google has ever pulled it off with Android. They were able standardize a way to monazite their changes to the FSH.

I think Steam could team up with Red Hat and Lennart to pull off systemd/Linux which, in a way as a systemd user, is sort of what I'm advocating for and is how I think that I'd do it if I had the money, time, and resources.

[betam4x]

Or we can just get rid of initramfs altogether. It's a relic from the past.

[BwackNinja]

A standardized /boot/whatever would offer the same flexibility for the rootfs as an initramfs would. Instead of a duplication of efforts by placing everything into the initramfs for every kernel installed, only the kernel & modules would need to be copied over to the boot volume since the rest of the tools would be standardized and already be there on the file system.

The big changes to the file system hierarchy and the software to patch...I'm not saying it wouldn't be a big pain in the ass, because it would, but, there are the options of shims, legacy compat layers, symlink fustercluck, and more. The scripts are more of a non-issue and you know it because system scripts would be changed and non-system legacy Linux scripts maybe covered by the previous sentence or they may be considered dropped from support.

/etc is the hard one to deal with because so much decided to use it...wait a minute...

Before I go any farther, I'd think I should say that if one wanted to do that then they should pull an Android and say "screw legacy Linux and let's try to become standardized Linux 1.0". When you think about it, distributions are the Wild, Wild West and Android is the closest thing to Standardized Linux 1.0 and that's because they said "screw Legacy compatibility" and I'm fine with that because we can chroot into Legacy and it works so people who need Legacy are already covered. Saying "screw Legacy Linux" is the only way to define your own FSH. From there you'd want to just use containers, chroots, and VMs for traditional Linux systems like we do for Windows or BSD on current Linux systems.

Trying to redefine the FSH while supporting the traditional/current FSH would be a riddled with nightmares like you point out. Unless one really wanted to redefine the traditional GNU/Linux into New/Linux like Google did with Android/Linux, I don't think it would be worth doing.

The line between data and configuration isn't so bad. Defaults under /usr/share and overrides under /etc or $HOME/.config never bothered me nor have I ever considered stuff under /usr/share to even be writable in that context or even to be used as system-wide configuration files. Defaults that shouldn't ever be used go here, root/system wide goes here, per user goes here, with permissions to define config precedence makes sense to me. IMHO, that's pretty simple to define...but I'm also assuming a clear separation and distinction between the base system and applications.

On your conclusion -- which is really why only Google has ever pulled it off with Android. They were able standardize a way to monazite their changes to the FSH.

I think Steam could team up with Red Hat and Lennart to pull off systemd/Linux which, in a way as a systemd user, is sort of what I'm advocating for and is how I think that I'd do it if I had the money, time, and resources.

I agree with you for regular desktop systems, but the question is more generically, "how do I get to my rootfs". You may have a diskless system pxe-booting with your rootfs exported read-only over NFS, and other directories either temporary or read-write mounts otherwise. There you don't have the option to say its just another folder on your rootfs. For your usage it may be unnecessary, but the functionality has to exist either in the bootloader or in the initramfs. The difference there is that the initramfs doesn't have to be operating system agnostic.

I'll push harder on the work necessary to change the filesystem layout because I explicitly want to avoid legacy shims. From the list of issues I've presented and even more that i haven't, I'd say I'm further along with those changes because I'm on the implementation stage, not the brainstorming stage.

Android still has some legacy paths. MacOS also has /bin, /sbin, /usr, and others. Both succeeded as far as they did because they had the resources and no need for compatibility. Starting with your own libc, everything starts by being incompatible and you have to build a userspace on top of that yourself.

People joke about systemd/Linux, but I think the goals are generally expressed poorly. It isn't an init system, its literally THE "system daemon" -- abstracting away details, centralizing access to resources, and generally operating as the interface to the system. I think the most legitimate arguments against it are disagreeing with the definition of "system" that it presents, or disagreeing that an expansive standard should be created at all. We're already talking here about how difficult it is to move away from one standard and how everything previously represented needs a place. I don't like rigid standards because they are stifling. I'm also not a fan of layers of abstraction because you need to understand how something works at the core in order to create a better replacement or even believe that replacement is possible at all. This is again supported by the effort needed and code read to create that partial list of things that need to change in order to move away from the FHS without maintaining compatibility layers.

[bug77]

If you can make it faster, sure, go ahead. But how often di you need to generate a new image anyway? I mean, I'm on arch and it feels like I'd only be doing this once or twice a week.

[anarki2]

I don't get the fuss. We're talking about a few seconds. And only when there's something kernel-related going on, which isn't too often, more like once a week. I mean it's great if they can improve it, but if not, I won't have any sleepless nights.

[betam4x]

I don't get the fuss. We're talking about a few seconds. And only when there's something kernel-related going on, which isn't too often, more like once a week. I mean it's great if they can improve it, but if not, I won't have any sleepless nights.

Those 'few seconds' add up when installing a new kernel that, for example, has several dkms modules, etc. In my case, I have 5 different dkms modules that are installed with every kernel update. Considering the kernel updates several times a month, it can take quite a while to wait for everything to be regenerated. Every second counts.