+<a name="quickstart">
+<h2>Using the EFI Stub Loader: Three Configuration Options</h2>
+</a>
+
+<p>The EFI stub loader is basic and reliable, but it requires some setup to use it on some computers. It also requires that you run a kernel with the same bit width as your EFI. In most cases, this means running a 64-bit kernel, since 32-bit EFI-based computers are so rare. I describe three methods of using the EFI stub loader: an <a href="#easiest">easiest method</a> for those with compatible partition and filesystem layouts, a <a href="#testing">quick test configuration</a> for those without such a layout, and <a href="#longterm">a long-term setup</a> for those without the ideal setup.</p>
+
+<a name="easiest">
+<h3>For Those With Foresight or Luck: The Easiest Method</h3>
+</a>
+
+<p>This method requires that your <tt>/boot</tt> directory, whether it's on a separate partition or is a regular directory in your root (<tt>/</tt>) filesystem, be readable by the EFI. At the moment, all EFI implementations can read FAT and Macs can read HFS+. By using <a href="drivers.html">drivers,</a> 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 <tt>/boot</tt>, 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 <tt>/boot</tt> partition. You must also have a 3.3.0 or later Linux kernel with EFI stub support, of course.</p>
+
+<p>If you installed rEFInd 0.6.0 or later with its <tt>install.sh</tt> 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:
+
+<ul>
+
+<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>
+
+<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
+ should do this job, or you can do it manually as described <a
+ 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>
+
+</ul>
+
+<p>When you reboot, you should see rEFInd options for your Linux kernels. If they work, your job is done, although you might want to apply some of the tweaks described in the <a href="#longterm">maintenance-free setup</a> section. If you have problems, you may need to adjust the <tt>refind_linux.conf</tt> file, as described in the <a href="#efistub">detailed configuration section.</a></p>
+
+<a name="testing">
+<h3>Preparing a Test Configuration</h3>
+</a>
+
+<p>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:</p>
+
+<ol>
+
+<li>Copy your kernel file (<tt>vmlinuz-*</tt>) and matching initial RAM
+ disk file (<tt>init*</tt>) from <tt>/boot</tt> to a subdirectory of
+ <tt>EFI</tt> on your ESP. Your distribution's directory there should
+ work fine. For instance, typing <tt class="userinput">cp
+ /boot/vmlinuz-3.6.7-4.fc17.x86_64
+ /boot/initramfs-3.6.7-4.fc17.x86_64.img /boot/efi/EFI/redhat</tt> might
+ do the trick on a Fedora system, although you'll probably have to
+ adjust the version numbers. Note that the filename forms vary from one
+ distribution to another, so don't worry if yours look different from
+ these. Be sure that you match up the correct files by version number,
+ though.</li>
+
+<li>Copy the <tt>/boot/refind_linux.conf</tt> file to the same directory to
+ which you copied your kernel. If this file doesn't exist, create it by
+ running (as <tt>root</tt>) the <tt>mkrlconf.sh</tt> script that came
+ with rEFInd. This step may not be strictly necessary if <tt>/boot</tt>
+ is an ordinary directory on your root (<tt>/</tt>) partition.</li>
+
+<li>Reboot. You should now see a new entry for launching the Linux kernel
+ that you copied. Try the option. If it works, great. If not, you may
+ need to adjust your <tt>refind_linux.conf</tt> file. See the <a
+ href="#efistub">detailed configuration section</a> for a description of
+ this file's format. If the kernel begins to boot but complains that it
+ couldn't find its root filesystem, double-check the version numbers on
+ your kernel and initial RAM disk file, and check the <tt>root=</tt>
+ option in <tt>refind_linux.conf</tt>.</li>
+
+</ol>
+
+<p>You can continue to boot your computer with this type of configuration; however, the drawback is that you'll need to copy your kernel whenever it's updated. This can be a hassle. A better way is to configure you system so that the EFI, and therefore rEFInd, can read your Linux <tt>/boot</tt> directory, where most Linux distributions place their kernels.</p>
+
+<a name="reconfigure">
+<h3>If You Need to Reconfigure Your Partitions....</h3>
+</a>
+
+<p>If your <tt>/boot</tt> directory happens to be on an XFS or JFS partition that the EFI can't read, or it's tucked away in an LVM or RAID configuration that the EFI can't read, you won't be able to use the <a href="#easiest">easiest solution.</a> Fortunately, this problem can be overcome with relatively little fuss. Several variant procedures are possible, but I begin by describing one that will almost always work, although it's got some important caveats (described at the end). You should perform the following steps as <tt>root</tt>, or precede each of these commands with <tt>sudo</tt>:</p>
+
+<ol>
+
+<li>Begin with your ESP mounted at <tt>/boot/efi</tt>, which is the most
+ common location. If it's not mounted there, type <tt
+ class="userinput">mount /dev/sda1 /boot/efi</tt> to do so (adjusting
+ <tt>/dev/sda1</tt>, if necessary), or mount it elsewhere and adjust the
+ paths in the following procedure as necessary.</li>
+
+<li>Check the size of the ESP by typing <tt class="userinput">df -h
+ /boot/efi</tt>. The ESP must be large enough to hold several Linux
+ kernels and initial RAM disk files—100MiB at a bare minimum, and
+ preferably 200–500MiB.</li>
+
+<li>Check your <tt>/boot</tt> directory to be sure it contains no links or
+ other files that rely on Unix/Linux-style permissions or ownership. If
+ it does, don't proceed, or at least research these files further to
+ determine if you can work around the need for such permissions and
+ ownership.</li>
+
+<li>Type <tt class="userinput">cp -r /boot/* /boot/efi</tt>. You'll see an
+ error message about being unable to copy <tt>/boot/efi</tt> into
+ itself. Ignore this.</li>
+
+<li>Type <tt class="userinput">umount /boot/efi</tt>.</li>
+
+<li>Edit <tt>/etc/fstab</tt> and change the mount point for
+ <tt>/boot/efi</tt> to <tt>/boot</tt>. If the ESP isn't present in
+ <tt>/etc/fstab</tt>, you must create an entry for it, with a mount
+ point of <tt>/boot</tt>.</li>
+
+<li>Type <tt class="userinput">mount -a</tt> to re-mount everything,
+ including <tt>/boot</tt>. Check that your normal <tt>/boot</tt> files
+ are all present, along with the new <tt>/boot/EFI</tt> directory, which
+ holds what used to be <tt>/boot/efi/EFI</tt>. If something seems to be
+ missing (other than <tt>/boot/efi</tt> with a lowercase <tt>efi</tt>),
+ then you should try to correct the problem.</li>
+
+<li>If it doesn't already exist, create a file called
+ <tt>/boot/refind_linux.conf</tt> and populate it with kernel options,
+ as described <a href="#refind_linux">later.</a> If this file doesn't
+ already exist, the easiest way to create it is to run the
+ <tt>mkrlconf.sh</tt> script that comes with rEFInd 0.5.1 and
+ later.</li>
+
+<li>Check your <tt>refind.conf</tt> file (presumably in
+ <tt>/boot/EFI/refind</tt>) to be sure that the
+ <tt>scan_all_linux_kernels</tt> line is uncommented. If it's not,
+ uncomment that line.</li>
+
+<li>Optionally, type <tt class="userinput">cp
+ /boot/EFI/refind/icons/os_<i>name</i>.icns /boot/.VolumeIcon.icns</tt>
+ to give loaders in <tt>/boot</tt> an icon for your distribution.</li>
+
+<li>Reboot to test that this configuration works.</li>
+
+</ol>
+
+<p>Recall that in step #4, you <i>copied</i> the contents of <tt>/boot</tt> (as a safety measure), but you did not move them. Therefore, you ended up with two copies of your kernels and other <tt>/boot</tt> directory contents, with one copy hiding the other when you mounted the ESP at <tt>/boot</tt>. Once you've booted successfully and are sure all is working well, you can recover some disk space by unmounting <tt>/boot</tt> and deleting the contents of the underlying <tt>/boot</tt> directory on your root (<tt>/</tt>) filesystem. Be sure that the <tt>/boot</tt> partition is unmounted before you do this, though! Also, be sure to leave the <tt>/boot</tt> directory itself in place, even if it has no contents; the directory is needed as a mount point for the <tt>/boot</tt> partition. Note that GRUB 2 may stop working if you delete its files from the root filesystem's <tt>/boot/grub</tt> directory, so if you want to keep GRUB around, you should re-install it with the separate <tt>/boot</tt> partition mounted.</p>
+
+<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>