<link href="../Styles/styles.css" rel="stylesheet" type="text/css" />
</head>
+<meta name="viewport" content="width=device-width, initial-scale=1">
+
<body>
<h1>The rEFInd Boot Manager:<br />Methods of Booting Linux</h1>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/19/2012; last Web page update:
-8/25/2013, referencing rEFInd 0.7.4</p>
+9/19/2015, referencing rEFInd 0.9.2</p>
-<p>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!</p>
+<p>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!</p>
<table border="1">
<tr>
<h2>Using a Traditional Linux Boot Loader</h2>
</a>
-<p>I consider <a href="http://www.rodsbooks.com/efi-bootloaders/elilo.html">ELILO,</a> <a href="http://www.rodsbooks.com/efi-bootloaders/grub_legacy.html">GRUB Legacy,</a> and <a href="http://www.rodsbooks.com/efi-bootloaders/grub2.html">GRUB 2</a> to be traditional Linux boot loaders. These programs all exist independent of the Linux kernel, but they 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).</p>
+<p>I consider <a href="http://www.rodsbooks.com/efi-bootloaders/elilo.html">ELILO</a>, <a href="http://www.rodsbooks.com/efi-bootloaders/grub_legacy.html">GRUB Legacy</a>, <a href="http://www.rodsbooks.com/efi-bootloaders/grub2.html">GRUB 2</a>, and <a href="http://www.rodsbooks.com/efi-bootloaders/syslinux.html">SYSLINUX</a> to be traditional Linux boot loaders. These programs all exist independent of the Linux kernel, but they can load a kernel and hand off control to it. All four 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).</p>
<p>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.</p>
<li>Copy the relevant driver file for your filesystem and architecture to
the <tt>drivers</tt> or <tt>drivers_<tt class="variable">arch</tt></tt>
- subdirectory of the rEFInd installation directory on the ESP. You may
- need to create this subdirectory, too.</li>
+ subdirectory of the rEFInd installation directory on the EFI System
+ Partition (ESP). You may need to create this subdirectory, too.</li>
<li>Create a <tt>refind_linux.conf</tt> file in your <tt>/boot</tt>
directory. The <tt>mkrlconf.sh</tt> script that comes with rEFInd
href="#efistub">later.</a> Starting with version 0.6.12, rEFInd can
create minimal boot options from <tt>/etc/fstab</tt>, if <tt>/boot</tt>
is <i>not</i> a separate partition, so a <tt>refind_linux.conf</tt>
- file may not be strictly necessary. It remains desirable, though, and
- is necessary if <tt>/boot</tt> is on a separate partition or if you
- need unusual kernel options to boot your computer.</li>
+ file may not be strictly necessary. Version 0.9.0 also adds the ability
+ to identify the root (<tt>/</tt>) partition via the <a
+ href="http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">Discoverable
+ Partitions Spec,</a> if your disk uses the appropriate type codes. A
+ <tt>refind_linux.conf</tt> file remains desirable, though, and is
+ necessary in some situations.</li>
</ul>
loader to another. The same solution is possible under EFI, but rEFInd
offers another possibility.</p>
-<p>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:</p>
+<p>rEFInd 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:</p>
<ol>
rEFInd won't scan for kernels that lack <tt>.efi</tt> filename
extensions.</li>
+<li>If a file's name ends in <tt>.efi.signed</tt>, any other file with an
+ otherwise-identical name that <i>lacks</i> this extension is excluded.
+ This peculiar rule exists because Ubuntu has begun delivering two
+ copies of every kernel, one with and one without this extension. The
+ one with the extension is signed with a Secure Boot key; the one
+ without it is not so signed. Thus, if both files are present, the one
+ without the key won't boot on a computer with Secure Boot active, and
+ either will boot if Secure Boot is inactive. Thus, rEFInd excludes the
+ redundant (unsigned) file in order to help keep the list of boot
+ options manageable.</li>
+
<p class="sidebar">A kernel whose filename lacks a version string matches an initial RAM disk that also lacks a version string in its filename. Note that you can reliably use only <i>one</i> kernel and initial RAM disk per directory that lack version numbers in their filenames.</p>
<li>rEFInd looks for an initial RAM disk in the same directory as the
initial RAM disk is identified, rEFInd passes a suitable
<tt>initrd=</tt> option to the kernel when it boots.</li>
-<p class="sidebar">rEFInd 0.2.1 and 0.2.2 used a filename of <tt>linux.conf</tt> to hold Linux kernel options; however, the Linux kernel developers plan to use this name themselves, so I've switched to <tt>refind_linux.conf</tt> as of rEFInd 0.2.3. Through version 0.4.2, rEFInd still supported the <tt>linux.conf</tt> filename as a backup to <tt>refind_linux.conf</tt>, but as of version 0.4.3, <tt>linux.conf</tt> no longer works, so you should rename rEFInd's <tt>linux.conf</tt> file to <tt>refind_linux.conf</tt> if you're upgrading.</p>
-
<li>rEFInd looks for a file called <tt>refind_linux.conf</tt> 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,
+ directory as the kernel file. 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. If
<p>rEFInd sorts boot loader entries <i>within each directory</i> 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 <tt>default_selection</tt>, 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 <tt>default_selection</tt> in this way. If you <i>don't</i> want the latest kernel to become the default, you can use <tt>touch</tt> to give the desired kernel (or other boot loader) in the directory a more recent time stamp, or you can set <tt>default_selection</tt> 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 <a href="http://en.wikipedia.org/wiki/Coordinated_Universal_Time">Coordinated Universal Time (UTC)</a>. 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.</p>
+<p>Prior to rEFInd 0.9.0, each Linux kernel appeared as a separate entry in the main rEFInd menu. This could make for a very crowded menu if you kept many old kernels and/or if you have several Linux distributions installed. rEFInd 0.9.0 adds a "folding" feature, in which multiple kernel entries in a single directory appear as a single entry in the main menu. Selecting that entry launches the kernel with the most recent time stamp. To launch an older kernel, you must press F2 or Insert; older kernels appear in the submenu shown earlier, but with the kernel filename prepended to the description. If you want to launch an older kernel by default, you can <tt>touch</tt> it in Linux, as in <tt>touch /boot/vmlinuz-3.6.0</tt> to make <tt>/boot/vmlinuz-3.6.0</tt> the default. (You must type this command as <tt>root</tt> or using <tt>sudo</tt>.) If you want to see all your kernels separated on the main menu, as in earlier versions of rEFInd, you should edit <tt>refind.conf</tt>: Uncomment the <tt>fold_linux_kernels</tt> option and set it to <tt>false</tt>, <tt>off</tt>, or <tt>0</tt>.</p>
+
<p class="sidebar"><b>Tip for distribution maintainers:</b> If you maintain an <tt>EFI/<tt class="variable">distname</tt></tt> directory for your kernels, you can place your version of rEFInd in a directory called <tt>EFI/<tt class="variable">distname</tt>/refind</tt>. This will avoid collisions with duplicate rEFInd installations from other distributions.</p>
-<p>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 <tt>refind_linux.conf</tt> 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.)</p>
+<p>On the whole, auto-detecting kernels and passing boot options using <tt>refind_linux.conf</tt> 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 <tt>refind_linux.conf</tt> 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.)</p>
<p>For end users, this method is simpler than maintaining manual configurations in <tt>refind.conf</tt> (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 <tt>refind_linux.conf</tt> in your kernel's directory. You will, however, have to adjust <tt>refind_linux.conf</tt> if you make certain changes, such as if your root directory identifier changes.</p>
<hr/>
-<p>copyright © 2012 by Roderick W. Smith</p>
+<p>copyright © 2012–2015 by Roderick W. Smith</p>
<p>This document is licensed under the terms of the <a href="FDL-1.3.txt">GNU Free Documentation License (FDL), version 1.3.</a></p>