Switch to UEFI booting also in standard images

[jan-kiszka]

This would allow to unify the boot, make sure that non-volatile efivars and dmi information will eventually be available and will hopefully simplify things.

One blocker: We either need to add multi device-tree support to systemd-boot's UKI (Unified Kernel Image) stub, analogously to EFI Boot Guard (siemens/efibootguard@d0c7afd). Or we need to enhance isar recipes to generate a UKI from EFI Boot Guard while using a different boot loader (systemd) or booting directly a UKI. The first option appears nicer but requires upstream work.
@stormc

[stormc]

I think we should strive to eventually settle on one EFI Stub, wherever that is hosted. So, given systemd's ubiquity, it would make sense to approach "upstream", also lowering maintenance efforts in the EFI Boot Guard project. In addition, it should/would be in systemd's interest to support a broader range of use cases like this.

That said, there's the question of release / development speed to be discussed: For new / board-enabling scenarios -- assuming systemd would be the upstream of the EFI Stub -- and given that Distributions do not always ship the latest greatest version, a backport of systemd may have to be used to benefit from the latest enabling features. While intermittent, this may not be acceptable as getting other features / bugs as by-catch. Accounting for this, it would probably make sense to create a new upstream for the EFI Stub used by different projects or a stand-alone packaging of systemd's EFI Stub having decoupled release cycles...

Short-term and technically speaking, I guess it's faster to use EFI Boot Guard's EFI Stub while settling the topic with the systemd project for a long-term nicer solution.

[jan-kiszka]

The implementation of a stub extension in systemd-boot is only one aspect. First, we will have to get the new UKI spec extended: https://uapi-group.org/specifications/specs/unified_kernel_image. We will look into that soon.