Originally written: 3/19/2012; last Web page update: -7/28/2014, referencing rEFInd 0.8.3
+3/4/2017, referencing rEFInd 0.10.5This 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!
@@ -41,8 +43,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com - -
+
@@ -56,8 +57,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
-
-
+
@@ -72,8 +72,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
-
-
+
@@ -87,8 +86,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
-
-
+
@@ -102,8 +100,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
-
-
+
@@ -116,8 +113,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
-
-
+
@@ -182,9 +178,9 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
This method requires that your /boot directory, whether it's on a separate partition or is a regular directory in your root (/) filesystem, be readable by the EFI. At the moment, all EFI implementations can read FAT and Macs can read HFS+. By using drivers, you can make any EFI read HFS+, ISO-9660, ReiserFS, ext2fs, ext3fs, ext4fs, or Btrfs. Thus, if you use any of these filesystems on a regular partition (not an LVM or RAID configuration) that holds your kernels in /boot, you qualify for this easy method. The default partition layouts used by Ubuntu, Fedora, and many other distributions qualify, because they use one of these filesystems (usually ext4fs) in a normal partition or on a separate /boot partition. You must also have a 3.3.0 or later Linux kernel with EFI stub support, of course.
+This method requires that your /boot directory, whether it's on a separate partition or is a regular directory in your root (/) filesystem, be readable by the EFI. At the moment, all EFI implementations can read FAT and Macs can read HFS+. By using drivers, you can make any EFI read HFS+, ISO-9660, ReiserFS, ext2fs, ext3fs, ext4fs, Btrfs, or other filesystems. Thus, if you use any of these filesystems on a regular partition (not an LVM or RAID configuration) that holds your kernels in /boot, you qualify for this easy method. The default partition layouts used by Ubuntu, Fedora, and many other distributions qualify, because they use one of these filesystems (usually ext4fs) in a normal partition or on a separate /boot partition. You must also have a 3.3.0 or later Linux kernel with EFI stub support, of course.
-If you installed rEFInd 0.6.0 or later with its install.sh script from your regular Linux installation, chances are everything's set up; you should be able to reboot and see your Linux kernels as boot options. If you installed manually, from OS X, or from an emergency system, though, you may need to do a couple of things manually: +
If you installed rEFInd 0.6.0 or later with its refind-install (formerly install.sh) script from your regular Linux installation, chances are everything's set up; you should be able to reboot and see your Linux kernels as boot options. If you installed manually, from OS X, or from an emergency system, though, you may need to do a couple of things manually:
If you're not sure you want to use the EFI stub loader in the long term, you can perform a fairly quick initial test of it. This procedure assumes that you have access to a 3.3.0 or later Linux kernel with EFI stub support compiled into it. (Fedora 17, Ubuntu 12.10, and probably other distributions ship with such kernels.) Creating this configuration poses no risk to your current boot options, provided you don't accidentally delete existing files. The procedure for a quick test is:
+If you're not sure you want to use the EFI stub loader in the long term, you can perform a fairly quick initial test of it. This procedure assumes that you have access to a 3.3.0 or later Linux kernel with EFI stub support compiled into it. (Fedora since version 17, Ubuntu since 12.10, and most other distributions ship with such kernels.) Creating this configuration poses no risk to your current boot options, provided you don't accidentally delete existing files. The procedure for a quick test is:
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 subdirectories on the ESP, on EFI-accessible /boot partitions, or in /boot directories on EFI-accessible Linux root (/) partitions. rEFInd will detect these 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!
+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 subdirectories on the ESP, on EFI-accessible /boot partitions, or in /boot directories on EFI-accessible Linux root (/) partitions. rEFInd will detect these kernels and create one main menu entry for each directory that holds kernels; or if fold_linux_kernels is set to false, one menu entry for each kernel. Each entry will implement as many options as there are lines in the refind_linux.conf file (multiplied by the number of kernels, if fold_linux_kernels is true). 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.
-As an example, consider the following file configuration:
+As an example, consider the following (partial) file listing:
-$ ls -l /boot/efi/EFI/ubuntu/ +$ ls -l /boot/vmlin* 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 +-rw-r--r-- 1 root root 5271984 Aug 7 10:18 /boot/vmlinuz-3.16.7-24-default +-rw-r--r-- 1 root root 5271536 Oct 23 17:25 /boot/vmlinuz-3.16.7-29-default-
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:
+When rEFInd scans this directory, it will discover two kernels in /boot. Assuming fold_linux_kernels is its default of true, rEFInd will create one main-menu tag for these two kernels. A refind_linux.conf file in this directory should contain a list of labels and options:
-"Boot with standard options" "root=/dev/sda3 ro quiet splash vt.handoff=7" -"Boot to single-user mode" "root=UUID=1cd95082-bce0-494c-a290-d2e642dd82b7 ro single" -"Boot with minimal options" "root=UUID=1cd95082-bce0-494c-a290-d2e642dd82b7 ro" -# "Boot alternate install" "root=/dev/sdb9 ro quiet splash vt.handoff=7" +"Boot with standard options" "ro root=UUID=084f544a-7559-4d4b-938a-b920f59edc7e splash=silent quiet showopts " +"Boot to single-user mode" "ro root=UUID=084f544a-7559-4d4b-938a-b920f59edc7e splash=silent quiet showopts single" +"Boot with minimal options" "ro root=UUID=084f544a-7559-4d4b-938a-b920f59edc7e" +# This line is a comment
Ordinarily, both fields in this file must be enclosed in quotes. If you have to pass an option that includes quotes, you can do so by doubling up on them, as in "root=/dev/sdb9 my_opt=""this is it""", which passes root=/dev/sdb9 my_opt="this is it" to the shell. 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:
+In the preceding example, the first line sets the options that rEFInd passes to the kernel by default (along with the name of the discovered initrd 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:
To assist in initial configuration, rEFInd's install.sh script creates a sample refind_linux.conf file in /boot. This sample file defines three entries, the first two of which use the default GRUB options defined in /etc/default/grub and the last of which uses minimal options. The first entry boots normally and the second boots into single-user mode. If you want to create a new file, you can use the mkrlconf.sh script that comes with rEFInd. If you pass it the --force option, it will overwrite the existing /boot/refind_linux.conf file; otherwise it will create the file only if one doesn't already exist.
+Note that in this example, the default kernel (the one with the most recent time stamp) appears first on the list, with the labels specified in refind_linux.conf. Subsequent kernels (just one in this example) appear below it, with the same labels preceded by the kernel filename. If you were to set fold_linux_kernels false, each kernel would get its own entry on the main menu, and each one's submenu would enable options for launching it alone.
+ +To assist in initial configuration, rEFInd's refind-install script creates a sample refind_linux.conf file in /boot. This sample file defines three entries, the first two of which use the default GRUB options defined in /etc/default/grub and the last of which uses minimal options. The first entry boots normally and the second boots into single-user mode. If you want to create a new file, you can use the mkrlconf script that comes with rEFInd. If you pass it the --force option, it will overwrite the existing /boot/refind_linux.conf file; otherwise it will create the file only if one doesn't already exist.
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 good (ext2fs/ext3fs, ext4fs, ReiserFS, Btrfs, ISO-9660, and HFS+), so chances are you'll be able to use this method to boot your kernel from your root (/) partition or from a /boot partition.
+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 good (ext2fs/ext3fs, ext4fs, ReiserFS, Btrfs, ISO-9660, HFS+, and NTFS in rEFInd, plus more from other sources), so chances are you'll be able to use this method to boot your kernel from your root (/) partition or from a /boot partition.
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.)
+On the whole, auto-detecting kernels and passing boot options using refind_linux.conf 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 rEFInd 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–2014 by Roderick W. Smith
+copyright © 2012–2017 by Roderick W. Smith
This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.