Managing EFI Boot Loaders for Linux:
EFI Boot Loader Installation

by Rod Smith, rodsmith@rodsbooks.com

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
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal

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.

If you're scratching your head over how to get Linux booting in EFI mode on a new computer, your should understand the general principles involved in boot loader installation. With these principles in hand, you can apply them to specific boot loaders, such as ELILO, GRUB Legacy, GRUB 2, the kernel's EFI stub loader, rEFIt, and rEFInd.

Obtaining a Boot Loader

The first step, of course, is to obtain a boot loader. As with most software, you can install EFI boot loaders in several different ways:

For the most part, the advantages and disadvantages of each approach are the same as the advantages and disadvantages of installing other software in each way. (If you're new to Linux, know that package systems are generally the easiest and safest ways to manage software.) Many EFI boot loaders, though, don't install completely and automatically using the package system. That is, the boot loader files are installed to somewhere in the Linux directory tree, but not to the /boot/efi directory where the EFI System Partition (ESP) is normally mounted. Thus, to actually use the boot loader, you must mount the ESP, copy the boot loader's files to the ESP, and register the boot loader with the firmware, as described on this page.

Accessing the ESP

If your computer is already booting in EFI mode, chances are the ESP is mounted at /boot/efi. If you're uncertain of this, though, you can try typing df /boot/efi at a shell prompt. If your ESP is mounted at this location, it will show up as a separate mount point:

$ df /boot/efi
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1               201633     33104    168530  17% /boot/efi

This example shows /dev/sda1 mounted at /boot/efi. The ESP is usually /dev/sda1, but this isn't always the case, so if you see another partition specified, it might still be correct. If your ESP is not mounted, the df command may show /boot or / under the Mounted on column; or it may return an error message to the effect that there is no such file or directory as /boot/efi. If df showed that the ESP was not mounted, then you should mount it (after creating the /boot/efi mount point, if necessary), but you'll need to know what partition to mount. You can use parted to view the partitions on your disk:

# parted /dev/sda print
Model: ATA ST32000542AS (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                  Flags
 1      225kB   210MB   210MB   fat32        EFI System            boot
 2      210MB   420MB   210MB   ext2         Ubuntu 11.04 /boot
 3      420MB   629MB   210MB   ext2         Linux /boot (unused)
 4      629MB   2000GB  2000GB               Linux LVM             lvm

In parted, an ESP is identified by the boot flag and a FAT filesystem—ideally FAT32, but sometimes FAT16 or even FAT12. With your ESP identified, you can mount it:

# mount /dev/sda1 /boot/efi

If it succeeeds, this command will return to another shell prompt. You can verify that it worked by repeating the df command to verify that it's mounted; or you can view its contents:

$ ls /boot/efi
EFI  startup.nsh

Most ESPs have just a single EFI directory in their root directories; however, this example also has a shell script, startup.nsh. You can also view the EFI directory, which may have subdirectories for its boot loaders. (Since FAT is case-insensitive, the EFI directory might show up as efi or some other variant.) On some distributions, you may need root privileges to view the files in the ESP.

If you're reconfiguring a computer to boot in EFI mode, you might want to add an entry for the ESP to your /etc/fstab file, which controls how partitions are mounted when the computer boots. An example entry looks like this:

/dev/sda1   /boot/efi       vfat    defaults        0       1

Many distributions use a UUID=####-#### value rather than a device filename to specify the ESP. This is fine, so if you see such an entry and your ESP mounted correctly, there's no need to change it. If you see such an entry but your ESP did not automatically mount, you can either replace the UUID=####-#### notation with /dev/sda1 (or whatever the device filename is) or type blkid /dev/sda1 to find the correct UUID value.

Copying Boot Loader Files

Installing boot loader files to the ESP is a matter of using the Linux cp command (or its GUI drag-and-drop file manager equivalents) on the boot loader files. If you're installing a new boot loader, though, you may need to create a directory for it first. The total set of commands might resemble the following:

# cd original-directory
# mkdir /boot/efi/EFI/newloader
# cp -r * /boot/efi/EFI/newloader

These commands copy all the files from original-directory to a suitable directory (/boot/efi/EFI/newloader) on the ESP. Of course, original-directory must hold the original EFI boot loader files, and ideally nothing else—there's no point in wasting disk space on source code or other irrelevancies. Be sure that the files you copy include at least one file with a name that ends in .efi—this filename extension denotes an EFI binary file, such as a boot loader file. Some boot loaders require other files be copied, too, such as a configuration file or even your Linux kernel. I describe such requirements on the pages devoted to specific boot loaders.

If you want the boot loader to be the default in case the NVRAM entries are cleared, you can use /boot/efi/EFI/BOOT as the target directory for the .efi file, and you can rename the boot loader to bootx64.efi (assuming an x86-64 architecture). On most systems, this name makes the boot loader the default. Some EFI implementations use EFI/Microsoft/BOOT/bootmgfw.efi (on the ESP) as a default name in addition to or instead of EFI/BOOT/bootx64.efi, so you can try that name and location, too. (I've received reports that this name is required on at least some HP computers.)

Registering the Boot Loader with the EFI

The final step to installing a boot loader is to make the EFI recognize it. This step can be tricky because it varies from one system to another.

If you're booted using EFI mode, you can use the efibootmgr program to add your new boot loader to the EFI's boot menu. The command to do so looks like this:

# efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\newloader\\loadername.efi -L NewLoader

This example adds /boot/efi/EFI/newloader/loadername.efi on /dev/sda1 to the EFI's internal menu of boot options. (You can usually omit the -d /dev/sda and -p 1 options, which specify the disk device and partition number; they're only needed if the ESP is something other than /dev/sda1.) The resulting entry should appear under the name NewLoader. Note that the filename is specified relative to the ESP's root directory, using doubled-up backslashes (\\) rather than Linux's usual slashes (/) as separators. (Alternatively, you can enclose the filename specification in quotes and use single backslashes, \, rather than doubling them up.) Also note that at least one manufacturer (Lenovo) ships products with a known bug that causes the system to refuse to boot unless the boot loader's name (NewLoader in this example) is either Windows Boot Manager or Red Hat Enterprise Linux.

Unfortunately, not all EFIs seem to properly add boot options when you use efibootmgr. Also, the command is useless if you're currently booted in BIOS mode—for instance, if you installed Linux in BIOS mode but want to switch to EFI booting. Thus, you may want to use another method to specify the boot loader. I know of several other possibilities:

With any luck, you should be able to get your desired boot loader launched using one of these methods. If you couldn't use efibootmgr because you were initially booted in BIOS mode, you can try again with efibootmgr once you boot in UEFI mode in some other way—or perhaps your other way will be perfectly acceptable to you.

If your computer stubbornly boots into Windows after you've installed Linux, you can download a CD or USB flash drive version of rEFInd. This may be easier to get started than Linux, and it should enable you to launch a (version 1) shell, or perhaps to launch Linux. In some cases, though, you may need to add boot options to launch Linux, particularly if rEFInd detects the Linux kernel (vmlinuz-*) and offers to launch it directly. With the kernel highlighted in rEFInd, press the F2 or Insert key twice. This opens a text editor in which you can add ro root=/dev/sda# to the boot options, where /dev/sda# is your Linux installation's root partition. If this approach is successful in launching Linux, then installing rEFInd in Linux will probably get the computer to boot rEFInd, and from there Linux, more directly.


Go on to "Using ELILO"

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 rodsmith@rodsbooks.com. Thanks.

Return to my main Web page.