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.
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 and boot managers, such as ELILO, GRUB Legacy, GRUB 2, the kernel's EFI stub loader, rEFIt, and rEFInd.
Before proceeding, understand that most Linux distributions' installers set up a boot loader (normally GRUB 2) automatically. Even if something has gone wrong with that process, chances are you needn't perform every step described on this page. I first wrote this page when Linux distributions had much poorer EFI support than exists now. Today, this page presents a reasonably thorough description of completely manual EFI boot loader installation. You'll need this information if you're using a distribution with poor EFI support or if you want to install a non-standard EFI boot loader, particularly if your system does not already boot in EFI mode. This page also assumes familiarity with Linux text-mode system-administration tools; if you're a first-time Linux user, you'll find this page difficult to understand. I recommend you read up on Bash and other system administration basics and come back later.
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. In the case of buggy EFIs or if you want to create a bootable USB drive, you may need to rename your boot loader to work around its bugs.
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 or /dev/sda2, 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 Disk flags: Number Start End Size File system Name Flags 1 225kB 210MB 210MB fat32 EFI System boot, esp 2 210MB 420MB 210MB ext2 Ubuntu 18.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 (with a redundant esp flag in recent versions of the program) 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 configuring 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.
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.
In addition to the program's .efi file, you may need to copy a configuration file and other support files. If the source of the .efi file includes these extra files, copying the whole directory, as specified earlier, will copy them, too. You may need to copy them from elsewhere, rename them, or modify them, though. See program-specific documentation for details.
Note that some EFI boot loaders provide installation scripts. GRUB 2 comes with grub-install and rEFInd comes with refind-install, for instance. The details of what these scripts do vary from one program to another. Typically, they copy the necessary files and register the boot loader (as described in the next section).
In some cases, you may need to use a fallback filename, as described later, in Using a Fallback Filename.
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 often 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. In this example, 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.) Recent versions of efibootmgr also accept the usual Linux-style forward slashes (/) and translate them to the EFI's native backslashes.) Also note that at least one manufacturer (Lenovo) once shipped 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. I know of no recent (ca. 2014 or later) computers with this bug.
Unfortunately, not all EFIs properly add boot options when you use efibootmgr. Sometimes this problem is caused by EFI bugs that must be worked around by renaming boot files, as described shortly. Other times, though, non-Linux tools seem to work better. I know of several other tools that might work:
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 EFI mode in some other way—or perhaps your other way will be perfectly acceptable to you.
As a one-time boot solution, if you can launch an EFI shell, you can navigate to the directory in which your boot loader file exists and launch it by typing its name. The EFI shell prompt is similar to a DOS or Bash prompt and takes similar commands. This approach is awkward to use on a regular basis, but it can be useful if you just need to get your boot loader launched once so that you can use efibootmgr or some other Linux-based tool.
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 an EFI 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. (You don't need to add this detail unless you've created a separate /boot 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.
As described on this site's Basic Principles page, the fallback filename (EFI/BOOT/bootx64.efi on x86-64 computers) is used to make removable media bootable. In most cases, you should not use this filename for your primary boot loader on a hard disk. Doing so would give up some of EFI's key benefits over BIOS, such as the ability of multiple boot loaders to coexist and the ability to identify a boot loader by the directory and/or filename in which it's stored. In some cases, though, you may need to resort to using a fallback filename. Examples of these cases include:
Broadly speaking, there are two alternative names that are most useful:
You can move and rename your boot loader manually from any OS by following these steps:
When you reboot, your desired boot program should come up. In some cases, you may need to add or alter boot loader configuration files so that the Windows boot loader is detected. Sometimes you might want or need to copy the boot loader rather than move or rename it. In this case, adjust the procedure accordingly.
If you had to move or rename an existing boot loader in order to put yours in the fallback position, then be aware that whatever put the original file there might notice the change and undo it. Thus, you could be facing a never-ending battle for control of the computer's boot process. This is the type of problem that the NVRAM-based EFI boot manager entries were meant to avoid, and one of the reasons you should use this approach on a hard disk only as a last resort or as a backup to the conventional name. Such a backup plan is often implemented via the fallback.efi program.
Go on to "Using ELILO"
Return to "Managing EFI Boot Loaders for Linux" main page
copyright © 2011–2017 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.