UEFI
Unified Extensible Firmware Interface(UEFI) is a specification for the firmware architecture of a computing platform. This page documents how Alpine Linux works with devices using UEFI firmware.
EFI system partition
UEFI requires a partition called "EFI System Partition" (ESP) - a FAT32 partition where the OS bootloader apps get installed to.
The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is \efi\boot\bootx64.efi and \efi\boot\bootaa64.efi on ARM64 architecture.
Most of the programs that are expected to run in the UEFI environment are bootloaders, but other utilities might exist too. There are also programs to deal with firmware updates from motherboard manufacturers which can run before operating system startup like fwupdate/fwupd.
UEFI boot process
UEFI has list of possible boot entries, stored in UEFI config variables (normally in NVRAM), and boot order config variables stored alongside them. UEFI firmware can read ESP partition, a UDF or FAT32-formatted USB drive or DVD, and look for OS boot loaders and runs it.
These boot entries in NVRAM can be viewed and edited with efibootmgr utility.
Disk layout for UEFI
UEFI-GPT layout is the recommended layout for UEFI.
The UEFI booting relies on the boot entries in NVRAM and looks for OS boot loaders and runs it. Parted and its front-ends use a "boot" flag on GPT to indicate that a partition is an EFI system partition(ESP), but the "boot" flag is not used by UEFI boot process.
UEFI-GPT layout
Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting. On UEFI systems, Alpine Linux requires an EFI System Partition(ESP) in addition to the (/) root partition. A minimal UEFI-GPT layout is given below:
| Mount point | Partition | Partition type Purpose | Recommended minimum size |
|---|---|---|---|
| /boot or /efi or /boot/efi | /dev/sda1 | EFI system partition | 260 MiB |
| / | /dev/sda2 | Alpine Linux root system OS | 1–32 GiB |
BIOS-MBR layout
BIOS-style booting from MBR-partitioned disks is called BIOS-MBR, regardless of it being performed on UEFI or legacy BIOS-based systems. Such a boot scheme is commonly called UEFI-MBR.
Despite the fact that the UEFI specification requires MBR partition tables to be fully supported, some UEFI firmware implementations may immediately switch to BIOS-based Compatibility Support Module (CSM) booting depending on the type of boot disk's partition table, effectively preventing UEFI booting to be performed from EFI System Partition on MBR-partitioned disks. CSM is a deprecated feature as of late 2020's.
Use this only on BIOS only motherboards. A BIOS boot partition with "boot" flag may be required when using this layout, depending on the firmware implementation.
| Mount point | Partition | Partition type Purpose | Recommended minimum size |
|---|---|---|---|
| /boot | /dev/sda1 | Boot grub partition (optional) | 100 MiB |
| / | /dev/sda2 | Alpine Linux root system OS | 1–32 GiB |
BIOS boot process
BIOS mainly supports two methods of booting - loading approximately 448 bytes of 8088 machine code from the start of a floppy disk, or the same from the start of a fixed disk. BIOS can only assume one boot loader occupying the start of hard drive. So each OS overwrites it with its own boot loader.
MBR cannot handle disks larger than 2 TiB (232 × 512 bytes). Therefore, it is impossible to use any drive space beyond 2 TiB using MBR layout.
BIOS is deprecated since approximately 2011 onwards and modern motherboards are using UEFI.
BIOS-GPT layout
Booting legacy BIOS-based systems from GPT disks is also possible, and such a boot scheme is commonly called BIOS-GPT. A BIOS boot partition with "boot" flag is required when using this layout. This partition must not be formatted with a file system or mounted.
| Mount point | Partition | Partition type Purpose | Recommended minimum size |
|---|---|---|---|
| None | /dev/sda1 | BIOS boot partition | 8 MiB |
| / | /dev/sda2 | Alpine Linux root system OS | 1–32 GiB |
Secure boot process
When the device is powered ON, secure boot checks the digital signatures of the bootloader and operating system. If the signatures are valid and match the trusted keys stored in the system, the boot process continues. If not, secure boot halts the process to protect against tampering.
Almost all X86 based motherboard has a small list of pre-trusted certificates which includes Microsoft's certificates, which they currently let anyone use for a small fee as a Certification Authority (CA).
Alpine Linux does not have a certificate which some other Linux distributions (mostly enterprise-related) have. This means, users have to first disable Secure Boot to be able to install Alpine Linux.
UEFI Secure Boot page explains how to generate your own UEFI keys and enrolling those UEFI keys to be used with a Unified Kernel Image.