Originally written: 9/23/2011; last update: 6/30/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|
With the rising availability of Extensible Firmware Interface (EFI) and Unified EFI (UEFI) computers, there's an increasing need to configure EFI boot loaders, particularly in multi-boot environments. The way EFI computers boot is very different from the way older computers based on the Basic Input/Output System (BIOS) boot. This fact is both positive and negative. On the plus side, the EFI boot method is much more flexible and, in theory, easier to configure than is the BIOS boot method. On the minus side, existing documentation and personal skills are often built around BIOS, which can make setting up an EFI-based system tricky. There's also the fact that most Linux distributions provide weaker EFI than BIOS support.
I've written this set of Web pages with the goal of explaining some of the basics of the EFI boot methods, most notably including how to install and manage EFI boot loaders. This document is broken into a number of sections, as detailed below.
Note: Another EFI boot loader for Linux, efilinux, is an out-of-kernel precursor to the kernel's EFI stub loader. It's got the stub loader's disadvantages and few of its advantages. I've had little success getting it working, although I've only tested it on a couple of systems. I therefore don't cover it here, aside from this paragraph. At least two additional programs are under development to help work around boot problems associated with Secure Boot; these are described in the section on Secure Boot.
In my experience, EFI boot loaders capable of booting Linux can be ranked as follows, from best to worst:
SYSLINUX isn't on the list because it's so new that I don't yet have enough experience with it to judge its reliability. rEFIt isn't on the list because it's very awkward at booting the Linux kernel by itself; it's used to select between a Linux-capable boot loader and a non-Linux boot loader such as one that boots Windows or OS X. Although rEFIt can boot a kernel with the EFI stub loader compiled in, this works in practice only if the kernel has been compiled with the precise boot options you need for your system; rEFIt doesn't know how to pass other options to the Linux kernel. rEFInd can be configured to provide such options, and this combination works well, in my experience. Although I have less experience with gummiboot than with rEFInd, gummiboot seems to work well with the EFI stub loader, too. As of April 2013, most distributions with short release cycles, such as Fedora 17 and Ubuntu 12.10 (and later versions of these distributions), ship with kernels that include EFI stub support; however, older distributions don't include this support, which complicates using the EFI stub loader. One complication of the EFI stub loader is that some users, particularly with Macs and Lenovos, seem to be having problems with some kernels in the 3.7.x and 3.8.x series. See this Arch Linux forum thread for details.
ELILO and GRUB Legacy come in very close to each other in reliability, in my experience. I give the nod to ELILO over GRUB Legacy because ELILO is quite consistently reliable between systems, with one exception (a 32-bit Mac Mini), on which ELILO fails completely. GRUB Legacy, by contrast, is a bit more finicky across the board—it occasionally fails to boot or has system-specific quirks, usually relating to its handling of the display. On the plus side, it works well with that Mac Mini that gives ELILO fits. If you can't boot a post-3.3.0 kernel but have a choice of boot loaders and if you're not comfortable building a cutting-edge kernel yourself, then IMHO these are the EFI boot loaders to try.
GRUB 2 has been very finicky in my tests, although my experience with the latest release is limited. It seems to be most reliable when it's configured to store its configuration data on the EFI System Partition (ESP); however, several distributions (Ubuntu, Mint, and OpenSUSE) unwisely place their GRUB 2 configuration files and other support files in the Linux /boot directory, which reduces GRUB 2's reliability. The GRUB 2 scripts for creating final configuration files also often get things wrong; many experienced users prefer to create custom grub.cfg files manually, which can improve reliability. As a practical matter, most EFI-based Linux computers use GRUB 2, because the biggest distributions (Ubuntu and Fedora 18 and later) use GRUB 2 by default.
Both versions of GRUB can function as boot managers for non-Linux OSes; that is, they can chainload other boot loaders, much as rEFIt, rEFInd, and gummiboot can. They require more in the way of manual (or scripted) configuration to detect non-Linux OSes, though. Also, if you use Secure Boot, GRUB can be finicky about launching non-Linux OSes. ELILO is a Linux-only tool; if you multi-boot with another OS, you'll need to use another program to switch between Linux and your other OS.
Be aware that there are significant system-specific quirks. I've never gotten ELILO to work on my 32-bit Mac Mini, for instance. ELILO does work with a 32-bit version of VirtualBox's EFI, so I suspect a Mac-specific quirk—but I've seen many references to ELILO working on Macs, so it may be model-specific, or I may be doing something wrong.
If you have a computer that shipped with Windows 8 installed, chances are the firmware is set to use Secure Boot. This is a feature designed to prevent malware from infecting the computer before the OS has a chance to take over. Unfortunately, it also complicates the installation and management of boot loaders. If you need help, read my section on Secure Boot.
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.