Originally written: 3/14/2011; last update: 7/17/2017
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. rEFInd offers other configurability improvements, bug fixes related to UEFI systems, and additional icons for specific Linux distributions.
If you're already using GRUB, there's little reason to add rEFInd to the picture unless you're having problems with your GRUB scripts not detecting other OSes or if you want a prettier boot screen. If you've got a kernel with EFI stub loader support, though, rEFInd can load it as well as anything else, and it has the advantage (shared with rEFIt) that it can automatically detect other OSes' boot loaders. In fact, this auto-detection can be a great boon; 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 by using the dont_scan_volumes, dont_scan_dirs, and dont_scan_files configuration file options, or by deleting extraneous boot loader files.)
One significant advantage of rEFInd is that it can semi-automatically detect Linux kernels with EFI stub support. This can make kernel upgrades a snap: Once you've created a refind_linux.conf file in the directory that holds your kernels, you need only copy your kernel files and matching initial RAM disk files to that directory to boot them. One limitation to this feature is that rEFInd must be able to read the filesystem on which the kernels are stored. rEFInd comes with EFI filesystem drivers for ext2fs/ext3fs, ext4fs, ReiserFS, and Btrfs, as well as some non-Linux filesystems; and of course FAT (and HFS+ on Macs) is supported via the EFI's standard drivers; but for more exotic filesystems, including JFS and XFS, you must look elsewhere for drivers. You must also be careful about file naming as described shortly, in Configuring rEFInd.
One feature of rEFInd that's critical for some multi-booters is its ability to redirect the boot process to BIOS boot loaders. rEFIt supports this feature, too, but only on Macs; rEFInd provides it on both Macs and most UEFI-based PCs, although it's disabled by default on the latter. (To enable it, you must edit the scanfor line in the refind.conf configuration file. Installing both BIOS-mode and EFI-mode OSes on one computer is generally a bad idea, as described on the CSM: The Good, the Bad, and the Ugly page. If you really must do it, though, rEFInd can remove some of the pain of such a configuration.
Compared to its parent rEFIt, rEFInd offers bug fixes and better project support for UEFI-based PCs; but rEFInd provides less in the way of integration into a Mac environment. For instance, rEFIt provides a point-and-click installer for Mac OS X, but for various reasons I've dropped that support in rEFInd. (One of these reasons is reports of disk corruption that may be caused by the point-and-click installer package, so its availability may not be a great boon.) On the other hand, the Apple's System Integrity Protection (SIP) feature in OS X 10.11 and later would cause problems for rEFIt installation. These problems can be surmounted, but you'll need to read up on SIP to do so. Although rEFInd installation is also affected by SIP, he rEFInd documentation covers this issue. rEFInd offers some configurability and usability improvements over rEFIt, such as better options to define precisely how to scan for OSes and support for a scrolling list of OSes (which is useful if you've got many of them installed). rEFInd can also handle Linux kernels with EFI stub support better than rEFIt can. With rEFIt, you're limited to the boot options compiled into the kernel, as described on the EFI stub page; but rEFInd enables you to pass arbitrary options to such kernels. Since version 0.5.0, rEFInd can talk to the shim boot loader, which is a specialized tool to help boot on computers that use Secure Boot.
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. If your distribution doesn't use RPM or Debian packages, you can download the binary zip file and run the refind-install script to achieve much the same effect.
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 OS X 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 OS X root (/) volume. 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:
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/OS X 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, OS X partitions, 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. 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 or Insert 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 Mac OS X 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. If you have such entries, you may be able to eliminate them by adjusting the scanfor option in the global configuration section. If you want to eliminate an EFI boot option but continue automatic scans for others, you can rename the boot loader's .efi file or move its directory inside rEFInd's main directory. (rEFInd doesn't scan its own directory for boot loaders.) The dont_scan_volumes, dont_scan_dirs, and dont_scan_files options in refind.conf can also hide specific volumes, directories, and files from the rEFInd menu.
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-2017 by Roderick W. Smith
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.