+<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>