fix(dracut): install items after including modules

[bdrung]

Users or distributions might request installing additional binaries (like cat or rm) via --install or --install-optional. These binaries could be provided by different projects (like coreutils or busybox). Installing those files before including the modules will enforce specific implementations (e.g. use cat from coreutils instead of busybox).

Install those files after including the modules to allow the modules (like busybox) to pick an implementation. For example: If dracut is called with --install cat and busybox includes the cat applet, the inst_multiple -o cat will become a no-op.

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[devkontrol]

In my mental model, dracut invocation command line options have higher priority than built-in dracut module logic.

In other words, in case of a conflict, command line should overrule dracut module, and not the other way around.

This PR appears to make an exception for this mental model for the --install command line option. Before proceeding with the discussion, is my understanding correct here ?

[bdrung]

Dracut invocation command line options have higher priority than config file settings.

In my mental model, --install just says that this thing should be in the initrd. If you want something explicit, you could use --include.

[devkontrol]

In my mental model, --install just says that this thing should be in the initrd. If you want something explicit, you could use --include.

I think --install and --include are not different in this regard, so if this PR lands, than it should also change the ordering of --include

This PR by definition is a compatibility break, probably best to highlight it.

Dracut invocation command line options have higher priority than config file settings.

What I meant is that command line arguments like --install or --include should behave like dracut module ordered as 00 dracut module ordering.

[bdrung]

I think --install and --include are not different in this regard, so if this PR lands, than it should also change the ordering of --include

I checked the code and --include is done even later than that (search for include_src). So I moved the code for install further down to get those two closer together.

This PR by definition is a compatibility break, probably best to highlight it.

I created #2513 for tracking what we should mention in the release notes.

[devkontrol]

I checked the code and --include is done even later than that (search for include_src). So I moved the code for install further down to get those two closer together.

This would then imply that dracut was already inconsistent and there is no good mental model established between dracut module ordering and command line ordering when there is a conflict. One could argue that this PR makes dracut more consistent. I was hoping we could use this PR as a motivation to establish and document a new reasonable mental model if there is not one.

Would the following work as a mental model going forward, that we could add to the documentation as well not just to the release notes ?

Command line arguments (and corresponding configuration presets) --install and --include should execute after the dracut modules have been installed and behave similarly to dracut modules with 99 module ordering._

[devkontrol]

Based on my experience, @aafeijoo-suse has a great eye for compatibility risk. @aafeijoo-suse can you help review this PR ? Thanks !

[devkontrol]

Counterpoint for this PR from Claude

busybox override pattern (most likely to bite people)
A common config is enabling the busybox dracut module for size, while explicitly forcing specific full-featured binaries via install_items+=" cat rm mount ..." in dracut.conf.d — done precisely to avoid busybox's leaner applet semantics (different flag support, locale handling, error codes) for scripts/hooks that depend on GNU-specific behavior. After this patch, that override stops working silently — no error, no warning, the initramfs just ends up with busybox's implementation instead of the one the config explicitly requested. This is a runtime/boot-behavior regression, not a build failure, so it's the kind of thing that surfaces as "my rescue shell 'cat' behaves differently since I upgraded dracut" bug reports weeks later.

Because the new position runs after the fstab-lines//etc/fstab generation block (which uses >> append, not truncate), an --installed seed file at /etc/fstab would now be skipped if dracut's own fstab-writing logic already created the file, silently dropping the user-supplied content — reversed from the old behavior where the seed file was installed first and dracut appended to it. Niche, but worth a regression test given nobody's added one.

[aafeijoo-suse]

Yes, this change is very dangerous... it may not affect Ubuntu because it recently adopted dracut, but it will certainly have side effects.

[bdrung]

Hm, so we want users to be able to enforce including stuff at the beginning.

What does Fedora want to do in dracut.conf.d/fedora/01-dist.conf with:

# always install the following binaries to allow to debug and correct initrds in rescue shell
install_optional_items+=" vi /usr/libexec/vi /etc/virc ps grep cat rm chroot "

My understanding is that they want to have those binaries, but do not care about the implementation.

[devkontrol]

What does Fedora want to do in dracut.conf.d/fedora/01-dist.conf with:

# always install the following binaries to allow to debug and correct initrds in rescue shell
install_optional_items+=" vi /usr/libexec/vi /etc/virc ps grep cat rm chroot "

Just recently there is some discussion on this, I hope it is not completly off-topic -

vi/vim were both managed via alternatives

https://discussion.fedoraproject.org/t/dracut-fails-to-build-initramfs-on-fedora-44-due-to-neovims-broken-lpeg-so-needed-entry/196691/

@pvalena @Conan-Kudo

[pvalena]

IMHO this proposed change might not addresses the issue the right way -- I think inst_* should just instead of copying just do a lazy install -- create a 'list' of intems to copy later (and the relevant sources) -- and only after everything is prepared (from modules and other sources), the transaction is made, incl. the dependency chain.

This would avoid the issue by simply rewriting the original source (for install) by a new one for particular destination. The behavior is similar to DRACUT_RESOLVE_LAZY, but for main install item instead.
(And if we want to preserve the original behavior we just skip updating the source for the items in the list; we could even have this as an option.)

But this completely changes the behavior of what gets to be kept in the initrd (currently nothing never get overwritten AFAIU).

In any case this situation is just a variant of a dillema -- users have configs, which should probably have precedence, but it seems in some cases it "might be better" to override it from a module (as this PR intends); but how can we tell which is case is it?

In the same way, I might want to install a specific binary from a specific path, and I'd like the option/arg/config to take precedence over what any module wants to install.

[pvalena]

It's also moved inside if [[ $kernel_only != yes ]]; then ... so it gets ignored completely on kernel-only?