mkosi-initrd: add option to build generic initrds

[aafeijoo-suse]

That is, add the default kernel modules defined in the mkosi-initrd configuration instead of the loaded modules in the host, and also do not add host-specific configuration.

[DaanDeMeyer]

I think it makes sense to define a bit better what a "generic" initrd is supposed to mean. Is it an initrd that will boot the current local system on any hardware or is it an initrd that can be built by a build system and will be able to boot a variety of different systems. If the first, then crypttab and kernel command line should still be processed. Otherwise, we shouldn't, but then we should probably also mention that the generic initrd is not generic over different kernels, but still tied to a specific kernel version.

[aafeijoo-suse]

I think it makes sense to define a bit better what a "generic" initrd is supposed to mean. Is it an initrd that will boot the current local system on any hardware or is it an initrd that can be built by a build system and will be able to boot a variety of different systems. If the first, then crypttab and kernel command line should still be processed.

I agree, that would open 2 different "generic" modes:

• One with the local conf that could be used with different hw (if I'm not mistaken, this is what initramfs-tools does).
• One without any local conf or current kernel modules (this is the dracut variant).

So, we could have 2 different options or one --generic option with different values.

we should probably also mention that the generic initrd is not generic over different kernels, but still tied to a specific kernel version.

Ok, that should be always the case, since the initrd is always built for a specific kernel, but it doesn't hurt to make it clear.

[DaanDeMeyer]

So, we could have 2 different options or one --generic option with different values.

Would it be acceptable to have --generic only do the "initrd that will boot the local system on any hardware" usecase? I think for the build system use case you'll probably want extra different behavior, for example in that case I don't know if you still want to pick up /usr/lib/mkosi-initrd and such. I don't know if that use case is a good fit to support in mkosi-initrd. So I'd be OK if we make --generic specific to the "any hardware" use case and don't handle the other use case inside mkosi-initrd.

[aafeijoo-suse]

So, we could have 2 different options or one --generic option with different values.

Would it be acceptable to have --generic only do the "initrd that will boot the local system on any hardware" usecase? I think for the build system use case you'll probably want extra different behavior, for example in that case I don't know if you still want to pick up /usr/lib/mkosi-initrd and such. I don't know if that use case is a good fit to support in mkosi-initrd. So I'd be OK if we make --generic specific to the "any hardware" use case and don't handle the other use case inside mkosi-initrd.

For me it's ok at least to decouple the loaded kernel modules from the equation, that should be enough. The "without any local conf" case in dracut is very important, because it also adds part of its custom logic as local conf, but here we don't have that issue. Also, since we install packages, files shipped under /etc should not be local conf at all.