mkosi-initrd: add some autodetection logic if output is not specified

[aafeijoo-suse]

Make use of installation layout (bls, uki, other...), $BOOT_ROOT partition and entry token provided by kernel-install.

[behrmann]

I'm not convinced it's a good idea to redo this logic, that's the purview of kernel-install in mkosi-initrd.

[DaanDeMeyer]

I guess suse hasn't adopted kernel-install yet because it doesn't do any of the snapshot stuff that suse needs. But then I wonder if this shouldn't live in the suse packaging scriptlets. How is this handled with dracut?

[aafeijoo-suse]

I'm not convinced it's a good idea to redo this logic, that's the purview of kernel-install in mkosi-initrd.

I tend to disagree. kernel-install if for adding initrds and kernels, but under some uses cases (e.g. a package update, any configuration change on the system, etc.) only the initrd must be regenerated.

[aafeijoo-suse]

I guess suse hasn't adopted kernel-install yet because it doesn't do any of the snapshot stuff that suse needs. But then I wonder if this shouldn't live in the suse packaging scriptlets. How is this handled with dracut?

You're right, kernel-install is not being used yet, but it's always installed and some configuration tweaks are being used with systemd-boot installations. But one thing is installing kernels + initrds, and other is regenerating only the initrd. As you guessed, dracut has it's own auto detection logic of the output file, but I want to be closer to what kernel-install already provides, which is the same as being closer to upstream systemd.

[behrmann]

I tend to disagree. kernel-install if for adding initrds and kernels, but under some uses cases (e.g. a package update, any configuration change on the system, etc.) only the initrd must be regenerated.

But that's then very specific to how Suse usecase, isn't it? For bls one would need to write a loader config, which referenes the kernel and for uki one needs a kernel to marry it to the initrd to get a UKI. The idea of kernel-install, at least as far as I see it, is that doing kernel-install add with the same version should do what you want it to do, which is why I'm a bit hesitant to put this here as well, since e.g. layouts are a kernel-install concept.

[aafeijoo-suse]

But that's then very specific to how Suse usecase, isn't it?

Nope, this does not fix SUSE's btrfs snapshots use case...

For bls one would need to write a loader config, which referenes the kernel

This feature is not intended for that, it just wants to regenerate the initrd only of existing boot loader entries. At SUSE we have defined 2 rpm macros (%regenerate_initrd_post[trans]), which are called from other rpm packages when they require the initrd to be rebuilt after an installation/update. So, the goal is not to create new complete boot loader entries on the ESP (or on the old /boot it the layout is "other"), but just to build the (existing) initrd again. I don't think that this is a SUSE-specific use case, but unfortunately I don't know what other distros do with mkinitcpio or mkinitramfs, but those using dracut most of the time do not need to specify an output file.

and for uki one needs a kernel to marry it to the initrd to get a UKI.

Thanks for this point, you're right, I was missing the "UKI concept" here, so yes, for UKI's this logic does not make any sense.

which is why I'm a bit hesitant to put this here as well, since e.g. layouts are a kernel-install concept.

I'd say that this auto-detection logic is a nice to have feature, but it's not critical if finally it's not included.

[DaanDeMeyer]

@aafeijoo-suse If you're intending to use this from packaging scriptlets, how do you handle cleanup? Won't the packaging scriptlets need to know the actual output directory regardless so they can clean up old initrds? Usually the kernel version is somehow encoded in the initrd file or path in the ESP so if that changes mkosi wouldn't be able to clean up old initrds itself and this would have to be done by the caller.

[aafeijoo-suse]

@aafeijoo-suse If you're intending to use this from packaging scriptlets, how do you handle cleanup? Won't the packaging scriptlets need to know the actual output directory regardless so they can clean up old initrds? Usually the kernel version is somehow encoded in the initrd file or path in the ESP so if that changes mkosi wouldn't be able to clean up old initrds itself and this would have to be done by the caller.

Package scriptlets are just one of the know use cases, and the clean-up is not handled there. I think it's more important now since we are building initrds from packages, if e.g. only the util-linux package is updated, it will need to trigger the rebuild of the current initrd somehow, otherwise there is version mismatch between util-linux in the initrd and util-linux after switching root.

Other common use case is a user who needs to manually rebuild the initrd after a configuration change that can affect the system startup. But of course, he could manually specify the output file.

[DaanDeMeyer]

@aafeijoo-suse If you're intending to use this from packaging scriptlets, how do you handle cleanup? Won't the packaging scriptlets need to know the actual output directory regardless so they can clean up old initrds? Usually the kernel version is somehow encoded in the initrd file or path in the ESP so if that changes mkosi wouldn't be able to clean up old initrds itself and this would have to be done by the caller.

Package scriptlets are just one of the know use cases, and the clean-up is not handled there. I think it's more important now since we are building initrds from packages, if e.g. only the util-linux package is updated, it will need to trigger the rebuild of the current initrd somehow, otherwise there is version mismatch between util-linux in the initrd and util-linux after switching root.

Other common use case is a user who needs to manually rebuild the initrd after a configuration change that can affect the system startup. But of course, he could manually specify the output file.

The thing I'm worried about is that we just don't have sufficient information to make this work. On Fedora, the initramfs in /boot includes the kernel version in its name. That's just something we can't autodetect in mkosi-initrd so there always would be some manual configuration to be specified.

[aafeijoo-suse]

The thing I'm worried about is that we just don't have sufficient information to make this work. On Fedora, the initramfs in /boot includes the kernel version in its name. That's just something we can't autodetect in mkosi-initrd so there always would be some manual configuration to be specified.

Yes, there is a lot of divergence nowadays with the expected output in each distro. Some standardization work has started here: uapi-group/specifications#100

And in my view, I'd like to implement something like this: uapi-group/specifications#100 (comment)

But maybe the spec should be written first, and then this PR could implement that. What do you think?

[behrmann]

But maybe the spec should be written first, and then this PR could implement that. What do you think?

I think that's a good idea. Having a draft spec and seeing whether we can get others onboard and implementing that, makes sense to me.