+<ul>
+
+<li><b>Ext2fs</b>—This driver originated with rEFIt. It's useful
+ for reading Linux kernels from a separate <tt>/boot</tt> partition, or
+ even from a root (<tt>/</tt>) filesystem, if you use ext2fs on it.
+ Although it's called an "ext2fs" driver, it also works with ext3fs.</li>
+
+<li><b>Ext4fs</b>—Stefan Agner <a
+ href="https://github.com/falstaff84/rEFInd">modified the rEFIt/rEFInd
+ ext2fs driver</a> so that it could handle ext4fs. I'm including this as
+ a separate driver from the ext2fs driver, although the ext4fs version
+ can handle ext2fs and ext3fs, too. Providing both drivers enables
+ easy filesystem separation—for instance, you can use ext2fs on a
+ <tt>/boot</tt> partition and ext4fs on your root (<tt>/</tt>)
+ partition, to have the EFI scan only the former. This driver has some
+ limitations. Most notably, for various reasons it maxes out at 16TiB
+ and won't mount any ext4 filesystem that's larger than this. As of
+ version 0.6.1, this driver supports the <tt>meta_bg</tt> feature, which
+ can also be used on ext2fs and ext3fs. Thus, it can handle some ext2fs
+ and ext3fs partitions that the ext2fs driver can't handle. You can
+ learn about your ext2/3/4 filesystem features by typing <tt
+ class="userinput">dumpe2fs <i>/dev/sda2</i> | grep features</tt>,
+ changing <tt class="userinput"><i>/dev/sda2</i></tt> to your
+ filesystem's device.</li>
+
+<li><b>ReiserFS</b>—This driver originated with rEFIt. It can be used
+ in the same way as the ext2fs and ext4fs drivers. <b>Caution:</b> If you
+ use this driver, you should use the <tt>notail</tt> option in Linux's
+ <tt>/etc/fstab</tt> file for the partition(s) you want the EFI to read.
+ This is because the driver doesn't properly handle ReiserFS's
+ "tail-packing" feature, so files can seem to be corrupted in EFI if you
+ use this feature, which is disabled by <tt>notail</tt>.</li>
+
+<li><b>Btrfs</b>—</b>Samuel Liao contributed this driver, which is
+ based on the rEFIt/rEFInd driver framework and algorithms from the GRUB
+ 2.0 Btrfs driver. I've tested this driver with simple one-partition
+ filesystems on several installations, and with a filesystem that spans
+ two physical devices on one (although I've made no attempt to ensure
+ that the driver can actually read files written to both devices). Samuel
+ Liao has used the driver with a compressed Btrfs volume. The driver will
+ handle subvolumes, but you may need to add kernel options if you're
+ booting a Linux kernel directly from a filesystem that uses subvolumes.
+ For instance, when booting Ubuntu from Btrfs, <tt>also_scan_dirs +
+ @/boot</tt> must be set in <tt>refind.conf</tt> and
+ <tt>rootflags=subvol=@</tt> must be added to the kernel options in
+ <tt>refind_linux.conf</tt>. Without the first of these options, rEFInd
+ can not locate the kernel; and without the second, the boot fails with a
+ message to the effect that the initial RAM disk could not find
+ <tt>/sbin/init</tt>. rEFInd 0.10.0 adds <tt>@/boot</tt> as a standard
+ option to <tt>also_scan_dirs</tt>, and its <tt>refind-install</tt> and
+ <tt>mkrlconf</tt> scripts should pick up the root flags, assuming the
+ system is booted into the regular installation. These additions make it
+ easier to set up rEFInd to work with Btrfs.</li>
+
+<li><b>ISO-9660</b>—This driver originated with rEFIt's author, but
+ he never released a final version. Its code was improved by Oracle for
+ use in its VirtualBox product, and then further modified by the authors
+ of the <a
+ href="https://sourceforge.net/projects/cloverefiboot/">Clover</a> boot
+ loader. If your firmware doesn't provide its own ISO-9660 driver, this
+ one can be helpful; however, you may need to install it on your hard
+ disk before you can read an optical disc.</li>
+
+<li><b>HFS+</b>—Oracle wrote this driver, apparently with some code
+ taken from open source Apple examples. It was then further modified by
+ the Clover authors. I expect this driver to have limited appeal to most
+ rEFInd users. Macs don't need it, since Apple's EFI implementation
+ provides its own HFS+ driver, and HFS+ isn't normally used on
+ UEFI-based PCs. Some CDs are mastered with both ISO-9660 and HFS+, or
+ even with HFS+ alone, and it's conceivable that an HFS+ driver would be
+ useful when accessing such discs. Also, one unusual feature of this
+ driver is that it can read files from within an Apple LVM setup, which
+ Apple's own EFI HFS+ driver can't do. The upshot of this feature is
+ that if you load this driver on a Mac that uses Apple's LVM, rEFInd is
+ likely to show two OS X boot options. Ordinarily this is pointless, but
+ it could be helpful if your Recovery HD volume becomes damaged. I'm
+ providing the driver mainly because it compiled cleanly with no extra
+ work, aside from providing a Makefile entry for it.</li>
+
+<p class="sidebar"><b>Warning:</b> I've received multiple reports of system hangs when using the NTFS driver; however, I've been unable to replicate the problem. (The problem is probably triggered either by interactions with specific EFIs or by unique features of the "problem" NTFS volumes.) I therefore recommend avoiding the NTFS driver unless it's absolutely necessary. I've added a couple of checks to the driver code in rEFInd 0.9.1 that <i>may</i> fix this problem, but these checks may also have no effect.</p>
+
+<li><b>NTFS</b>—Samuel Liao contributed this driver, which uses the
+ rEFIt/rEFInd driver framework. Note that this driver is
+ <i><b>not</b></i> required to boot Windows with rEFInd, since Windows
+ stores its EFI boot loader on the (FAT) ESP, and the BIOS boot process
+ (generally used when dual-booting on a Mac) relies only on the
+ partition's boot sector, which is read without the benefit of this
+ driver. Reasons to use this driver include:
+ <ul>
+ <li>If you want to store large boot files to be read from EFI, such as
+ RAM disk images, from Windows.</li>
+ <li>If you have a Mac and NTFS data partitions, loading this driver
+ should exclude those data partitions from the boot menu.</li>
+ <li>If you have a Mac that dual-boots with Windows, using this driver
+ should provide NTFS volume names in the boot menu.</li>
+ </ul>
+ </li>
+
+</ul>
+
+<p>All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.</p>
+
+<p class="sidebar"><b>Note:</b> rEFInd's <tt>refind-install</tt> script, when run from Linux, installs the driver required to read the <tt>/boot</tt> directory. Under OS X, the <tt>refind-install</tt> script installs the ext4fs driver if the script detects a Linux partition—but you might need to change this driver if you use another filesystem. The script installs all the available drivers if you pass it the <tt>--alldrivers</tt> option. (I do <i>not</i> recommend using this feature except for creating general-purpose USB flash drives with rEFInd, since having too many drivers can cause various problems.) See the <a href="installing.html">Installing rEFInd</a> page for details.</p>
+
+<p>If you want to use one or more of these drivers, you can install them from the rEFInd binary package from the <tt>refind/drivers_<tt class="variable">arch</tt></tt> directory, where <tt class="variable">arch</tt> is a CPU architecture code—<tt>x64</tt> or <tt>ia32</tt>. The files are named after the filesystems they handle, such as <tt>ext4_x64.efi</tt> for the 64-bit ext4fs driver. You should copy the files for the filesystems you want to use to the <tt>drivers</tt> or <tt>drivers_<tt class="variable">arch</tt></tt> subdirectory of the main rEFInd installation directory. (You may need to create this subdirectory.) Be careful to install drivers only for your own architecture. Attempting to load drivers for the wrong CPU type will cause a small delay at best, or may cause the computer to crash at worst. I've placed rEFInd's drivers in directories that are named to minimize this risk, but you should exercise care when copying driver files.</p>
+
+<p class="sidebar"><b>Warning:</b> <i>Do not</i> place EFI program files in your driver directories! Unfortunately, EFI uses the same <tt>.efi</tt> filename extension to identify both EFI program files and EFI drivers. Therefore, rEFInd can't distinguish between the two prior to loading them, and if you place program files in a drivers directory, rEFInd will run the EFI program file when it does its driver scan.</p>
+
+<p>When you reboot after installing drivers, rEFInd should automatically detect and use the drivers you install. There's likely to be an extra delay, typically from one to five seconds, as rEFInd loads the drivers and tells the EFI to detect the filesystems they handle. For this reason, and because of the possibility of drivers harboring bugs, I recommend installing only those drivers that you need. If you like, you can install drivers you don't plan on using to some other directory, such as <tt>/drivers</tt> on the ESP's root. You can then load these drivers manually with the EFI shell's <tt>load</tt> command if the need arises in the future. You can then tell the shell to re-assign drive identifiers with <tt>map -r</tt>:</p>
+
+<pre class="listing">
+fs0: <tt class="userinput">load btrfs_x64.efi</tt>
+fs0: <tt class="userinput">map -r</tt>
+</pre>
+
+<a name="finding">
+<h2>Finding Additional EFI Drivers</h2>
+</a>
+
+<p>As already noted, I know of no EFI drivers for EFI hardware, aside from those that are built into motherboards' EFI implementations. I do, however, know of a few EFI filesystem drivers, in addition to those provided with rEFInd:</p>