The EFI architecture places it between the OS and the lowest levels of firmware, with the hardware beneath it all. (Source: Wikipedia)
Originally written: 9/23/2011; last update: 7/6/2018
This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
| Donate $1.00 | Donate $2.50 | Donate $5.00 | Donate $10.00 | Donate another value |
This page is part of my Managing EFI Boot Loaders for Linux document. If a Web search has brought you to this page, you may want to start at the beginning.
At the dawn of the PC era in 1981, IBM shipped its Personal Computer 5150 with firmware known as the Basic Input/Output System (BIOS). The BIOS was intended to be an interface between many hardware devices and the Disk Operating System (DOS). As the years progressed, though, the BIOS became less important because it was written using 16-bit code, and operating systems progressed to 32-bit and, now, 64-bit code. Such advanced OSes can't use the BIOS's features without a performance penalty, so modern OSes instead rely on drivers to talk to hardware. Today, therefore, the main role of the BIOS is to begin the boot process. Once the system is booted, the BIOS is essentially irrelevant.
Still, booting the computer is an important task, and the BIOS's ancient design creates limitations. For instance, the BIOS begins the boot process by loading just 512 bytes of data—the contents of the first sector of the boot disk—and executing it. Therefore, whatever program resides in that tiny location (the Master Boot Record, or MBR) controls how the computer boots. Often, the MBR code loads additional code from elsewhere in order to present a menu of options. There is no universal standard for how this is done, though, and it's common for OSes to wipe out existing MBR code, and therefore working boot loader configurations, upon installation.
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. This fact enables multiple boot loaders to coexist on the hard disk, and to be accessed entirely using normal file access mechanisms. These facts make EFI boot loader maintenance eaiser and more flexible than equivalent operations for BIOS boot loaders—at least, in theory. In practice, bugs and quirks in some EFI implementations, and in some OSes, can make it harder to manage EFI boot loaders, particularly if you're unfamiliar with their principles. EFI also has its design limitations, as described on this page.
Although EFI is intended to replace BIOS, some of the earliest EFI implementations on the x86-64 platform have been supplements to the BIOS—an EFI module is added to a traditional BIOS, leaving the BIOS in control of basic hardware initialization and booting the computer if a BIOS boot loader is detected. The vast majority of EFIs on computers sold since 2012 or 2013 completely replace the legacy BIOS code, though. Such implementations can typically boot more quickly than can a BIOS, and they often (but not always) include "eye candy" such as flashy mouse-enabled GUIs. From a software perspective, though, both types are equivalent—they use the same boot loaders, disk structures, and so on.
The EFI architecture places it between the OS and the lowest levels of firmware, with the hardware beneath it all. (Source: Wikipedia)
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. This wouldn't be so bad except that no other entity has the clout to ensure that its keys are included in such a wide range of hardware. Fortunately, Microsoft offers a signing service, and several Linux distributions take advantage of it; but many in the open source community object to being dependent upon Microsoft, particularly for something as basic as launching a boot loader. I describe the technical details of how to cope with Secure Boot in my Dealing with Secure Boot page. If you want to use Secure Boot but be completely free of Microsoft's keys, see my Controlling Secure Boot page.
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. Windows also enforces the EFI/GPT association, at least for its boot disk—if Windows boots on an EFI-based computer, the boot disk must be GPT, and if it boots on a BIOS-based computer, the boot disk must use the older MBR style. (There are hackish ways around these ties; for instance, see this article for information on booting Windows from a GPT disk in BIOS mode.) Therefore, when setting up a computer to boot in EFI mode, it's generally best to create it as a GPT disk. In Linux, there are three main ways to create a GPT disk:
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. (This choice can cause problems for Windows 7, which will accept only a FAT32 ESP. At least one EFI implementation, Gigabyte's Hybrid EFI, also seems to be allergic to FAT16 ESPs.) 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. On the other hand, this may cause the Windows installer to fail should you need to install this OS.
The ESP holds EFI drivers, EFI applications, EFI scripts, and EFI boot loaders, among other things. This range of EFI data illustrates the fact that EFI is quite complex; it's similar in many ways to DOS in power. This set of Web pages is devoted principally to EFI boot loaders (and boot managers), of course.
Each EFI boot loader is stored in its own subdirectory of the EFI directory on the ESP. These subdirectories are typically named after the OS that created them. For instance, Ubuntu places its EFI boot loader files in EFI/ubuntu, and Red Hat places its EFI boot files in EFI/redhat. (Fedora also used the EFI/redhat directory name through Fedora 17, but it's switched to EFI/fedora with version 18.) Once Linux is installed, the ESP is typically mounted at /boot/efi, so these directories would be /boot/efi/EFI/ubuntu and /boot/efi/EFI/redhat, respectively, on a working Linux installation. A proposal at freedesktop.org would encourage mounting the ESP at /boot rather than at /boot/efi. This proposal has yet to be adopted by any major distribution, although Arch Linux users are fond of mounting the ESP at /boot.
These EFI boot loader directories hold an EFI boot loader file, whose name ends in .efi, as well as configuration files, support files, and perhaps even Linux kernels and initial RAM disk files. The details vary from one boot loader to another.
If you need to install a boot loader independently of the one your OS installed, you may want to create your own directory for it. I typically name mine after the boot loader itself, such as EFI/refind for rEFInd. One other boot loader directory requires mention: EFI/BOOT. This directory holds a boot loader file, bootx64.efi, which serves as the fallback boot loader if none is specified in the firmware's flash storage. The filename varies depending on the architecture—the filename is bootia32.efi on IA-32 (x86) computers and bootaa64.efi on ARM64 computers. The vast majority of EFI-based x86-64 computers use 64-bit EFIs and therefore use a bootx64.efi default boot loader file. A handful of early Macs and some Atom-based tablets have 64-bit CPUs but 32-bit EFIs; and some early Intel-based Macs used 32-bit CPUs and EFIs, so their default boot loaders are called bootia32.efi. Some EFIs try to run EFI/Microsoft/BOOT/bootmgfw.efi as a sort of secondary fallback boot loader. This is the name of Windows' EFI boot loader, so presumably checking this name helps in case the computer's NVRAM is erased.
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 boot loader launched by the firmware can load an OS directly (as the Windows EFI boot loader does) or it can present a menu or prompt with additional options (as most Linux EFI boot loaders do). During OS installation, the OS's boot loader is written to disk and its boot loader should be added to the built-in boot manager's list of options—normally as the first entry.
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. (If not for that fixed filename, a factory-fresh computer wouldn't be able to boot anything!) This filename was quickly adopted as a fallback filename for hard disk installations, as well. This way, if a duplicate of the normal boot loader is installed to the fallback filename, the computer will remain bootable if the NVRAM-based boot manager list is damaged. In practice, some EFIs have badly broken boot managers that tend to forget or ignore their boot loaders. These computers boot reliably only from the fallback boot loader. In many cases, the fallback boot loader is handled through a regular boot entry that refers to the bootx64.efi file or to the disk; however, details vary greatly from one computer to another.
Note also that non-disk boot devices can have EFI boot manager entries. This is common with network devices to boot over the network. Entries for such devices are normally created by the firmware when you activate a network-boot option; but they can be manipulated (their order changed) by the same tools you use to manipulate other entries, as described on the next page. Some EFIs provide entries to launch an EFI shell, the EFI setup utility, or other tools.
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.
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. Note that using the CSM creates a potential for significant complications, so I advise against using it if possible. See my CSM: The Good, the Bad, and the Ugly page for more on this subject.
Although managing boot loaders by juggling files in the ESP is arguably far superior to managing boot loaders by overwriting code in the MBR or other locations on the disk, EFI boot loader management has an Achilles' heel: 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. To make matters worse, some computers "forget" their NVRAM settings without provocation, necessitating installing the boot loader as EFI/BOOT/bootx64.efi. This isn't so bad in and of itself, but if an OS or boot loader installer sets up the boot loader in the way it officially should, it won't work and the user must intervene manually. One workaround to such problems is to install a copy of rEFInd to a USB flash drive or CD-R. When you boot it, rEFInd scans for your regular boot loaders and should enable you to launch them. Another workaround is to use the fbx64.efi fallback boot loader.
Two similar terms are often used interchangeably, but in fact they refer to different things:
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. In practice, you may end up using a boot manager to launch one or more different boot loaders. Boot loaders are often (but not always) OS-specific, so a boot manager might launch one boot loader for one OS and another boot loader for a second OS. A combination tool like GRUB is likely to use its own boot loader features to launch a Linux kernel, and its boot manager features to launch a boot loader for another OS, such as Windows or macOS.
Although this series of Web pages includes boot loaders in its title, I also cover boot managers. Part of the reason for this is that the EFI stub loader tends to blur the distinction. As described on its page, this program turns a Linux kernel into its own boot loader. This means that a boot manager can launch a Linux kernel, much as a boot loader could.
From an EFI perspective, both boot loaders and boot managers are simply EFI programs. Other EFI programs exist, such as EFI shells, tools to manage Secure Boot features, programs to update a computer's firmware, and even a Python interpreter. Boot managers can launch such tools and present them in their menus along with boot loaders. This series of Web pages touches on such programs from time to time but does not go into them in any depth.
Go on to "EFI Boot Loader Installation"
Return to "Managing EFI Boot Loaders for Linux" main page
copyright © 2011–2018 by Roderick W. Smith
If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main Web page.