What's EFI?

The Extensible Firmware Interface (EFI) and its newer variant, the Unified EFI (UEFI), are firmware designs that are intended to replace the BIOS. EFI supports many advanced features, but the most important for purposes of this Web page is the fact that EFI boots in a very different way from BIOS. EFI implementations are more sophisticated than BIOS implementations, so an EFI can read partition tables and filesystems, which a typical BIOS can't do.

EFI Disk Structures

The EFI specification includes a description of a new partition table type, the GUID Partition Table (GPT). Although some EFI-based computers can boot from MBR disks, some balk at this practice, so most EFI computers use GPT disks.

Creating a GPT Disk

• Use a libparted-based tool, such as parted or GParted, to create your partitions, and explicitly tell that tool to use GPT. In parted, you can do this by typing mklabel gpt. In GParted, you select Device -> Create Partition Table, expand the Advanced item, select gpt as the partition table type, and click Apply to create a new partition table. Either method erases your existing partitions.
• Use GPT fdisk (gdisk, cgdisk, or sgdisk) to create your partitions. These tools can convert an existing MBR disk to GPT format, or they can partition a blank disk.
• Use a recent version of fdisk or one of its related tools, cfdisk or sfdisk. The version in util-linux 2.27 does the job, but the version in util-linux 2.20 does not. I'm not sure exactly when the change took place. Typing g at the fdisk main menu creates a new GPT; but this act will wipe out existing partitions.

EFI System Partition (ESP)

Whether the boot disk uses GPT or MBR, EFI relies on a special partition, known as the EFI System Partition (ESP), to hold EFI-specific data. The ESP should officially use a FAT32 filesystem, although some (especially older) Linux distributions place a FAT16 filesystem on this partition.

• On an MBR disk, the ESP has a type code of 0xEF. On a GPT disk, the ESP has a GUID value of C12A7328-F81F-11D2-BA4B-00A0C93EC93B, but most partitioning tools hide GUID values because they're awkward for humans to use. In GPT fdisk, ESPs are displayed as having a type code of EF00, and most libparted-based tools use a "boot flag" (and a redundant "esp flag") to identify the ESP. Note that in libparted tools, a GPT partition's "boot flag" is entirely different from a "boot flag" on an MBR disk. You should not set the "boot flag" on any OS partition under GPT, just on the ESP.
• Although the EFI specification is mute on the subject of the ESP's size, most OSes make it fairly small—Macs ship with 200MiB ESPs, and the Windows 7 installer creates one of just 100MiB. (That value has been raised to a bit over 200MiB on newer versions of Windows.) Some users, however, have found that some EFIs have bugs that cause problems with FAT32 ESPs that are under 512MiB (537MB) in size. One very common problem is files that can't be read by the EFI. The Linux mkdosfs command defaults to using FAT16 for partitions of up to 520MiB (546MB). Therefore, adding a margin of safety to protect against MiB/MB confusion and rounding errors, I recommend creating an ESP that's at least 550MiB in size. If you must use a smaller ESP and if you encounter mysterious problems, try converting it to FAT16; most ESPs will work fine with this, and it may eliminate your problems.

The EFI Boot Process

The EFI boot process doesn't refer to code in the MBR, and it normally doesn't use code in the boot sector of a partition, either. Instead, the EFI loads the boot loader specified by the EFI's built-in boot manager. This boot manager maintains a list of boot options in NVRAM, along with an order in which to try them. If you boot without overriding the boot order, the computer will try each item in the specified order until one doesn't return. If an entry returns (because it points to a non-existent file, the program exits, etc.), the next item in the list is tried.

The Fallback Boot Loader

The fallback boot loader mentioned earlier (EFI/BOOT/bootx64.efi, or variants of that, depending on the architecture) is something of a special case. This filename was originally intended for use only on removable media, so that they could be booted to install an OS.

Boot Menu

In principle, EFIs can provide menus to enable users to select which of the available boot loaders to use at boot time. In practice, though, these boot menus are often awkward to use. Frequently, you must press a special key at some point during the boot process to access the boot manager menu; if you fail to do this, the default OS will load. Some implementations don't provide such a boot manager menu at all. Consult your computer's or motherboard's documentation to learn how to access the boot menu.

Compatibility Support Module (CSM)

Most, but not all, modern EFI-based computers include a BIOS compatibility mode that enables them to boot using BIOS boot loaders. This feature is known as the Compatibility Support Module (CSM). Typically, you can activate or deactivate CSM support by using options on a Boot menu in your firmware setup utility, so look for such options if you want to switch your computer's boot mode.

Managing Boot Loaders with NVRAM

Because the firmware tries to load a boot loader whose location is stored in NVRAM, the system becomes vulnerable to failure if either the hard disk is swapped out or the NVRAM is erased. Users report being unable to boot if they update their firmware, and moving a disk from one computer to another requires adjusting the NVRAM boot settings. Furthermore, some EFI implementations "helpfully" remove NVRAM settings for boot loaders they can't detect, which can require re-creating the NVRAM settings if you temporarily remove a hard disk and then re-install it.

Boot Loaders vs. Boot Managers

Two similar terms are often used interchangeably, but in fact they refer to different things:

• Boot managers present a menu of boot options, or provide some other way to control the boot process. The user can then select an option, and the boot manager passes control to the selected tool.
• Boot loaders handle the task of loading an OS kernel into memory, often along with support files such as a Linux initial RAM disk (initrd) file, and starting the kernel running.

Some programs, including the popular GRUB (both GRUB Legacy and GRUB 2), function as both boot managers and boot loaders, which may be why the terms are often used interchangeably. In the EFI world, though, some programs (such as ELILO, SYSLINUX, and the EFI stub loader) can load only Linux kernels and so are boot loaders alone; and others (such as rEFIt, rEFInd, and gummiboot/systemd-boot) are strictly boot managers. In fact, the EFI specification calls for EFIs to provide their own boot managers—but these are often very minimal or awkward to use.

Dealing with Secure Boot

One further feature of EFI deserves mention here: Secure Boot. This feature is intended to improve security by ensuring that only boot loaders signed with a cryptographic key can run. If you or an entity that you trust controls the key, it's unlikely that malware authors will be able to sign their code, which can theoretically block one avenue of malware attack.

The problem with Secure Boot is that Microsoft requires its use on desktop and laptop computers that ship with Windows 8 and later. As a practical matter, this means that Microsoft's keys are included in the vast majority of new computers.

Workarounds for Secure Boot

• Microsoft offers a signing service, and several Linux distributions take advantage of it.
• Many in the open source community object to being dependent upon Microsoft, particularly for something as basic as launching a boot loader.

Conclusion

This article provided a comprehensive overview of managing EFI boot loaders with a focus on GPT for Linux systems. Understanding the concepts of EFI, GPT, ESP, Secure Boot, and the interplay between boot loaders and boot managers is crucial for configuring and maintaining modern computer systems.