Originally written: 9/23/2011; last update: 4/27/2013
I'm a technical writer and consultant specializing in Linux technologies. 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 larger 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, the newness of EFI can make it harder to manage EFI boot loaders, particularly if you're unfamiliar with their principles. EFI also has its weaknesses, as described on this page.
Although EFI is intended to replace BIOS, many 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. More ambitious EFIs completely replace the legacy BIOS code, though. Such implementations can typically boot more quickly than can a BIOS, and they often 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.
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. 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 is offering a signing service, and several Linux distributions have begun to 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.
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 do 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. Therefore, when setting up a computer to boot in UEFI mode, it's generally best to create it as a GPT disk. In Linux, there are two main ways to create a GPT disk:
Most importantly, the venerable Linux fdisk, sfdisk, and cfdisk programs cannot yet modify GPT disks, so you should not use them on such disks. (Code to support GPT has been added to fdisk, but this version of the program is not yet widely available, as of April of 2013.)
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 many 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" 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 installer creates one of just 100MiB. 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, 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, but to the best of my knowledge, all current EFI-based x86-64 computers use 64-bit EFIs and therefore use a bootx64.efi default boot loader file. Some early Intel-based Macs used 32-bit EFIs, though, 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 default boot loader (normally EFI/BOOT/bootx64.efi) or a boot loader whose filename is stored in the firmware's flash memory. This boot loader can then load an OS directly (as the Windows EFI boot loader does) or it can present a menu or prompt with additional options (as Linux EFI boot loaders do).
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, and perhaps all, modern EFI-based computers include a BIOS compatibility mode that enables them to boot using BIOS boot loaders. This feature is officially known as the Compatibility Support Module (CSM). At the moment (early 2013), this mode is a simpler and more reliable way to boot Linux than is EFI mode, although users are increasingly using EFI mode because many Windows 7 PCs sold since mid-2011 and the vast majority of Windows 8 computers boot in EFI mode by default. Using EFI mode enables you to use GPT on a dual-boot computer, which may be desirable or even necessary if your boot disk is larger than 2 TiB. As EFI support matures, this situation is likely to change, and even today, EFI mode can work perfectly well if you're aware of the pitfalls. Typically, you can activate or deactivate EFI 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.
Because Linux, unlike Windows, can install to GPT on a BIOS-based computer, it's occasionally simpler to install Linux using BIOS compatibility mode and to then switch to EFI-style booting than it is to install directly in EFI mode. If you want to go this route, be sure to create a BIOS Boot Partition on the GPT disk. GRUB 2 uses this partition to store part of itself when it boots from a GPT disk. After Linux is installed, you can mount your ESP to /boot/efi, copy your chosen boot loader(s) to the ESP, and reconfigure the firmware to boot in EFI mode.
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. These problems may fade in time as EFI implementations improve and as better utilities become available to help manage boot loaders, but at the moment managing EFI boot loaders is harder than it should be.
In some cases it's desirable or even necessary to boot one OS in EFI mode and another in BIOS mode (or CSM or legacy mode, as it's increasingly being called). The prime example of this is on Macs that dual-boot between OS X and Windows; OS X boots in EFI mode and Windows boots in BIOS mode. The traditional way to do this is with Apple's Boot Camp software. Apple's EFI implementation enables a fairly seamless switch between the two boot modes by holding down the Option key during the boot process; this produces Apple's own boot manager menu, which enables you to select your boot OS. Alternatively, you can install rEFIt or rEFInd, both of which scan the computer for both EFI- and BIOS-bootable OSes and present a menu each time you boot.
On PCs that ship with an EFI-booting Windows, users sometimes mistakenly install Linux in BIOS mode, or want to install an OS that doesn't support EFI-mode booting, such as FreeBSD. Pressing F8, F12, or some other function key at boot time may produce a boot menu akin to that produced on Macs by holding down the Option key, enabling a change in boot modes. rEFInd 0.4.6 and later also support BIOS-mode booting on some (but not all) UEFI PCs.
The idea of CSM sounds good: It can help users transition from older OSes to newer ones, or to buy a replacement motherboard that's still able to run an existing BIOS-mode OS installation. Unfortunately, there are no set rules for when a computer should attempt an EFI-mode vs. a BIOS-mode boot. You could easily boot a Linux installer into BIOS mode from a CD-R, install Linux, and then be unable to boot because the computer is set to boot from the hard disk in EFI mode. What's more, the firmware user interface options for selecting your boot mode are inconsistent from one product to another, are usually poorly documented, and are often inadequate. Particularly in a dual-boot environment, therefore, a CSM can create as many problems as it solves. If you're having problems with booting on an EFI-enabled computer, you should read your motherboard's manual, check your CSM settings, and try to ascertain whether your OS installer has set itself up to boot in BIOS mode or in EFI mode.
Go on to "EFI Boot Loader Installation"
Return to "Managing EFI Boot Loaders for Linux" main page
If you have problems with or comments about this web page, please e-mail me at firstname.lastname@example.org. Thanks.
Return to my main Web page.