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

[jacob]

While it's true there's now an open kernel component, it's still not a drop-in replacement for the current one AFAIK, and it certainly doesn't support as many cards as the (fully) closed driver.

I could be wrong but I thought the plan was to eventually fully migrate to the open kernel module?

[sinepgib]

I could be wrong but I thought the plan was to eventually fully migrate to the open kernel module?

I think that's true for relatively recent cards, but it's not the case of previous generations.

[pal666]

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.

those crazy people will have choice - use their own initrd tools

[pal666]

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

keep us posted

[tachi]

Without knowing the details I don't see why it wouldn't.

Nvidia kernel modules have to be compiled on the host as far as I know (that's what happens when installing the nvidia-driver package on Debian for instance), and then the initramfs has to be updated too.

If everything has to be signed by the distro, the host simply cannot update the initramfs after compiling the Nvidia kernel modules, and this amazing trust chain can't be applied.

Edit: to reply to the various comments posted after the quoted one, I still thinks this is an issue. General-purpose distros cannot simply require you to use a Geforce RTX 2000 or newer, so I unfortunately think that this isn't going to be widely implemented anytime soon.

[jacob]

Nvidia kernel modules have to be compiled on the host as far as I know (that's what happens when installing the nvidia-driver package on Debian for instance), and then the initramfs has to be updated too.

If everything has to be signed by the distro, the host simply cannot update the initramfs after compiling the Nvidia kernel modules, and this amazing trust chain can't be applied.

Edit: to reply to the various comments posted after the quoted one, I still thinks this is an issue. General-purpose distros cannot simply require you to use a Geforce RTX 2000 or newer, so I unfortunately think that this isn't going to be widely implemented anytime soon.

The nVidia module must be built from source in the general case, if the distro can't assume which kernel version and config is being used. That's why Debian does it. But on Fedora or Ubuntu, running custom kernels is more or less unsupported and I don't know if anyone amongst their user bases ever bothered to do it. Nothing stops those distros from packaging and signing a binary nvidia.ko built for the kernel they're shipping.

I'd also say that if you want to run a self-built kernel and initramfs, the whole point of being able to sign it with the distro's key is moot. You're on own to make sure that what you run is not compromised.

[tachi]

The nVidia module must be built from source in the general case, if the distro can't assume which kernel version and config is being used. That's why Debian does it. But on Fedora or Ubuntu, running custom kernels is more or less unsupported and I don't know if anyone amongst their user bases ever bothered to do it. Nothing stops those distros from packaging and signing a binary nvidia.ko built for the kernel they're shipping.

I'd also say that if you want to run a self-built kernel and initramfs, the whole point of being able to sign it with the distro's key is moot. You're on own to make sure that what you run is not compromised.

I wasn't thinking about custom kernels, and don't think that Debian currently does things the way it does because of custom kernels - if you're building tarballs from kernel.org you can also install the drivers from the Nvidia website.

I think that they do things the way they do because, just like Ubuntu, they ship different kernel packages (different versions, normal vs cloud vs rt releases, etc). They could ship n different drivers though (as they already do to support older cards), if the license permits it; package managers should be able to handle dependency versions just fine.

To be clear, I'd love this to become a reality, but I was pointing out some of my main concerns

[arQon]

Or put differently, i don't want this new system. I see no benefit at all from a user point of view.

Then it's a good thing user benefit isn't the point, isn't it.

This is just yet another landgrab by systemd, because the more pieces of the system you co-opt the harder it is to remove the dependency you artificially induce a few months later. "Cancer" really is the perfect analogy for it.

At this point, there's been so much poor handling of things by the systemd team that even on the rare occasions that they actually produce something beneficial, you have to take a step back and work out the ways in which it could be abused by a malicious actor, the same way you do when MS suddenly joins a standards group and starts pushing some extensions they'd like added to it.

[arQon]

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.

The RAM wastage is less of a problem than the pettiness of journald inserting itself into the system in such a way that it can't be removed even if unused and unwanted, despite the constantly-repeated lie of systemd being "modular".
The fact that journald also insists on trying to burn multiple GB of storage on binary bullshit duplicated logs is usually a bigger issue than the handful of MB it uses, even on embedded systems, because anything with enough RAM to run that monolithic mess in the first place can probably afford to waste another 6MB for no reason.

[sinepgib]

The RAM wastage is less of a problem than the pettiness of journald inserting itself into the system in such a way that it can't be removed even if unused and unwanted, despite the constantly-repeated lie of systemd being "modular".

This is not relevant to whether or not it's appropriate for embedded use.

The fact that journald also insists on trying to burn multiple GB of storage on binary bullshit duplicated logs is usually a bigger issue than the handful of MB it uses, even on embedded systems, because anything with enough RAM to run that monolithic mess in the first place can probably afford to waste another 6MB for no reason.

It doesn't if you don't tell it to. As I said in the post you quoted, you can stop it entirely from actually logging anything, be it to disk or to RAM. So the only real, technical reason, you wouldn't want journald in an embedded system is that it's generally a bad idea to waste RAM and disk in something you don't use in an embedded system, no matter how little it is. It's also always more bug surface FWIW.
Regardless, if you decide to use either one solution to produce logs, common sense is using only one of them: if you set journald to log, then don't run a syslog daemon, and conversely, if you want a syslog daemon, just set journald to proxy-only mode.