fix(dracut-systemd): systemd-gpt-auto-generator should not run when root is unset

[savyajha]

systemd-gpt-auto generator runs when root=<device> is not set on the
kernel cmdline. It doesn't work even if root=<device> is set by dracut
in the stored command line. For systemd-gpt-auto-generator to not run,
one either needs to explicitly set a root= parameter or set
rd.systemd.gpt_auto=0 on the kernel cmdline.

Since we do not have control over the command line passed to the kernel,
the easiest way to bypass this is to delete the generator when the root
parameter is set.

Fixes #1709

Signed-off-by: Savyasachee Jha hi@savyasacheejha.com

This pull request changes...

Changes

Deletes systemd-auto-gpt-generator at runtime if the root= parameter is set.

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

It has been (extensively) tested on Fedora 35 running systemd 249 (v249.9-1.fc35) and dracut v55.

Fixes #1709

[savyajha]

@johannbg I am, again, sorry for pinging you but would you wish me to run any more tests on this? I got a friend to do this on Arch Linux and it worked for him too. I've tried this on my Debian box and it works fine.

[stale]

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]

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.

[LaszloGombos]

@savyajha Can this bug be reproduced with a test case like TEST-04-FULL-SYSTEMD using qemu ?

This would help to understand the problem, justify the PR, and guard against future regressions.

[stale]

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.

[LaszloGombos]

Related - random-archer/mkinitcpio-systemd-tool#70

[stale]

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.

[johannbg]

Deleting the generator is a workaround not a fix
That said I'm somewhat failing to understand the problem here
If root is unset the generator is not run https://github.com/systemd/systemd-stable/blob/b622e95f2f59fcb58e23ddafed745eee26a0f52f/src/gpt-auto-generator/gpt-auto-generator.c#L833

I should probably mention that systemd only uses
/usr/lib/kernel/cmdline /etc/kernel/cmdline /proc/cmdline
and ignores everything else
If by It doesn't work even if root=<device> is set by dracut in the stored command line.
Then that's by design in systemd and the bug is we need to start using the correct kernel commandline file path as in stop using
/etc/cmdline.d/*.conf /etc/cmdline
And start using
/usr/lib/kernel/cmdline /etc/kernel/cmdline
( which we need adapt it at somepoint ), which is what systemd uses.
I'm a bit curious if things work for you if you use /etc/kernel/cmdline to rule out any bugs in the generator itself or on systemd's behalf.

What does the non working kernel commandline look like?

[savyajha]

It didn't work for me. The stored command line was rd.md.uuid=<uuid> root=zfs:rpool/ROOT/debian rootfstype=zfs rootflags=rw,relatime,xattr,posixacl. It didn't work for either /etc/kernel/cmdline or /usr/lib/kernel/cmdline.

I should note that I normally have a long grub commandline. The kernel line in my grub.cfg typically looks like this: /vmlinuz-<version> root=zfs:rpool/ROOT/debian ro single spectre_v2=on spec_store_bypass_disable=on tsx=off tsx_async_abort=full,nosmt mds=full,nosmt l1tf=full,force nosmt=force kvm.nx_huge_pages=force random.trust_cpu=off intel_iommu=on efi=disable_early_pci_dma slab_nomerge slub_debug=FZ init_on_alloc=1 init_on_free=1 mce=0 pti=on vsyscall=none page_alloc.shuffle=1 extra_latent_entropy.

For testing, I changed it to /vmlinuz-<version> ro single spectre_v2=on spec_store_bypass_disable=on tsx=off tsx_async_abort=full,nosmt mds=full,nosmt l1tf=full,force nosmt=force kvm.nx_huge_pages=force random.trust_cpu=off intel_iommu=on efi=disable_early_pci_dma slab_nomerge slub_debug=FZ init_on_alloc=1 init_on_free=1 mce=0 pti=on vsyscall=none page_alloc.shuffle=1 extra_latent_entropy with the stored command line mentioned above.

[stale]

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.

[johannbg]

bad bot

[johannbg]

Pretty sure this is a bug in the generator hence closing. File an bug report in upstream systemd if it get's nacked with not our problem re-open this request.

[arvidjaar]

systemd only uses
/usr/lib/kernel/cmdline /etc/kernel/cmdline /proc/cmdline

You mix different things. systemd is using /usr/lib/kernel/cmdline and /etc/kernel/cmdline only to generate loader entries. systemd is only using /proc/cmdline when it checks for kernel arguments.

this is a bug in the generator

No, it is not a bug, generators work as designed. It could be missing feature, then some cooperation between systemd and initramfs generators is still needed.