Release Engineering

This project is intented for all release related issues (isos, installer, etc), under the umbrella of the ArchLinux Release Engineers

FS#20419 - (U)EFI Boot support for Installer CD/USB

Attached to Project: Release Engineering
Opened by Anonymous Submitter - Monday, 09 August 2010, 13:53 GMT
Last edited by Eric Belanger (Snowman) - Saturday, 25 August 2012, 13:16 GMT
Task Type Support Request
Category ArchISO
Status Closed
Assigned To Dieter Plaetinck (Dieter_be)
Architecture All
Severity Low
Priority Normal
Reported Version 2010.05
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 9
Private No


Description :

Currently Archlinux Official Installer and Archboot do not include support for booting in pure (U)EFI systems (without a BIOS compatibility option). This support is important as more and more motherboards are shipping with UEFI 2.x firmware (Phoenix 1-second boot firmware) like Intel Server motherboards, MSI Boards and of course Apple-Intel Macs.

EFI Boot support does not involve any boot-sectors and stuff like that. Only some extra files (efi apps and their configs) will be required. EFI support is not same as GPT support.

Supported boot-loaders :-

Fedora's grub-legacy fork - - grub-efi-fedora
GRUB2 EFI - - grub2-efi-bzr
SYSLINUX does not support EFI.

Of these 2, grub2 is recommended. Although it is not KISS, it is more actively developed and its modular structure is great.

Important Info :-

UEFI Firmware can be either 32-bit (i386) or 64-bit (x86_64).

In the ISO, the following files should be present -

(iso-root)/efi/boot/bootx86.efi (grub2 binary for 32-bit EFI)
(iso-root)/efi/boot/bootx64.efi (grub2 binary for 64-bit EFI)
(iso-root)/efi/boot/grub.cfg (grub2 configuration file)

Both the grub2 binaries need to be present as the UEFI firmware arch need not be same as the linux kernel arch. It is also not possible to change the UEFI arch by simply flashing the firmware.

The UEFI firmware will automatically launch the appropriate binary depending on its arch. Therefore the filenames should not be changed. The kernel config already has efi enabled so no change is needed at kernel level.

Additional requirements :-

Although GPT support is not needed for UEFI boot, most of the systems using UEFI are GPT partitioned.
Archboot includes GPT support in its installer and also includes "extra/gdisk" in the iso for GPT partitioning. Archiso does not include any such support. All >2TiB 512-byte sector drives have to use GPT. Please add GPT support to Archiso and move gdisk to core. None of the util-linux-ng tools support GPT.

Testing :-

Testing can be done using any UEFI motherboards, Intel's Tianocore EDK2 DuetPkg (, in QEMU using Tianocore's OVMF ( or using EFI emulation in VirtualBox (based on OVMF but OVMF downloaded binaries cannot be used).
This task depends upon

Closed by  Eric Belanger (Snowman)
Saturday, 25 August 2012, 13:16 GMT
Reason for closing:  Implemented
Additional comments about closing:  Implemented. Using new EFI_STUB feature of Linux-3.3. it/commit/?id=6caa5bcb69037442fac2b30ac5 b20e4350a11056
Comment by Anonymous Submitter - Monday, 09 August 2010, 13:56 GMT
Related info from Fedora's wiki (they managed to implement efi support in Anaconda):-
Comment by Tobias Powalowski (tpowa) - Monday, 09 August 2010, 14:36 GMT
Thanks, i'll start immediately with hacking the support for archboot. The loaders also need to install in the EFI partition if i'm not wrong?
Comment by Anonymous Submitter - Monday, 09 August 2010, 15:49 GMT
I guess you are talking about EFI SYSTEM PARTITION. Although EFI SYSTEM PARTITION (which should be FAT32 - no other FS) is the officially supported way for EFI applications (not just bootloaders), I have seen firmwares which support any partition with the supported filesystem (in this case FAT{12/16/32} and ISO9660, but not UDF). My /boot is FAT32 and I am able to access it in my EFI firmwares (Tianocore EDK DUET UEFI64 x64 UEFI 2.1 and EDK2 DuetPkg X64 UEFI 2.3).

In case of Linux, I think only Fedora (and Redhat) officially support UEFI currently. They expect EFI SYSTEM PARTITION to be mounted on /boot/efi/ . In my system I mount my EFISYS at /efi so that /boot is not disturbed. I manually edited my /etc/fstab. I do not know how to detect which partition is EFISYS in a particular drive. Each physical drive may contain its own EFISYS partition.

In MBR, its type code is 0xEF. In GPT its GPT Partition Type GUID is C12A7328-F81F-11D2-BA4B-00A0C93EC93B . In GNU Parted "boot" flag in GPT disks marks a part as EFISYS. No such option exists in parted for MBR disks though. In GPT fdisk, EF00 type sets a part as EFISYS.

I had to install Archlinux only through BIOS (using Archboot for GPT and gdisk). I setup my efi bootloaders after installation manually.

The AUR grub2-efi-bzr PKGBUILD will help in understanding how to compile grub2 for efi. As you already know, cross compiling for different EFI arch requires gcc-multilib.
Comment by Anonymous Submitter - Monday, 09 August 2010, 15:57 GMT
If you have a Windows system and a spare 1 or 2 GB USB pendrive, you can download compiled Tianocore firmwares from (EFI_DUET.exe 7-zip LZMA2 self-extracting) and and setup duet in your pendrive (instructions in Usage_Windows.txt file). There is currently no way to setup duet under linux. These firmwares will provide access to real hardware, not as in case of OVMF.
Comment by Anonymous Submitter - Tuesday, 10 August 2010, 08:30 GMT
I have attached a text file with some info copied from UEFI 2.3 Spec in which the exact way UEFI boot works is described. The simple (iso-root)/efi/boot/ will work for newer UEFI firmwares (those that contain ISO9660 FS driver. The older firmwares need a FAT12 floppy image within the iso with a el-torito boot entry of Platform id 0xEF apart from the BIOS boot entry (Platform ID 0x00).

I think GNU xorriso is able to create compliant BIOS+UEFI+isohybrid ISOs

Comment by Anonymous Submitter - Thursday, 12 August 2010, 13:29 GMT

GNU Xorriso Latest development version includes support for creating UEFI boot images.
Comment by Tobias Powalowski (tpowa) - Thursday, 12 August 2010, 18:05 GMT
Great for collecting everything, my archboot implementation will start with next release cycle.
The R6 isos will not contain any uefi booting.
After this release i have some weeks time to develop the uefi stuff.
Comment by Anonymous Submitter - Saturday, 14 August 2010, 09:29 GMT
I have created a shell script that creates a BIOS+UEFI+isohybrid iso from an existing archboot iso. Copy and extract grub2_efi_stuff.tar.xz into the folder where the archboot iso exists. You will need package to be installed. This script uses xorriso (in mkisofs emulation), not cdrkit. Also edit the "export archboot_util_bin=" line to point to script. Comments are welcome.
Comment by Tobias Powalowski (tpowa) - Saturday, 14 August 2010, 11:53 GMT
hey thanks, looks great.
Comment by Anonymous Submitter - Saturday, 14 August 2010, 13:49 GMT
I modified the script slightly for the USB image. I copied over commands from you usb-helper script and modified few option to make syslinux work.
I tested the images using Virtualbox PUEL 3.2.8 and EDK1 UEFI64 DUET. There was a kernel panic while using grub2-efi-bzr but that was solved by using grub2-efi-bzr-exp package as the initrd was not loaded properly. Also grub2 efi takes a long time to setup the initramfs in the memory due to its size. There is also some problem with available video modes due to which the boot messages are not shown in EDK1 DUET (no problem with Virtualbox). Otherwise the efi firmwares detect and launch grub2 correctly which is enough for the cd. All other problems are either due to the firmware. grub2 or the kernel itself.

One problem that may arise with older BIOS firmwares is that they do not know how to read multiple el-torito boot entries.
Comment by Tobias Powalowski (tpowa) - Saturday, 14 August 2010, 18:14 GMT
The usb image is some kind of relict, it was from the times hybrid, were i didn't know of hybrid isos.
Comment by Anonymous Submitter - Tuesday, 17 August 2010, 09:50 GMT
I think this change will be needed in archboot also, for a proper FAT32 USB image .

Edit: The AUR grub2-efi package link is .
Comment by Anonymous Submitter - Saturday, 21 August 2010, 20:02 GMT
For 32-bit x86 EFI the filename is bootia32.efi, not bootx86.efi

(iso-root)/efi/boot/bootia32.efi (grub2 binary for 32-bit EFI) - correct

Try Colin Watson's test iso (also ). That seems to be a better solution than my shell script. But I think grub2 bzr experimental branch must be used to solve initramfs problems that occur with main trunk.
Comment by Anonymous Submitter - Sunday, 22 August 2010, 16:02 GMT
Modified script - creates efi boot images similar to Colin Watson's Ubuntu ISO which I found to be better, and proper grub.cfg grub2 config

Edit: New script at - includes grub.cfg as "cat >" output and uses splash png file syslinux/splash.png . No need for grub2_efi_stuff dir now or a separate grub.cfg outside of the script.
Comment by Anonymous Submitter - Wednesday, 25 August 2010, 16:16 GMT
One thing you might find strange in the script (do not use the attachments in this bugreport - use the link provided) is the use of

set _EFI_ARCH="x86_64" for 64-bit EFI and
set _EFI_ARCH="i386" for 32-bit EFI

This variable is added to the kernel boot parameter as "none=EFI_ARCH_${_EFI_ARCH}" in the final grub2 config for the kernel. This is my workaround for detecting which efi arch is used for booting. It is possible to know the firmware version of the EFI used for booting using "dmesg" but no easy way to find out which processor arch of EFI is booted, not even with efibootmgr or uefivars (both utils use efivars kernel module).

If the kernel arch and EFI arch do not match, then "dmesg | grep EFI" shows no proper output (not even the firmware version). If tha archs match then "dmesg | grep EFI" shows the firmware (but may not show always - noefi kernel boot parameter).

With this grub2 config the "BOOT_IMAGE=" line in dmesg output includes none=EFI_ARCH_x86_64 (for 64-bit EFI) or none=EFI_ARCH_i386 (for 32-bit EFI). This detection will help in deciding which grub2 package will have to be installed during bootloader install section in archboot, whether grub2-efi-x64 or grub2-efi-x86 . I do not know how to implement install support for grub2-efi. That part is left to Tobias.

This script only enables iso or usb booting in efi. Isohybrid iso's dd copy to a USB pendrive will not work in efi. The USB has to be FAT16/32 formatted for EFI-USB booting to work.

The grub2-efi-* packages in AUR currently do not use 1.98 tar.gz but my own tar.xz of bzr rev 2627, as release 1.98 is too old for efi, as confirmed by grub2 devs . Also script needs memdisk support in grub2 which is present only in bzr development version. 1.99 is likely to be released in september .

And a minor issue - EFI boot in VirtualBox or QEMU (OVMF based) or any Tianocore based firmware is not supporting AHCI SATA mode in BIOS. All these firmwares support only Legacy IDE mode. This may be the case even with actual UEFI firmwares in the motherboard. There should be some way to check this while booting.
Comment by Anonymous Submitter - Wednesday, 22 September 2010, 19:12 GMT
EFI boot can be detected by checking for /sys/firmware/efi dir. If it exists then install grub2-efi-<kernel arch> package otherwise install grub2-bios package.

if [ -d /sys/firmware/efi/ ] || [ -d /proc/efi/ ]
if [ "$(uname -m)" == "x86_64" ]
pacman -S grub2-efi-x64
elif [ "$(uname -m)" == "i686" ]
pacman -S grub2-efi-x86
pacman -S grub2-bios

The dir /sys/firmware/efi/ is created only if the kernel arch and efi arch match. If kernel & efi arch do not match, or if "noefi" kernel parameter is used while booting, then there is no reliable way of detecting whether it is a bios boot or efi boot. In that case assume bios boot or query the user for correct firmware info.
Comment by Anonymous Submitter - Saturday, 25 September 2010, 06:23 GMT Comment by Anonymous Submitter - Thursday, 23 December 2010, 13:55 GMT
For Archboot installer script efi support go to .
Comment by Tobias Powalowski (tpowa) - Saturday, 19 February 2011, 08:13 GMT
Archboot implemented uefi completely.