fix(dracut.sh): append to kernel cmdline instead of override in uefi

[Fahrj]

Thanks for your great work and please advise if I should open an issue additionally/instead! :)

When creating an EFI executable with both hostonly_cmdline=yes and kernel_cmdline=" quiet " in the config file, I would expect that both cmdline parameters for my current host and the quiet parameters provided in kernel_cmdline would be added to the UEFI kernel cmdline. What happens instead is that kernel_cmdline=" quiet " takes priority and overrides any arguments stored due to hostonly_cmdline=yes, resulting in overall parameters of only " quiet " and thus non-booting executables.

Looking at the docs I get the impression that this is a bug rather than intentional behavior:

hostonly_cmdline="{yes|no}" If set to "yes", store the kernel command line arguments needed in the initramfs. If hostonly="yes" and this option is not configured, it’s automatically set to "yes".

kernel_cmdline="parameters" Specify default kernel command line parameters.

This change might be considered breaking, since calls with both hostonly_cmdline=yes and extra parameters in kernel_cmdline will behave differently, e.g. when giving both hostonly=yes as well as mount parameters in kernel_cmdline?

If needed I could also attempt to clarify the documentation in this regard?

Changes

For EFI executables, if both kernel_cmdline and hostonly_cmdline are provided, both are taken into account and appended to the UEFI kernel cmdline instead of kernel_cmdline taking priority.

Checklist

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

[Fahrj]

Yes, it breaks the current behavior implemented in 2015 (https://github.com/dracutdevs/dracut/commit/636d2d46a537a5235a18dc2cf2429d729c343bf8), so I'm not sure about this...

I'm not sure I understood what you are not sure about; whether I should adapt the docs, or not to change this and clarify in the docs that kernel_cmdline overrides hostonly_cmdline?

As mentioned before I believe this to be buggy rather than intentional, and the breaking changes would thus break old configs to the better, but please correct me! :)

To give more detail:

I want to build an EFI executable for my host running debian testing, so I'm using the config options hostonly=yes (and additionally hostonly_cmdline=yes, which should not be necessary but for completeness), because I trust dracut to generate the correct UEFI cmdline for my luks, lvm, and mount setup. This works flawlessly and generates the following parameters: rd.luks.uuid=..., rd.lvm.lv=..., root=..., rootfstype=..., rootflags=....

Now, all I want to achieve is to add quiet as an additional parameter. The moment I add kernel_cmdline=" quiet " to the config file, however, the final UEFI cmdline only contains quiet and nothing else, despite the log informing me what kernel commandline parameters have been stored in the initram due to hostonly_cmdline=yes.

Currently I found two ways of achieving the desired result:

1. Hardcode the entire kernel commandline in the kernel_cmdline option in the config file. While this works, it feels weird to me to hardcode something that dracut can (and does) generate automatically. Additionally, I cannot simply re-use this config file on other hosts, since the hardcoded parameters only work for my machine.
2. Create the non-existing folder /etc/cmdline.d/, place a file 99-dracut.conf with the content quiet, and add install_items+=" /etc/cmdline.d/99-dracut.conf " to dracut's config file. The resulting config file is machine-independent, but the setup is rather tedious and most of all this approach is not really documented anywhere.

With the changes of this MR, I could simply add kernel_cmdline=" quiet " to the config file, which would be prepended to all parameters automatically generated by hostonly_cmdline=yes.

[stale[bot]]

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

[stale[bot]]

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

[Fahrj]

I still consider the current behavior a bug.

Neither the code nor the documentation has changed on master; I'm happy to help with both!