x86_64_Notes_for_EFI_Systems

Notes for UEFI Systems

Forewords

Unified Extensible Firmware Interface, or UEFI, is the successor to the previous scheme, BIOS. Instead of start up codes in MBR header, UEFI uses EFI system partition and non-volatile memory (NVRAM) on motherboard to manage boot process. This article provides rationale and alternative solutions to Grub if you have special concerns.

TL; DR

Just use grub and DO NOT mount your EFI system partition at /boot. Mount it as /efi instead.

Topics/Partitioning

UEFI hardware requires a separate partition in vfat filesystem, where firmware searches for some EFI executables. This particular partition has a distinct type code: EFI System Partition aka. ESP.

Since this partition is used for startup, it is possible to use ESP as /boot partition. However, there are constraints. Read further.

Topics/dpkg

When dpkg install packages, it deploy symlinks to ensure an (nearly )transactional procedure. However vfat does not have full support for symlinks. So it would not make sense to mount your ESP at /boot and get a bunch of errors from dpkg.

Topics/Grub

Grub bootloader on EFI is basically an EFI binary that your UEFI can execute. Grub looks into wherever your kernel is located, then boots the kernel just like in the old days.

Topics/EFISTUB

All linux kernels in AOSC repositories are built with full UEFI support, where UEFI may treat kernel as an executable EFI binary (which starts the system). Such kernels are known as EFISTUBs.

There are a few interesting combinations of partitioning schemes and bootloaders. DO NOT mount your EFI system partition at /boot. Mount it as /efi instead.

Without any bootloaders

Since the UEFI can start EFISTUB kernel directly, why use bootloaders? Surprisingly it works quite nicely on well implemented hardwares.

In this case, kernel parameters such as root partition identifier (root=PARTUUID=BLAH) and initrd (initrd=/path/to/initrd.img) are passed to kernel as EFI binary parameters with an -u <params> in efibootmgr when creating an EFI boot entry to NVRAM. For example:

# efibootmgr -c -d /dev/sda -p 1 -L "AOSC OS" -l /vmlinuz-aosc-main-4.11.8 -u "root=PARTUUID=BLAH rw initrd=/initramfs-4.11.8-aosc-main.img"

See that /vmlinuz-aosc-main-4.11.8? Well, it specified an absolute path in the ESP, which means:

• - You have to copy kernel vmlinuz and initramfs from /boot to ESP manually every time there is a new kernel release,
• - and update your efi boot entry to the new kernel binary,
• - and there is no way to modify kernel parameters before starting kernel.
• - You also need a motherboard with A PERFECTLY STANDARD UEFI IMPLEMENTATION! (I'm serious)
• + But you may forget about bootloader waiting time and messing around with grub!

For second bullet there is a workaround by using consistent filenames for vmlinuz and initramfs (e.g. vmlinuz-aosc-main and initramfs-aosc-main) and write over when you copy newer kernels to ESP.

Systemd-boot aka. sell your underpants to systemd

You will still need an EFISTUB kernel, not a problem in AOSC OS though. Instead of messing around with NVRAM entries, systemd-boot (formerly known as gummiboot) uses human-friendly conf files for loading entries and gives a nice entry selector. Invoke bootctl to see how to use it.

systemd-boot only starts efi applications, i.e. only kernels with EFISTUB support may be launched with systemd-boot. Previously mentioned constraints also apply:

• - You have to copy kernel vmlinuz and initramfs from /boot to ESP manually every time there is a new kernel release.
• - You have to update configuration confs according to the new kernel binary.
• - You need a motherboard with a normal UEFI implementation (Or a non M$ hardcoded UEFI)
• + But you may forget about bootloader waiting time and messing around with grub!
• + Flexible configuration structure in case you want something else, like multi-boot or EFI shell
• + Allow pre-booting command line modification.