Originally written: 3/14/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.
rEFIt's author has abandoned the program; it hasn't been updated since March of 2010. Because rEFIt is very useful but has a number of limitations, I decided to fork a new project, rEFInd, to address them.
Like rEFIt, rEFInd is a boot manager, not a boot loader; however, when paired with a kernel that includes EFI stub support, rEFInd can boot a Linux kernel without the help of any other boot loader. Compared to rEFIt, rEFInd offers other configurability improvements, bug fixes related to UEFI systems, and additional icons for specific Linux distributions.
Overall, conditions when you might want to consider using rEFInd include:
Conditions in which you should probably not use rEFInd include:
If you're already using GRUB, there's little reason to add rEFInd to the picture unless you're having problems with GRUB 2 or if one of rEFInd's advantages not shared with GRUB 2 is important to you. In practice, rEFInd's boot loader auto-detection can be a great boon in a multi-boot environment; a large number of GRUB 2 problem reports relate to problems detecting or launching other OSes. rEFInd tends to handle such issues better, although it does have a tendency to pick up too many boot options. (You can trim them in various ways, as described in the rEFInd documentation.)
Overall, rEFInd is a capable modern boot manager. Like GRUB 2, it's low-maintenance once set up, but for different reasons; however, as GRUB 2 is the default boot loader for most distributions, GRUB 2 has an edge in initial configuration, especially if Secure Boot is enabled on the computer. rEFInd is easier than GRUB 2 to configure manually, including the sort of tweaks that are usually necessary when installing multiple Linux distributions. Like gummiboot/systemd-boot, rEFInd is a boot manager, not a boot loader, so it requires the use of the EFI stub loader.
rEFInd installation works as described in EFI Boot Loader Installation, with some small differences.
Since version 0.6.2, rEFInd has provided RPM and Debian packages that automatically run an installation script. If you've successfully booted into your regular EFI-mode Linux installation, this can make rEFInd installation a snap, since for most systems, everything will work fine when you reboot. A few distributions, including Arch, Debian, Gentoo, and Ubuntu, now offer rEFInd packages as part of their normal package archives. If your distribution doesn't use RPM or Debian packages and doesn't provide its own rEFInd package, you can download the binary zip file and run the refind-install script to simplify installation.
When you install rEFInd by copying files manually, your ESP's rEFInd directory should contain a refind_x64.efi file (or refind_ia32.efi on 32-bit systems), a refind.conf configuration file, an icons subdirectory that holds icons, and perhaps a keys subdirectory with Secure Boot keys. You can also install a few special .efi files that enable rEFInd to provide additional functionality. Most notable among these are:
If you're installing rEFInd on a Mac, you can sometimes install it on your macOS system volume rather than on your ESP. This works because a Mac's EFI can read HFS+ volumes. This installation location became less desirable with the release of OS X 10.10 ("Yosemite") because Apple began using a form of Logical Volume Management (LVM) by default with Yosemite, rendering the EFI (and therefore rEFInd) unable to access the macOS root (/) volume. Similarly, the use of APFS in macOS 10.12 and later installations on SSDs can render rEFInd installations to the root (/) volume unusable. The install script therefore installs to the ESP by default in rEFInd 0.8.4 and later.
Most rEFInd configuration options go in its main configuration file, refind.conf, which resides in the same directory as the rEFInd binary. If you use the semi-automatic kernel detection, though, you should probably also create a refind_linux.conf file in the same directory that holds your Linux kernels (or in all those directories, if you have more than one).
The refind.conf file is well-commented and may need no adjustment, particularly if you boot only EFI-based OSes. Like the GRUB and ELILO configuration files, refind.conf consists of two parts: global options and OS-specific boot loader definition stanzas. The default configuration uses no OS-specific stanzas; instead, it auto-detects EFI boot loaders. This behavior is controlled through the scanfor option in the global section:
scanfor manual,internal,external,optical,hdbios,biosexternal,cd,netboot
This example presents an over-the-top scan for every type of bootable medium. Specifically, manual scans for manual configuration stanzas, internal scans for internal EFI hard disks, external scans for external EFI disks, optical scans for EFI-bootable CD, DVD, and other optical discs, hdbios scans for internal BIOS hard disks, biosexternal scans for external BIOS disks, cd scans for BIOS-bootable optical discs, and netboot attempts a network (PXE) boot. (This last option requires an additional external binary.) The default on UEFI PCs is internal, external, optical, manual. On Macs, it's internal, hdbios, external, biosexternal, optical, cd, manual. The BIOS options are enabled by default on Macs because of the prevalence of Windows/macOS dual-boot configurations, which more-or-less require BIOS support on Macs. (This is changing, though; Windows 8 and later boot in EFI mode on many Macs.) There's generally little or no need for BIOS-mode boot support on UEFI-based PCs, although there are exceptions to this rule. Scanning for unnecessary boot sources can needlessly pad your boot loader list; leftover data or accidentally-installed BIOS boot loaders may be useless but appear as boot options. You can also use scanfor to limit the ability to boot external or optical media for security purposes (although you must also ensure that users can't bypass rEFInd by using the firmware's own options or by editing refind.conf). Although the manual option is enabled by default, the default configuration file includes no active manual boot stanzas; it's active to simplify the addition of such stanzas.
If you used my patched version of rEFIt, 0.14-rws, you should be aware that I've removed the quiet and ignorelegacy options I added for that version. The quiet option is no longer required because I've cleaned out the code that was displaying text-mode messages on the graphical screen. (You might still see such messages in case of serious problems, though.) The ignorelegacy option is redundant with and less flexible than the new scanfor option. The textonly option described on my rEFIt page is still available, but you're less likely to need it because of improved UEFI support and scrolling support for when you have more boot loaders than can be displayed at once.
rEFInd requires no configuration to identify specific boot loaders; depending on the scanfor options, it probes the ESP, macOS partitions, Linux /boot directory, and common locations for BIOS boot loaders to generate a menu of options. If you like, though, you can add stanzas that define particular boot loaders. This advanced configuration option is described in the rEFInd documentation.
With rEFInd, the easiest way to boot Linux kernels that employ the EFI stub loader is to use rEFInd's automatic boot loader detection code. In most cases, rEFInd will detect kernels placed in standard locations and given normal names, provided rEFInd can read the filesystem. As noted earlier, rEFInd can read FAT (and, on Macs, HFS+) via the EFI's built-in driver; and rEFInd comes with drivers for several common Linux filesystems. Note that, as of version 0.11.2, rEFInd does not ship with drivers for LVM or software RAID, so if you use LVM or software RAID, you must have a separate /boot partition that uses a supported filesystem. When run under the Linux you intend to boot, the refind-install script should install the appropriate driver; but you may need to add drivers in some unusual cases. See the rEFInd drivers documentation for details.
A refind_linux.conf file in the same directory as the kernels holds boot options. If you use the refind-install script to set things up, this file is created automatically. In case you need to create or edit it, you should know that this file consists of a series of lines, each of which has two fields: a name field and an options field. Each field is delimited by double quote marks ("). You can use a hash mark (#) as a comment field to add comments or remove temporarily unused entries. For example:
"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"
The first field on each line provides a name that's used on the rEFInd submenu page for an entry, and the second contains all the boot options you want to pass to the kernel. (rEFInd automatically generates an initrd= option based on the auto-detected initial RAM disk file.) At a minimum, you need one line in refind_linux.conf, which defines the default options. Subsequent lines define additional options you can access by pressing F2, Insert, or Tab after moving the cursor over a specific loader tag.
The big advantage of this method of configuration is that adding or replacing kernels is a snap; you need only copy them into the original kernel's directory under suitable names. rEFInd uses the same refind_linux.conf file for all the kernels it finds in this directory, so neither you nor your distribution's configuration scripts needs to edit any file when you add or replace a kernel file. (You can optionally change the default_selection option in refind.conf, but this isn't required.)
If rEFInd can't read a refind_linux.conf file, it attempts to generate a root= option for the kernel based on /etc/fstab (on the same partition as the kernel) or partition type codes. This process can succeed, particularly if your installation does not use a separate /boot partition. If your installation uses a separate /boot partition or requires unusual kernel options, though, this approach will likely fail and you'll have to create a refind_linux.conf file (or pass options manually) to boot.
When rEFInd is launched, it creates a display similar to the one shown here:
You can select your OS by using the arrow keys on the keyboard and pressing Enter, much as you would when using other boot loaders. If you use text mode, of course, the GUI display is replaced by a textual listing of options. The icons beneath the OS list provide access to rEFInd's tools—the shell, gptsync or gdisk program, a memory-test program, MokManager, Windows recovery tool, information about rEFInd, reboot, and program exit options, in this case. (These aren't the default options, and in fact what you'll see by default varies depending on your EFI's capabilities.) You can sometimes pass special options to a specific boot by pressing the F2, Tab, or Insert key once it's highlighted. This feature is most useful for macOS and Linux installations that boot via ELILO or a kernel's EFI stub loader. Pressing F2, Tab, or Insert again brings up an options editor so that you can customize options passed to the boot loader on a boot-by-boot basis. Shortcut keys, such as numbers to boot entries by the order in which they appear, are also supported.
Be aware that rEFInd, like rEFIt, can show useless entries. This is most likely to happen if you leave the automatic scans for BIOS entries enabled on a computer with either no BIOS-bootable OS or a UEFI-based PC. Eliminating unwanted entries is described in the rEFInd documentation. In most cases, hitting the Delete or minus (-) key after highlighting an entry is the easiest way to hide it.
Ideally, rEFInd requires little maintenance. Because it auto-detects boot loaders, you shouldn't need to adjust it when you install a new OS, provided the new OS installs its EFI boot files in a reasonable location. rEFInd normally requires no maintenance when you upgrade your kernels; however, you (or your distribution's scripts) must update your follow-on boot loader's configuration when you update your kernel. If you rely on semi-automatic detection of your Linux kernels with EFI stub loader support, rEFInd should detect your kernel upgrades. If you create your own rEFInd boot stanzas that boot a Linux kernel with EFI stub loader support, though, you'll have to maintain those entries manually, much as you would with custom GRUB, SYSLINUX, or ELILO entries.
Go on to "Using gummiboot/systemd-boot"
Return to "Managing EFI Boot Loaders for Linux" main page
copyright © 2011-2018 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.