Originally written: 3/14/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|
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 the new (as of the 3.3 kernel series) 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 Legacy or GRUB 2, 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 directory on your ESP with a refind_linux.conf file, you need only copy your kernel files and matching initial RAM disk files to that directory to boot them. If you have an EFI filesystem driver for the filesystem on which your kernels are stored, you need only give your kernels appropriate names to have them auto-detected. In either event, you must be careful about file naming as described shortly, in Configuring rEFInd.
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.) 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 install.sh 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 (and normally should) install it on your OS X system volume rather than on your ESP. This works because a Mac's EFI can read HFS+ volumes.
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, and cd scans for BIOS-bootable optical discs. 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.) 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. To do this, you must follow specific rules in placing your files:
The kernel and initial RAM disk file naming conventions mostly match those used by most distributions; you need only copy or move the files to a suitable location on the ESP. If you're using one of the supported filesystems, you needn't even do this.
Aside from placing files, the only thing you'll have to do to get this method of booting working is to create a refind_linux.conf file; but if you use the install.sh script to set things up, this file is created automatically. In case you need to 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 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.)
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 program, information about rEFInd, reboot, and program exit options, in this case. (These aren't the default options; by default, you'll see a shutdown option but no exit or gptsync options.) You can sometimes pass special options to a specific boot by pressing the F2 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 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.)
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. If you use GRUB or ELILO to boot your Linux kernel, rEFInd requires no maintenance when you upgrade your kernels; however, you (or your distribution's scripts) must update your GRUB Legacy, GRUB 2, or ELILO configuration when you update your kernel. If you rely on semi-automatic detection of your Linux kernels with EFI stub loader support, you need only place them appropriately, as described earlier, for rEFInd to 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 or ELILO entries.
Go on to "Using gummiboot"
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 firstname.lastname@example.org. Thanks.
Return to my main Web page.