A seismic shift is underway in the computer world, and many people are unaware of the trembling beneath their feet. Since the IBM PC's introduction in 1981, most x86 and x86-64 computers have used the Basic Input/Output System (BIOS) firmware. The BIOS, however, is antiquated and limiting. The industry is, therefore, shifting from it to a new system, the Extensible Firmware Interface (EFI) and its even newer variant, the Unified EFI (UEFI). Although most computer features aren't affected by this change, it does greatly affect how the computer boots and how you must prepare your hard disk for OS installation. This article is the first in a series of four that describes these changes and helps you get Linux up and running on the new EFI-based computers. (I use “EFI” to refer to both the original EFI 1.x and the new UEFI, which is essentially EFI 2.x.)
This article describes the overall features and principles of EFI, including why you might want to use it, how EFI boots and what types of bootloaders you might use with it to enable Linux to boot on an EFI computer. The next three parts of this series will describe how to prepare to install Linux on an EFI computer, how to perform the installation and how to manage the computer once it's up and running.
Chances are you're using BIOS-based computers today. They work fine, and they boot fine, so why should you switch to EFI? In practice, you won't have much choice, because manufacturers are phasing BIOS out. Beyond this very pragmatic reason for switching, EFI has certain advantages over BIOS. To understand these new EFI features though, you first must understand what firmware in general does and the ways in which BIOS is deficient.
Firmware is software that's built in to a device, stored in nonvolatile memory, such as electronically erasable programmable read-only memory (EEPROM) chips. Motherboards, plug-in cards and many external devices all use firmware. Both BIOS and EFI firmware run on a computer's motherboard and perform several important tasks. Most important, the firmware contains the first code that the computer runs when it starts up. This code includes hardware check functions and functions that read and execute programs from the hard disk.
The IBM PC was introduced in 1981, so its BIOS was simple by today's standards. In particular, to begin the boot process, the BIOS loads the first sector of the boot device and executes it. On a hard disk, the first sector often is called the Master Boot Record (MBR), and it has several limitations that have been causing problems for 30 years:
The MBR bootloader is tiny. Typically, it chainloads additional code in a partition's boot sector or in some other location. The methods used to locate this extra code are usually simple, because neither the BIOS nor the MBR bootloader understands filesystems.
The computer's boot process is vulnerable to changes caused by writing new code to the MBR. OS installations sometimes render other OSes unbootable because they overwrite the MBR code, and viruses that embed themselves in the MBR have wreaked havoc over the years too.
Getting multiple OSes or OS installations to coexist can be difficult.
Because the BIOS design dates back 30 years, it uses ancient 16-bit 8086 operating modes. A 32-bit or 64-bit computer is unlikely to need these operating modes at all except for the boot process, but CPU manufacturers must continue to build those modes into their products just to support the BIOS.
EFI aims to overcome some of these BIOS limitations. Modern hardware makes larger firmware more practical than it was in 1981, so EFI implementations can be more complex than older BIOS designs. This added complexity enables EFI to perform tasks that BIOS implementation's can't handle. The key features of EFI include the following:
EFI can parse partition tables and filesystems, which enables bootloader code to be stored in files in a partition. Bootloaders, therefore, can be complex, and you can store as many of them as you like on your computer.
EFI implementations usually provide some means of selecting which bootloader to use and, therefore, which OS to boot, at boot time. In practice, these user interfaces still are usually pretty limited, so you may want to use another bootloader as the selector. (The upcoming section, “Choosing an EFI-Capable Bootloader”, describes some EFI bootloader options for Linux.)
If your OSes are well-behaved, they won't overwrite each others' bootloaders. Unfortunately, bugs can and do cause problems sometimes. Also, one bootloader must be designated as the primary one, and an OS might change the primary bootloader when it installs itself.
EFI supports drivers for filesystems and hardware, enabling you to boot from devices on plug-in boards even if those devices lack firmware of their own.
EFI implementations typically provide a simple command-line shell and a scripting language, enabling you to write boot-time scripts that can perform various tasks before any OS boots. You can use tools, such as text editors and partitioning utilities, to adjust your system if you run into boot problems.
The EFI specification describes a new partition table type, the GUID Partition Table (GPT). The old MBR partition system is limited to 232 sectors, which works out to 2 TiB on disks with 512-byte sectors. GPT uses 64-bit pointers, so its limit is 264 sectors, or 8 ZiB (zebibytes). Although you can use GPT on BIOS-based computers, Windows refuses to boot from GPT on BIOS-based computers. Because Windows boots fine from GPT on UEFI-based computers, UEFI is a practical necessity to boot Windows from a GPT disk.
Most modern EFI implementations include a BIOS emulation mode. This is a stopgap measure that enables you to install an OS with no or poor EFI support even on an EFI-based computer. Intel-based Macintoshes use this feature to boot Windows using Apple's Boot Camp software.
EFI designs can boot a computer more quickly than can BIOS designs. In my tests, the results typically are about 20 or 30 seconds faster when using EFI boot mode rather than BIOS boot mode.
EFI has its drawbacks too, of course. The most important of these is the fact that it's new. This means that old bootloaders don't work with it and users are unfamiliar with it. One more significant problem is that the EFI boot process assumes the OS will run in the same bit depth as the EFI. Because all UEFI-based PCs and most EFI-based Macs use 64-bit firmware, this means that 64-bit OSes work best with these computers. (The earliest Intel-based Macs used 32-bit EFIs though.) Installing a 32-bit version of Linux on a computer with a 64-bit EFI is possible, but you'll give up runtime EFI interfaces. This makes bootloader maintenance harder, since the efibootmgr utility (which will be described in part three of this series) relies on such interfaces. For this reason, I recommend installing a 64-bit distribution if your firmware is 64-bit.
Overall, EFI's feature set provides a great deal of flexibility. In theory, it should enable easier coexistence between different OSes on multiboot computers and easier maintenance of the boot process even on computers that boot just one OS. In practice, EFI booting still is new enough that it's sometimes awkward simply because the tools are new and small in number. Lack of familiarity also can make EFI awkward to those who know all the BIOS booting tricks.
Recall that the BIOS begins the boot process by reading a single sector (the MBR) from the hard disk. EFI is more complex though, so it can read a bootloader from a file in a filesystem. To do this though, the EFI requires its own partition, just as OSes usually require their own partitions. The EFI's dedicated partition is known as the EFI System Partition (ESP). Because the EFI's main job is to boot the computer, you're likely to find OS-specific bootloaders on the ESP.
The EFI specification states that the ESP should use the FAT-32 filesystem, but in practice, any filesystem that the EFI supports will work. This normally means FAT-12, FAT-16 and FAT-32. Macintoshes also can use HFS+. Some versions of Windows refuse to accept an ESP with anything but FAT-32, so I strongly recommend using FAT-32 on your ESP.
The ESP is identified by a specific type code in the partition table. On a GPT disk, you can set this type code in various ways:
If you use GPT fdisk (gdisk, cgdisk or sgdisk) to partition a GPT disk, you should give your ESP a type code of 0xEF00.
If you use a libparted-based utility, such as parted or GParted, you should set the “boot flag” on the disk. Note that this “boot flag” is not equivalent to a “boot flag” on an MBR disk, and on a GPT disk, you should set it only on the ESP.
Linux installations normally mount the ESP at /boot/efi. The EFI directory holds subdirectories, each of which holds bootloaders and their support files. For instance, EFI/Microsoft holds the Windows bootloader files, and EFI/ubuntu holds Ubuntu's bootloader. In Linux, these directories would be /boot/efi/EFI/Microsoft and /boot/efi/EFI/ubuntu. The EFI/BOOT directory holds a default bootloader file, should no other bootloader be installed. If you install an EFI bootloader independently of your OS installations, you probably will either place it in the EFI/BOOT directory as the default bootloader or create a new subdirectory named after the bootloader itself.
EFI programs, including bootloaders, have .efi filename extensions. You can use any name you like, although the default bootloader in the EFI/BOOT directory has a special name: BOOTX64.EFI on x86-64 systems.
You can store a startup script in the startup.nsh file in the ESP's root directory (that is, /boot/efi/startup.nsh in Linux). You can use this file to launch a bootloader or to provide user-selectable preboot options, but I don't describe it in detail in this series.
The EFI specification doesn't provide much guidance on the size of the ESP. The Microsoft Windows installer creates a 100 MiB ESP by default; Mac OS X creates a 200 MiB ESP, and Linux distributions create ESPs of various sizes. I recommend creating an ESP that's in the 200–300 MiB range, particularly if you use ELILO (described shortly).
EFI implementations should provide a boot manager that enables you to select which OS to boot. EFI maintains a list of bootloaders in Flash storage on the motherboard, and you normally can enter a boot manager utility at system startup time by pressing a special key, such as F10 or F12. Sometimes you can use this boot manager or the firmware's more complete setup utility to add or remove items from the boot manager's menu. If you can't find such options, you can use Linux's efibootmgr utility (described in part three of this series) to manage your boot options.
Because the EFI boot manager user interface varies so much from one implementation to another, you should consult your motherboard's or computer's documentation to learn more. If the documentation is unclear, you may need to experiment with it.
The universe of EFI bootloaders is quite limited compared to the range available for BIOS. Nonetheless, several bootloaders for Linux exist. Table 1 summarizes their features. The bootloaders include:
ELILO: in my experience, ELILO is the most reliable Linux bootloader on UEFI-based PCs; however, I've had little luck with it on a 32-bit Mac Mini. It can load Linux kernels from the ESP, but not from other locations. This means that your ESP must be big enough to hold as many Linux kernels and initial RAM disks as you care to install. ELILO can't chainload another bootloader, so if you want to multiboot with other OSes, you'll need to use your firmware's boot manager or another bootloader in addition to or instead of ELILO. It reads its configuration file, elilo.conf, from the same directory in which its .efi file resides.
GRUB Legacy: the official version of GRUB Legacy doesn't support EFI booting; however, Fedora has created a heavily patched version that does support EFI. This version of GRUB supports booting a Linux kernel or chainloading to another EFI bootloader. Thus, you may be able to use GRUB Legacy as your primary bootloader in a multiboot environment. It can read kernels from any common Linux filesystem, but not from an LVM or RAID configuration. In my experience, it's pretty reliable. It reads its configuration file from the same directory as its binary .efi file. The configuration file is named after the binary file—normally grub.conf.
GRUB 2: GRUB 2 officially supports both BIOS and EFI booting; however, you must install an EFI-capable package, such as grub2-efi under Debian or Ubuntu. GRUB 2 can load a kernel from any Linux filesystem on a partition, LVM or RAID configuration. It also can chainload to another EFI bootloader. The main problem with GRUB 2 is its complexity, which makes its installations delicate. Distribution configuration scripts sometimes get details wrong, at least for EFI installations, which can render your computer unbootable.
rEFIt: unlike ELILO, GRUB Legacy and GRUB 2, rEFIt isn't capable of directly booting a Linux kernel. Instead, it presents a menu of bootloader options. When you select a bootloader, rEFIt chainloads it. This makes rEFIt a useful replacement for an EFI implementation's bootloader, if that bootloader is limited or awkward. By default, rEFIt presents a graphical menu. The most common rEFIt binaries use a “fat” 32-/64-bit format that's usable only on Macs. If you have a UEFI-based PC, you must track down a pure 64-bit version of the program. (Debian and Ubuntu both ship with such packages; see the Resources section for another source for such binaries.)
The Linux kernel: work is underway to embed an EFI bootloader in the Linux kernel itself. When this work is done, you will be able to launch Linux directly, without using ELILO, GRUB Legacy or GRUB 2. You'll have to store the kernel and its initial RAM disk on the ESP or some other partition that the EFI can read though. This code is not yet available in any publicly released kernel, as of the 3.1-rc7 kernel, but see the Resources section for a set of patches.
Overall, my preference for an EFI-capable Linux bootloader is either ELILO or Fedora's patched GRUB Legacy. When multibooting with a non-Linux OS, ELILO works best when paired with rEFIt. GRUB 2 is just too finicky and unreliable. It might eventually be possible to boot the Linux kernel directly using no other bootloader, but this support is still extremely new and is not yet available in released kernels.
Part two of this series covers preparatory steps for installing Linux on an EFI computer—disk partitioning and understanding the features and limitations of some common Linux distributions with respect to EFI.