+<p>Once this task is done, updates to your kernel will automatically be stored in the root directory of your ESP, where rEFInd will automatically detect them. Thus, the boot configuration becomes maintenance-free. The procedure as just described has some drawbacks, though. By placing your kernels in the root directory of your ESP, you render them vulnerable to any other OS with which you might be dual-booting. Your ESP must also be large enough to hold all your kernels. If you dual-boot with multiple Linux distributions, they might conceivably overwrite each others' kernels, and distinguishing one from another becomes more difficult.</p>
+
+<p>For these reasons, a variant of this procedure is desirable on some systems. Most of the steps are similar, but in this variant, you create a separate <tt>/boot</tt> partition that's independent of the ESP. This partition can use FAT, HFS+, ReiserFS, ext2fs, ext3fs, ext4fs, or Btrfs; but if you use any of the last six filesystems (five on Macs), you must install the matching EFI filesystem driver that ships with rEFInd. Creating the filesystem will normally require you to shrink an existing partition by a suitable amount (200–500MiB). Mount your new <tt>/boot</tt> partition at a temporary location, copy or move the current <tt>/boot</tt> files into it, unmount it, and add it to <tt>/etc/fstab</tt> as <tt>/boot</tt>.</p>
+
+<p>If your distribution already uses a separate <tt>/boot</tt> partition, but if it uses XFS or some other unsuitable filesystem, you can back it up, create a fresh FAT, HFS+, ReiserFS, Btrfs, ext2, ext3, or ext4 filesystem on it, and restore the original files. You'll probably need to adjust the UUID value in <tt>/etc/fstab</tt> to ensure that the computer mounts the new filesystem when you boot. If you use a separate non-ESP <tt>/boot</tt> partition, you'll probably want to continue mounting the ESP at <tt>/boot/efi</tt>.</p>
+
+<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 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>
+
+<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
+ 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>
+
+<li>rEFInd looks for a file called <tt>refind_linux.conf</tt> in the same
+ 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
+ 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>
+
+<li>If rEFInd can't find a <tt>refind_linux.conf</tt> file in the directory
+ that holds the kernel, the program looks for a file called
+ <tt>/etc/fstab</tt> on the partition that holds the kernel. If this
+ standard Linux file is present, rEFInd uses it to identify the root
+ (<tt>/</tt>) filesystem and creates two sets of Linux kernel boot
+ options: One set launches the kernel normally, but with minimal
+ options, and the other set launches the kernel into single-user mode.
+ This step can get a computer to boot without any rEFInd-specific
+ configuration files, aside from <tt>refind.conf</tt> in rEFInd's own
+ directory, but only if <tt>/boot</tt> is not a separate partition. The
+ intent is to facilitate the use of rEFInd as an emergency boot manager
+ or to help users who must install rEFInd from OS X or Windows. Note
+ that rEFInd uses <tt>/etc/fstab</tt> only if <tt>refind_linux.conf</tt>
+ is <i>not</i> found.</li>