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

[hax0r]

I almost saw 'systemd-ntoskrnl' in the title.

[hamishmb]

Recently Devuan project got their repository key expired. Says quite a lot about systemd haters' competency.

Not sure it's fair to call them sytemd haters either, without citing something.

It's a bit of a blunder, but accidents happen. I'd have been quite annoyed if I used Devuan, to be fair.

[some_canuck]

Let me off lennart's wild ride, I don't want to do this anymore...

[NobodyXu]

Ultimately I think kernels should come if their own built-in initrd, carrying modules for 99% of storage modules so you can mount your basic rootfs without another kernelspecific initrd. In fact, don't ever touch the inirtd, should be just an extension of the kernel to mount stuff and run the rest of the current initramfs functionality on your (potential reduced functionality) rootfs.

If you pack all modules insides kernel, then why build then as modules in the first place?
You can compile these stuff directly into the kernel.

Though for drivers which requires external non-opensource firmwares, you still need to build them as modules.
Otherwise, you would need to also compile these firmwares into the kernel, which violates the license.

[jacob]

So for this to work, it seems you need to use systemd, TPM and any bugs get passed off to package maintainers?? Hmm smacks of being 100% useful for business users yet fucks up everyone else. No surprise i's RedHat crap
.

In case you didn't notice, RedHat's customers ARE business users. It can also be very useful for desktops though, particularly immutable ones like Silverblue. If you want to tinker with your kernel and initramfs image, just use a distro better suited for that, like Arch or Debian.

[discordian]

If you pack all modules insides kernel, then why build then as modules in the first place?
You can compile these stuff directly into the kernel.

As built-in they always will take RAM, the initrd will be dropped when switching to the rootfs, so it only takes space on the boot partition. There is no big disadvantage, nowadays storage drivers are in an extra initrd, packing them with the kernel and compressing everything might even save space.

[NobodyXu]

As built-in they always will take RAM, the initrd will be dropped when switching to the rootfs, so it only takes space on the boot partition. There is no big disadvantage, nowadays storage drivers are in an extra initrd, packing them with the kernel and compressing everything might even save space.

The problem is not the RAM/disk usage, it's the licensing.
If initrd is put into the kernel, then so does the firmware or other closed-source drivers (Nvidia).
That is a clear violation of GPL 2.0 since the distros redistribute the compiled kernel with non-GPL stuff.

[discordian]

The problem is not the RAM/disk usage, it's the licensing.
If initrd is put into the kernel, then so does the firmware or other closed-source drivers (Nvidia).
That is a clear violation of GPL 2.0 since the distros redistribute the compiled kernel with non-GPL stuff.

Moving goalposts? Read the postimgs, put them in context. I was talking about essential storage drivers, and you asked why I am not building them directly into the kernel, but using a built-in initrd.

Can't have it both ways

[NobodyXu]

Moving goalposts? Read the postimgs, put them in context. I was talking about essential storage drivers, and you asked why I am not building them directly into the kernel, but using a built-in initrd.

Can't have it both ways

Oh I have misread your original comment.

So you want the kernel to have their own built-in initramfs which can mount any partition/disk out there, by including the modules (or compiled into the kernel) and includes a simple userspace like busybox?

Yeah, that sounds reasonable.

[sinepgib]

Not sure it's fair to call them sytemd haters either, without citing something.

It's a bit of a blunder, but accidents happen. I'd have been quite annoyed if I used Devuan, to be fair.

Most of Devuan in particular does use somewhat of a hate speech towards systemd, so they are haters in my book. Probably not all of their users are tho.

I use systemd fully but it's really done a bad job at getting any kind of adoption in the embedded space.

That said, the embedded space tend to use their own dumb methods of booting so I don't think this would apply there anyway.

There are some important issues with systemd on embedded. Or maybe not as important as the people doing them make themsound, but whatever. The main one is glibc is rather heavy for embedded (citation needed, developers kinda assume it but then many "embedded" devices have 1+GB of RAM and several GB of storage space) and systemd is pretty much married to it. Then there are some less dramatic issues like journald not being optional at all (you can make it so it only proxies logs, but you can't avoid loading it), so it wastes a little bit of RAM. There was once an experiment to use it on embedded that used about 6MB of RAM but, as you said, it never really caught up.