+<a name="efistub">
+<h2>EFI Stub Loader Support Technical Details</h2>
+</a>
+
+<p>The Linux <a href="http://www.rodsbooks.com/efi-bootloaders/efistub.html">EFI stub loader</a> is a way to turn a Linux kernel into an EFI application. In a sense, the kernel becomes its own boot loader. This approach to booting Linux is very elegant in some ways, but as described on the page to which I just linked, it has its disadvantages, too. One challenge to booting in this way is that modern Linux installations typically require that the kernel be passed a number of options at boot time. These tell the kernel where the Linux root (<tt>/</tt>) filesystem is, where the initial RAM disk is, and so on. Without these options, Linux won't boot. These options are impossible for a generic boot loader to guess without a little help. It's possible to build a kernel with a default set of options, but this is rather limiting. Thus, rEFInd provides configuration options to help.</p>
+
+<p>With all versions of rEFInd, you can create manual boot loader stanzas
+in the <tt>refind.conf</tt> file to identify a Linux kernel and to pass it
+all the options it needs. This approach is effective and flexible, but it
+requires editing a single configuration file for all the OSes you want to
+define in this way. If a computer boots two different Linux distributions,
+and if both were to support rEFInd, problems might arise as each one tries
+to modify its own rEFInd configuration; or the one that controls rEFInd
+might set inappropriate options for another distribution. This is a problem
+that's been a minor annoyance for years under BIOS, since the same
+potential for poor configuration applies to LILO, GRUB Legacy, and GRUB 2
+on BIOS. The most reliable solution under BIOS is to chainload one boot
+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>
+
+<ol>
+
+<li>rEFInd looks for boot loaders whose names include the strings
+ <tt>bzImage</tt> or <tt>vmlinuz</tt> and that end in <tt>.efi</tt>. For
+ instance, <tt>bzImage-3.3.0.efi</tt> or <tt>vmlinuz-3.3.0-fc17.efi</tt>
+ would match, and trigger subsequent steps in this procedure. Beginning
+ with version 0.3.0, if you uncomment the
+ <tt>scan_all_linux_kernels</tt> option in <tt>refind.conf</tt>, rEFInd
+ will also scan for kernels <i>without</i> a <tt>.efi</tt> filename
+ extension. This option is uncommented by default, but if you comment it
+ out, delete it, or change it to read <tt>scan_all_linux_kernels 0</tt>,
+ rEFInd won't scan for kernels that lack <tt>.efi</tt> filename
+ extensions.</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
+ kernel file. A matching initial RAM disk has a name that begins with
+ <tt>init</tt> and that includes the same version string as the kernel.
+ The version string is defined as the part of the filename from the
+ first digit to the last digit, inclusive. Note that the version string
+ can include non-digits. For instance, the version string for
+ <tt>bzImage-3.3.0.efi</tt> is <tt>3.3.0</tt>, which matches
+ <tt>initramfs-3.3.0.bz</tt>; and <tt>vmlinuz-3.3.0-fc17.efi</tt>'s
+ version string is <tt>3.3.0-fc17</tt>, which matches
+ <tt>initrd-3.3.0-fc17.img</tt>. Many other matches are possible. If an
+ 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,
+ 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
+ you installed rEFInd 0.5.1 or later with the <tt>install.sh</tt>
+ script, that script created a sample <tt>refind_linux.conf</tt> file,
+ customized for your computer, in <tt>/boot</tt>. This file will work
+ without changes on many installations, but you may need to tweak it for
+ some.</li>