systemd's mkosi-initrd Talked Up As Better Alternative To Current Initrd Handling

[phoronix]

Phoronix: systemd's mkosi-initrd Talked Up As Better Alternative To Current Initrd Handling

Red Hat engineer and systemd developer Zbigniew Jędrzejewski-Szmek presented on Monday at the Linux Plumbers Conference on a new design for inital RAM disks (initrd) making use of the new systemd mkosi-initrd project...

https://www.phoronix.com/news/LPC-20...d-mkosi-initrd

[hamishmb]

Okay, good, but will it be usable without systemd? I use systemd myself, but I don't especially want all the new shiny features to only work for people using systemd - it's nice to have choice.

Also, I wonder if this means you then can't make your own initramfs. I had to do that when I tried btrfs back in the day.

Didn't go well, but it was a long time ago, and I used the ext4 converter despite being told not to in the documentation, so *shrug*

[Vorpal]

This does not sound great. I have an older computer that is perfectly usable except initramfs loading by grub takes 10 seconds. (It is a bios only system, so no systemd-boot is not an option.)

However I tried to boot it with a generic non-system specific initrd at one point (turning off the auto detect hook on Arch Linux). That took 45 seconds to load.

Given that... Nope, not interest in generic initramfs.

[sinepgib]

This does not sound great. I have an older computer that is perfectly usable except initramfs loading by grub takes 10 seconds. (It is a bios only system, so no systemd-boot is not an option.)

However I tried to boot it with a generic non-system specific initrd at one point (turning off the auto detect hook on Arch Linux). That took 45 seconds to load.

Given that... Nope, not interest in generic initramfs.

I doubt this is gonna be fast too, BUT it does say it would rely on sysexts so there should be an option to build upon leaner images, so maybe you can use a minimal initramfs instead of a giant one like generic initrds are right now.

[juxuanu]

It's nice, but sometimes you need to modify your initrd. Add modules, etc.

[mirmirmir]

Okay, good, but will it be usable without systemd? I use systemd myself, but I don't especially want all the new shiny features to only work for people using systemd - it's nice to have choice.

So you're saying you expect a feature from other software that dont provide it? 🤔

I might sound toxic. I just don't understand people who hate systemd. That's just dumb.

[Vorpal]

I doubt this is gonna be fast too, BUT it does say it would rely on sysexts so there should be an option to build upon leaner images, so maybe you can use a minimal initramfs instead of a giant one like generic initrds are right now.

That sounds nice in theory, but I expect things like encryption, mdraid and LVM2 will be sysexts. Most of the space wastage in generic initramfs were from all the storage drivers last I looked (a few years ago). Unless you have a separate sysext per SATA driver, keyboard driver etc I don't see this being small.

[sinepgib]

So you're saying you expect a feature from other software that dont provide it? 🤔

systemd (the project) is a big umbrella, so it isn't unlikely that mkosi-initrd is compatible with inits other than systemd (the init). It is a valid question.

I might sound toxic. I just don't understand people who hate systemd. That's just dumb.

It's not always about hate. Some people would rather not have glibc and use musl instead, some people like pid 1 to be more restricted to achieve extra robustness, some need to cover specially constrained environments for which systemd is either not ideal or not even appropriate, etc. Of course there are haters and they're quite vocal and toxic, but there's also a wider umbrella of people who would rather not use systemd (or not use it in all of their systems).
I personally am fully on board with systemd, but I like some of the things s6 propose and would like to give it a try (although it's not ready for prime time due to lack of a sensible frontend).

[sinepgib]

That sounds nice in theory, but I expect things like encryption, mdraid and LVM2 will be sysexts. Most of the space wastage in generic initramfs were from all the storage drivers last I looked (a few years ago). Unless you have a separate sysext per SATA driver, keyboard driver etc I don't see this being small.

Yes, I also had that in mind when saying it's probably still not going to be fast. It's good in theory but unlikely to be exploited for that. That said, most of that should be compiled into the kernel IMO, and it isn't what takes the most space.

[Vorpal]

Yes, I also had that in mind when saying it's probably still not going to be fast. It's good in theory but unlikely to be exploited for that. That said, most of that should be compiled into the kernel IMO, and it isn't what takes the most space.

I would rather not see it compiled into the kernel. That is RAM you never get back. Unused modules don't have to be loaded, and as far as I know the initramfs is freed after switching to the actual root file system. On my main laptop with 32 GB RAM? Who cares. On the bios only system i mentioned, with 2 GB RAM? Yeah, it is actually starting to matter. On even more constrained systems it gets worse of course.