Comment 36 for bug 1937115

Hi folks,

we don't need reports of what works and what doesn't.

We already know that only live media are affected - installed systems usually don't boot via removable media path - but if they do, they go via fallback loader binary which works around the issue as it does not interpret its arguments.

We even have two approaches to work around the issue that are under discussion upstream.

Feedback we're looking for for fixing this better would be output of efibootmgr -v with a tarball of /sys/firmware/efi/efivars/Boot* files, on those systems where you can't boot live media. And which of those boot entries did not work.

What happens here is that the bootloader entries in UEFI contain arguments that get passed to shim. Shim tries to parse them, as it wants to treat the first argument as the bootloader to boot next - whcih is used for fwupd. Some firmware simply contains garbage in there, causing things to fail. We'd like to know what this garbage this such that we can safely ignore it and avoid even the workarounds.