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

[betam4x]

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.

Regarding systemd: People may hate on it, but IMO, it's the best thing to happen to Linux in a long time. Why? Because it unifies something that was once very fragmented. If only the Wayland team had taken this approach...

Anyways, I've actually been toying with the idea of having the rootfs itself only include /boot, a read only root file system, core configuration, and drivers. No coreutils or application data, just the basic stuff to get to the point where docker can start. As soon as the system is able, it boots one or more docker containers with all the userland stuff. The entire system embraces flatpak for the userland stuff where possible, and ideally the setup would be transparent to the end user. I'm still exploring it, of course. There are huge advantages to doing so, however. It's still just a concept, and it may evolve over time.

I'm also looking at a way to perform an early boot Xorg + DE rescue environment for repairs. Instead of being dropped to a console in rescue mode, you would get dropped to the GUI with many intuitive GUI based repair tools as well as the ability to launch a terminal (of course). This gives you the advantage, for example, of having a graphical web browser among many other things. Also just a concept.

[BwackNinja]

Regarding systemd: People may hate on it, but IMO, it's the best thing to happen to Linux in a long time. Why? Because it unifies something that was once very fragmented. If only the Wayland team had taken this approach...

Anyways, I've actually been toying with the idea of having the rootfs itself only include /boot, a read only root file system, core configuration, and drivers. No coreutils or application data, just the basic stuff to get to the point where docker can start. As soon as the system is able, it boots one or more docker containers with all the userland stuff. The entire system embraces flatpak for the userland stuff where possible, and ideally the setup would be transparent to the end user. I'm still exploring it, of course. There are huge advantages to doing so, however. It's still just a concept, and it may evolve over time.

I'm also looking at a way to perform an early boot Xorg + DE rescue environment for repairs. Instead of being dropped to a console in rescue mode, you would get dropped to the GUI with many intuitive GUI based repair tools as well as the ability to launch a terminal (of course). This gives you the advantage, for example, of having a graphical web browser among many other things. Also just a concept.

It depends on your goals. If you're just trying to get something high level done, any standard is better than none. If you're exploring lower level ideas, it only gets in the way. If wayland did that, we wouldn't have projects like wlroots as well as the standards established by the community and it would only validate Mir existing as a non-wayland compositor, even just as an IoT solution.

It sounds like you're mostly looking for an initramfs. Ideas are one thing, it would be more interesting in you implemented at least part of that.

[skeevy420]

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.

Darmok and Jalod at Tenagra.

But seriously, that would vary by the distribution and what they're trying to accomplish. I imagine that most things would work just like they do now for systems that rely on a bootloader since my main goal of no initramfs or /boot merge is just to remove the archive portion and standardize the tools available and do things like betam4x describes. I haven't used any network booting system in long enough time to comment there.

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.

My current method is leaving everything as is. I'm still in the process of getting all my ZFS datasets laid out. I've adopted Silverblue/OSTree's /var/home, /var/usrlocal (I call it /var/local), and a few others of my own like moving /root to /var/home/root, but that's about it.

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.

I know. Android is the best I can think of that both uses the Linux kernel and does its own thing in regards to the file system and even it has legacy cruft.

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.

This is where it gets difficult. Will someone have to call the current "no standard GNU/Linux" as the Linux 1.0 standard to even go forward? If they're using their own custom libc and the userspace is different, does it become a new distribution or a new OS?

But I think some form of systemd/Linux, for a lack of a better term for our discussion, is the way forward regardless of ones feelings of standards and that something like Wine will be needed for older and/or closed sourced programs (ok, games). It's either keep on keeping on and making everything work with everything or picking a core set of tools, standardizing those, and writing a new system and userspace around that (yeah, the Apple method).

[BwackNinja]

This is where it gets difficult. Will someone have to call the current "no standard GNU/Linux" as the Linux 1.0 standard to even go forward? If they're using their own custom libc and the userspace is different, does it become a new distribution or a new OS?

But I think some form of systemd/Linux, for a lack of a better term for our discussion, is the way forward regardless of ones feelings of standards and that something like Wine will be needed for older and/or closed sourced programs (ok, games). It's either keep on keeping on and making everything work with everything or picking a core set of tools, standardizing those, and writing a new system and userspace around that (yeah, the Apple method).

OS is all about expectations of compatibility. systemd/Linux as referenced may materialize, but I hope to have a viable alternative before that happens. If a standard has to exist, I'd like it to be as minimal and easy to discard as possible.

[discordian]

dracut is insanely fat, it needs systemd + udev and a metric ton of userspace tools on the initramfs. I really dont see many usecases where this would help over the way simpler initramfs-tools (which needs not much more than busybox).

[BwackNinja]

dracut is insanely fat, it needs systemd + udev and a metric ton of userspace tools on the initramfs. I really dont see many usecases where this would help over the way simpler initramfs-tools (which needs not much more than busybox).

If you're running systemd anyway, there's no point in maintaining a separate init system and scripts for your initramfs. Udev is necessary because it provides predictable device names for drives -- by uuid and label -- because /dev/sda1 is not necessarily a stable name (and when it is, that's handled by udev anyway).

[discordian]

If you're running systemd anyway, there's no point in maintaining a separate init system and scripts for your initramfs. Udev is necessary because it provides predictable device names for drives -- by uuid and label -- because /dev/sda1 is not necessarily a stable name (and when it is, that's handled by udev anyway).

No, you don't need udev for that:

http://man7.org/linux/man-pages/man8/findfs.8.html

This is also not about systemd, but copying everything into the initramfs, which shares little to no services with the final system.
And Dracut is a bunch of maintained scripts (does some funny things like polling devices since systemd is not used for that), not really possible to separate the root and initramfs (means a broken systemd will kill the initramfs aswell), and a pain to setup if you want to use it somewhere else than the running system.

Unless you have some complicated setup, with needing udev to load multiple layers of drivers, I don't see the big appeal.

[brent]

It might be slow, but: does it really matter that much? We're still talking seconds here. A speed-up is nice to have for sure, but it's not a big deal.

[letrout]

It might be slow, but: does it really matter that much? We're still talking seconds here. A speed-up is nice to have for sure, but it's not a big deal.

You're more patient than I am. I only start my car a couple times a day, some days not at all. But if it took an extra 5 seconds to fire up each time I'd probably get a different car.

[geearf]

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.

It's also longer when you have multiple kernels installed.
Having only one looks like a good way to have a dead system to me, so I always have a few, just in case (at least lts and latest, but lts may not support some newer feature and not work, like when I compressed my fs to zstd, so I have a few variants of latest too).
It'd be nice if initramfs creation could be done in parallel