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

[dekkzz78]

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
.

[kiffmet]

This development sounds great for servers with higher security requirements and seems like a logical continuation of the trend around layered, immutable system images.

Even in case of root access, embedding malware into the initrd will become impossible. Start a small hypervisor or xen dom0 this way and it'll greatly increase the chance that you can get rid of an infection just by rebooting the machine (provided that it isn't embedded into a guest VM and can just break out of the VM jail again).

Since not every distribution is going to adopt this new behaviour and regular general purpose distros tend to not use immutable system images, one can just switch over to dracut/mkinitcpio/initramfs-tools/mkinitramfs/genkernel/... if he doesn't like this new initrd concept or even avoid it entirely.

IMO having more options on how to do things is nearly always positive if it's just an opt-in/opt-out kind of thing.

[hamishmb]

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.

This is a little toxic - I made a point of saying I use systemd in an attempt to make it clear that I don't hate it. I also don't hate people who don't like systemd.

I think systemd is doing a lot of cool things, some of which I agree with more than others, but I certainly don't hate it. What I wouldn't like is for large parts of the operating system to depend on systemd, because that removes user choice.

So, even though I personally use systemd, I'm happy that projects like Devuan exist, for example.

[RahulSundaram]

I don't think it's "hate" to have a different preference or listening to systemd's own team as they say, "you always have a choice to use systemd or not".

Now, whether or not "choice" and "freedom" is a goal of systemd? It's certainly a project that wants to "tell you" what is "right and good". Can anyone disagree with that?

Yes, I disagree with that. systemd as a project doesn't tell you anything at all about what is right or good. The project has hundreds of contributors who have submitted a wide variety of features and options. For some core functionality, they are opinionated about how it is implemented but that vast majority of features are optional and can be disabled entirely or fine tuned to fit competing requirements or forked or even replaced completely and the interfaces are documented in https://systemd.io/PORTABILITY_AND_STABILITY/

[cjcox]

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.

I don't think it's "hate" to have a different preference or listening to systemd's own team as they say, "you always have a choice to use systemd or not".

Now, whether or not "choice" and "freedom" is a goal of systemd? It's certainly a project that wants to "tell you" what is "right and good". Can anyone disagree with that?

[ext73]

that's a very bad idea :/

[zbyszek]

Those "new goals" don't sound attractive at all.

If i'm reading in between the lines i see:

* bigger initrd image
* no more user build ones with custom modules (your distribution needs to do that). All you can build is the same as your distribution.
* no emphasis on speed so it's likely slower
* becomes like a black box but with the sidenote that you know what goes in. An "open black box", but you can't change anything.
* forces down the TPM crap on the user
* (i'm guessing) forced security patches from the distributor, as you need to use their signed initrd to even boot (provided you enable TPM or have a motherboard where you can only boot with signed loaders)

You got 0.5 correct out of 6.

The images are currently bigger, and are likely to stay so, but within reason. The most important part is how the kernel is split into subpackages. Right now it's not split at all, so you end up with *most* modules. It's possible that the kernel maintainers in the distro will split things in the future, and then the size difference might change.

It's possible to build things locally. That's what we're doing for development, and it's just an image building program, no magic, so you can always invoke this locally.

The initrd boots faster that the dracut ones.

It's the opposite of a black box: it's the exact same packages you have installed on the system, so you can just use `ls` and `cat`.

TPM use is orthogonal to this. An immutable and reproducible initrd image makes it much easier to use the TPM, but it doesn't depend on it.

Also, even when the initrd is built centrally, it'll be delivered as any package, which you can install or not, as you wish. I don't quite grok how you'd imagine it could be otherwise on an open source system...

[zbyszek]

Okay, good, but will it be usable without systemd?

No, not really. Mkosi-initrd is a way to build initrds from distro packages, so in principle you could configure it to use a different init system, if it is packaged by the distro. But the intent is to focus on systemd and distros that use systemd.

Also, I wonder if this means you then can't make your own initramfs.

Yes, you can. This is what we're doing right now. The intent is to build initrds centrally, but that's something for the future.

Once initrds are built and signed by the distro (for SecureBoot), you'll still be able to build locally, but then you'll have to install your own signing keys (or do without signing).

[arun54321]

Systemd haters: Everything works fine. I cannot tinker endlessly and waste my time with this. this is bad and bloat!!!

[You-]

Because with each new systemd features I get the vibes they want to put more spyware and backdoors in..

Good thing you can read the code to check then.