The rEFInd Boot Manager:
Methods of Booting Linux

by Roderick W. Smith, rodsmith@rodsbooks.com

Originally written: 3/19/2012; last Web page update: 5/6/2012, referencing rEFInd 0.3.3

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

This page is part of the documentation for the rEFInd boot manager. If a Web search has brought you here, you may want to start at the main page.


Windows and Mac OS X both provide relatively simple EFI boot loader programs. Launch them, and if they're launched from the correct locations and have the correct files in place, they'll boot their respective OSes. This makes rEFInd's job easy; it just locates the boot loader program files and runs them.

Under Linux, by contrast, things can get complicated. As detailed on my Managing EFI Boot Loaders for Linux page, several different EFI boot loaders for Linux exist, and all of them require configuration. If you're lucky, your distribution will have set up a Linux boot loader in a sensible way, in which case rEFInd should detect it and it will work as easily as a Windows or Mac OS X boot loader. If you're not lucky, though, you may need to configure it further. rEFInd offers options to help out with this task. Specifically, you can use a traditional Linux boot loader or configure an EFI stub loader.

Using a Traditional Linux Boot Loader

I consider ELILO, GRUB Legacy, and GRUB 2 to be traditional Linux boot loaders. These programs all exist as EFI programs that are independent of the Linux kernel, but that can load a kernel and hand off control to it. All three programs have their own configuration files that reside in the same directory as the boot loader itself (or optionally elsewhere, in the case of GRUB 2).

Ordinarily, rEFInd will detect these traditional boot loaders and provide main menu entries for them. If the boot loader exists in a directory with a name that matches a Linux distribution's icon filename, you'll automatically get a distribution-specific icon to refer to the boot loader.

If you prefer, you can disable automatic scanning and create an entry in refind.conf for your distribution, as described on the Configuring the Boot Manager page. This method is harder to set up but can be preferable if you want to customize your options.

Using the EFI Stub Loader

The Linux EFI stub loader is a way to turn a Linux kernel into an EFI application. In a sense, the kernel becomes its own boot loader. This approach to booting Linux is very elegant in some ways, but as described on the page to which I just linked, it has its disadvantages, too. One challenge to booting in this way is that modern Linux installations typically require that the kernel be passed a number of options at boot time. These tell the kernel where the Linux root (/) filesystem is, where the initial RAM disk is, and so on. Without these options, Linux won't boot. These options are impossible for a generic boot loader to guess without a little help. It's possible to build a kernel with a default set of options, but this is rather limiting. Thus, rEFInd provides configuration options to help.

With all versions of rEFInd, you can create manual boot loader stanzas in the refind.conf file to identify a Linux kernel and to pass it all the options it needs. This approach is effective and flexible, but it requires editing a single configuration file for all the OSes you want to define in this way. If a computer boots two different Linux distributions, and if both were to support rEFInd, problems might arise as each one tries to modify its own rEFInd configuration; or the one that controls rEFInd might set inappropriate options for another distribution. This is a problem that's been a minor annoyance for years under BIOS, since the same potential for poor configuration applies to LILO, GRUB Legacy, and GRUB 2 on BIOS. The most reliable solution there is to chainload one boot loader to another. The same solution is possible under EFI, but rEFInd offers another possibility.

rEFInd 0.2.1 and later supports semi-automatic Linux EFI stub loader detection. This feature works as part of the standard boot loader scan operation, but it extends it as follows:

  1. rEFInd looks for boot loaders whose names include the strings bzImage or vmlinuz and that end in .efi. For instance, bzImage-3.3.0.efi or vmlinuz-3.3.0-fc17.efi would match, and trigger subsequent steps in this procedure. Beginning with version 0.3.0, if you uncomment the scan_all_linux_kernels option in refind.conf, rEFInd will also scan for kernels without a .efi filename extension. This option is not the default, though, because it can pick up old kernels that lack EFI stub loader support and even non-kernel files, such as icon files named to give a kernel a unique icon.
  2. rEFInd looks for an initial RAM disk in the same directory as the kernel file. A matching initial RAM disk has a name that begins with init and that includes the same version string as the kernel. The version string is defined as the part of the filename from the first digit to the last digit, inclusive. Note that the version string can include non-digits. For instance, the version string for bzImage-3.3.0.efi is 3.3.0, which matches initramfs-3.3.0.bz; and vmlinuz-3.3.0-fc17.efi's version string is 3.3.0-fc17, which matches initrd-3.3.0-fc17.img. Many other matches are possible. If an initial RAM disk is identified, rEFInd passes a suitable initrd= option to the kernel when it boots.
  3. rEFInd looks for a file called refind_linux.conf in the same directory as the kernel file. This file is a practical requirement for booting from an auto-detected kernel. It consists of a series of lines, each of which consists of a label followed by a series of kernel options. The first line sets default options, and subsequent lines set options that are accessible from the main menu tag's submenu screen.

The intent of this system is that distribution maintainers can place their kernels, initial RAM disks, and a refind_linux.conf file in their own subdirectory on the ESP. rEFInd will detect their kernels and create one main menu entry for each kernel. Each entry will implement as many options as there are lines in the refind_linux.conf file. In this way, two or more distributions can each maintain their boot loader entries, without being too concerned about who maintains rEFInd as a whole.

The scan_all_linux_kernels option is intended to help users and distribution maintainers when rEFInd is used in conjunction with a Linux filesystem driver for EFI or when the ESP is mounted as the Linux /boot partition. In these cases, if all the kernels in Linux's /boot directory include EFI stub loader support, rEFInd will automatically detect and use kernels installed in the usual way, such as via an automatic system update. You won't even need to move or rename your kernels. You will need to set up a refind_linux.conf file and you may need to install a driver or set the also_scan_dirs option in refind.conf; but these are one-time requirements. Set up in this way, ongoing maintenance to handle kernel updates drops to zero!

As an example, consider the following file configuration:

$ ls -l /boot/efi/EFI/ubuntu/
total 17943
-rwxr-xr-x 1 root root  4781632 2012-03-18 12:01 bzImage-3.3.0.efi
-rwxr-xr-x 1 root root   131072 2011-10-14 04:10 grubx64.EFI
-rwxr-xr-x 1 root root 13459936 2012-03-18 12:02 initrd.img-3.3.0
-rwxr-xr-x 1 root root      266 2012-03-26 19:39 refind_linux.conf

When rEFInd scans this directory, it will find two EFI boot loaders in EFI/ubuntu: grubx64.EFI and bzImage-3.3.0.efi. rEFInd will create two main-menu tags for these two loaders, one of which will launch Ubuntu's standard GRUB and the other of which will launch the 3.3.0 kernel file directly. The refind_linux.conf file contains a list of labels and options:

"Boot with defaults"         "root=/dev/sda3 ro quiet splash vt.handoff=7"
"Boot into single-user mode" "root=UUID=1cd95082-bce0-494c-a290-d2e642dd82b7 ro single"
"Boot without graphics"      "root=UUID=1cd95082-bce0-494c-a290-d2e642dd82b7 ro"
# "Boot alternate install"   "root=/dev/sdb9 ro quiet splash vt.handoff=7"

Ordinarily, both fields in this file must be enclosed in quotes. You can include as much white space as you like between options. You can also place comments in the file, or remove an option by commenting it out with a leading hash mark (#), as in the fourth line in this example.

In the preceding example, the first line sets the options that rEFInd passes to the kernel by default (along with the name of the initrd.img-3.3.0 file, since its version string matches that of the kernel). The next two lines set options that you can obtain by pressing Insert, F2, or + on the main menu, as shown here:


rEFInd can load Linux boot options from
    a refind_linux.conf file in the Linux kernel's directory.

Note that the first entry shown here takes a name that's set in rEFInd rather than the one specified in the refind_linux.conf file. The remaining names match those specified in the file, though.

From a user's perspective, the submenus defined in this way work just like submenus defined via the submenuentry options in refind.conf, or like the submenus that rEFInd creates automatically for Mac OS X or ELILO. There are, however, limitations in what you can accomplish with this method:

Ordinarily, a kernel booted in this way must reside on the ESP, or at least on another FAT partition. On a Macintosh, though, you can use HFS+ to house your kernel files. In fact, that may be necessary; my Mac Mini hangs when I try to boot a Linux kernel via an EFI stub loader from the computer's ESP, but it works fine when booting from an HFS+ partition. If you use EFI drivers, though, you can place your kernel on any filesystem for which an EFI driver exists. This list is currently rather limited (ext2fs/ext3fs, ReiserFS, ISO-9660, and HFS+), but even just one or two options might help a lot if you've got an undersized ESP or if copying your kernel file to the ESP is a hassle you'd rather avoid.

Beginning with version 0.3.1, rEFInd sorts boot loader entries within each directory by time stamp, so that the most recent entry comes first. Thus, if you specify a directory name (or a volume label, for loaders stored in a volume's root directory) as the default_selection, rEFInd will make the most recent loader in the directory the default. This can obviate the need to adjust this configuration parameter when you add a new kernel; chances are you want the most recently-added kernel to be the default, and rEFInd makes it so when you set the default_selection in this way. If you don't want the latest kernel to become the default, you can use touch to give the desired kernel (or other boot loader) in the directory a more recent time stamp, or you can set default_selection to a value that uniquely identifies your desired default loader. One caveat you should keep in mind is that the EFI and Windows interpret the hardware clock as local time, whereas Mac OS X uses Coordinated Universal Time (UTC). Linux can work either way. Thus, time stamps for boot loaders can be skewed by several hours depending on the environment in which they were created or last modified.

On the whole, this method of configuration has a lot going for it. For distribution maintainers, if you place your Linux kernel files (with EFI stub support) on the ESP, with suitable filenames, matching initial RAM disk files, and a refind_linux.conf file, then any rEFInd 0.2.3 or later installation should detect your files, even if the user installs another distribution with another rEFInd that takes over from yours. (If the user, or this other rEFInd installation, disables auto-detection, this won't work.)

For end users, this method is simpler than maintaining manual configurations in refind.conf (or equivalents for ELILO or GRUB). To install a new kernel, you need only copy it and its initial RAM disk, under suitable names, to a scanned directory on the ESP. There's no need to touch any configuration file, provided you've already set up refind_linux.conf in your kernel's directory. You will, however, have to adjust refind_linux.conf if you make certain changes, such as if your root directory identifier changes.


copyright © 2012 by Roderick W. Smith

This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.

If you have problems with or comments about this Web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.

Go to the main rEFInd page

Learn about rEFInd's history

Return to my main Web page.