Bug 932842 – sys-kernel/installkernel[efistub]: uefi-mkconfig and kernel-bootcfg stablereq

• Status: CONFIRMED
• Product: Gentoo Linux

[Description tomas charvat 2024-05-27 11:12:42 UTC]

Works fine, solve sort issues of v1.3 with efistub

Reproducible: Always

[Comment 1 Andrew Nowa Ammerlaan 2024-05-29 16:11:35 UTC]

If this is stabilized, it should be stabilized together with app-emulation/virt-firmware.

However, whether or not EFI stub booting works, heavily depends on the UEFI implementation. If you happen to have a rather bad one, then you're going to have a painful time debugging why it doesn't work.

Because of this I consider EFI stub booting an advanced case, and I therefore think this should remain in testing (potentially forever).

[Comment 2 tomas charvat 2024-06-10 15:33:02 UTC]

@Andrew 

uefi-stub is working fine here, we have encounter non-standard situation only on A2SDi-2C-HLN4F boards (Atom), that can be easily overcome (reported to Supermicro).
Rest of the servers (x86) are working just fine, no issues so far. Servers are 3-5 years old.

sys-boot/uefi-mkconfig < 1.5 is the only drawback that we have with uefi-stub for now.

Even working with efi-shell to recover from efi menu related issues is far more convenient that recover from screwed grub.

In fact setup uefi-stub for 1st time was far more simpler that Grub for me. I do not consider it more advanced/dangerous that setting up Grub.

We have it on production for ... half year or so. Dozen of kernel updates, not a single surprise, except that sort issue of sys-boot/uefi-mkconfig.

[Comment 3 Andrew Nowa Ammerlaan 2024-06-10 17:25:09 UTC]

It's great that it works for you, and I would expect it to work if one buys new quality (server) hardware. However, I know of several blocking issues in various UEFI implementations:
- The firmware does not support boot entries at all (and always boots Windows or BOOT/BOOTX64.EFI) (effects most (all?) Dynabook laptops)
- The firmware does not support modifying the boot order and/or boot entries from the OS (effects MSI Z370 series and probably older)
- The firmware does not allow modifying the boot order and/or boot entries from an OS that is not signed with a certificate accepted in the secureboot DB (efi stub can be made to work, but it's a pain, sys-boot/shim does not resolve the issue)
- The firmware does not properly pass on the cmdline in the boot entry to the kernel (effects various Dell machines, though I believe this one can be resolved via firmware update)

I agree that efistub booting is a lot simpler then GRUB in the modern world of UEFI and UKIs. However, it would be just as simple with systemd-boot or refind and you would not encounter any of the above issues (for this reason I would argue that we should no longer consider GRUB the default bootloader for UEFI systems, but that is a different discussion).

I would also like to add that no other distro offers efistub booting as a "stable" option (AFAIK). Fedora is experimenting with it, but marks this explicitly as testing (this is where virt-firmware originates). And I know you can achieve this with relative ease in Arch, but they don't version their kernel so no adjustments to the UEFI configuration are necessary on kernel updates which effectively mitigates most of the problems I mentioned above. I'm very happy that we can offer this as an option in Gentoo, but I would not consider this a stable feature.

So to summarize, I do not consider efistub booting as advanced/unstable/dangerous because uefi-mkconfig/virt-firmware is not working properly, on the contrary both are rather simple and effective tools that I know work well. The blocking issue is the wild variety of UEFI implementations, some of which are severely bugged and will not be fixed by the manufacturer. And the total lack of overarching body to enforce that manufacturers actually follow the UEFI specifications.

I'll re-assign this to dist-kernel, since this is mostly about (helpers for) installkernel, and would love to hear opinions from the rest of the team. But unless the rest of the team disagrees with me then this is unfortunately still a no from my side.