Support IA32 UEFI
From https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_firmware_bitness:
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a EFI application corresponding to the UEFI firmware bitness/architecture.
The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 UEFI firmware. The only known devices that use IA32 (32-bit) UEFI are older (pre 2008) Apple Macs, Intel Atom System-on-Chip systems as on 2 November 2013 and some older Intel server boards that are known to operate on Intel EFI 1.10 firmware.
An x86_64 UEFI firmware does not include support for launching 32-bit EFI applications (unlike x86_64 Linux and Windows versions which include such support). Therefore the EFI application must be compiled for that specific firmware processor bitness/architecture.
Until Linux 5.7 the only way to boot a x86_64 kernel on IA32 UEFI was to use a boot loader that didn't rely on the kernel's EFI stub. Those would be GRUB and syslinux. As was discovered in FS#53182, syslinux does not work on real IA32 UEFI, so the only real option was GRUB.
Linux 5.7 EFI stub added support for booting a x86_64 kernel on IA32 UEFI. This new booting method needs to be supported by the boot loader/manager and the initrd must be specified in a UEFI variable, not using the initrd=
in kernel's command line.
This new method has been implemented in EDK2 OVMF (starting from version 202005 when built with LOAD_X64_ON_IA32_ENABLE
, commit & bug), so it can be tested using OVMF's builtin UEFI shell.
So the options for archiso are:
- Use GRUB.
- Ship a IA32 UEFI shell and let users specify the kernel cmdline manually, or provide a
startup.nsh
like 6caa5bcb did in the past😄 . - Waiting until systemd-boot implements support for mixed mode boot: https://github.com/systemd/systemd/issues/17056 .
1
is not an option since we all dislike GRUB. 2
is not optimal because UEFI shell's initrd
command support sspecifying only one file, but we have at least 3 (the main one and two microcode images). That only leaves us with 3
, so we'll just need to wait on systemd.
See https://bugs.archlinux.org/task/53182 for previous discussion.