href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 4/19/2012; last Web page update:
-12/11/2012, referencing rEFInd 0.5.1</p>
+1/6/2013, referencing rEFInd 0.6.3</p>
<p>I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!</p>
<hr />
+<div style="float:right; width:55%">
+
<p>Beginning with version 0.2.7, rEFInd has been able to load EFI drivers, and as of version 0.4.0, it has shipped with some EFI filesystem drivers. Although EFI implementations should be able to load drivers prior to rEFInd's launch, in my experience, most EFI implementations offer such poor control over EFI driver loading that they can't be counted on to do this. Thus, if you want to use EFI drivers, rEFInd's ability to do so can be useful. This page tells you why you might want to use drivers, how you can install and use rEFInd's own drivers, where you can go to find other drivers, and provides tips on a few specific drivers.</p>
+</div>
+
+<div class="navbar">
+
+<h4 class="tight">Contents</h4>
+
+<ul>
+
+<li class="tight"><a href="#why">Why Should You Use Drivers?</li>
+
+<li class="tight"><a href="#using">Using rEFInd's EFI Drivers</a></li>
+
+<li class="tight"><a href="#finding">Finding Additional Drivers</a></li>
+
+<li class="tight"><a href="#notes">Notes on Specific Drivers</a></li>
+
+</ul>
+
+</div>
+
+<br/>
+<a name="why">
<h2>Why Should You Use EFI Drivers?</h2>
+</a>
<p>EFI supports drivers, which can activate hardware or filesystems in the pre-boot environment. At the moment, EFI drivers are few and far between; but you can or might want to use them for various reasons:</p>
<ul>
+<!-- <p class="sidebar"><b>Tip:</b> Some Linux installation media come as <i>hybrid ISO</i> files, which can be written to either optical discs or USB flash drives for installation. Some of these media, though, are useless for installing to EFI systems from USB flash drives—unless your computer supports ISO-9660 on non-optical media. rEFInd's ISO-9660 driver provides this support. To use such a hybrid image from USB flash drive, you must boot using rEFInd on another disk that has the ISO-9660 driver installed. rEFInd should then provide an option to boot from the USB flash drive. I cannot guarantee that the installer will boot at this point, but it might.</p> -->
+
<li>You can load a filesystem driver to gain access to files on a filesystem other than FAT (or HFS+ on Macs or ISO-9660 on some systems). This is most likely to be useful on a Linux installation, since a filesystem driver can enable you to store a Linux kernel with EFI stub loader or for use by ELILO on a Linux-native filesystem if your ESP is getting crowded.</li>
<li>You can load a driver for a plug-in disk controller to give the EFI access to its disks. Note that this is <i>not</i> required if you place your boot loader (and perhaps your OS kernel) on another disk, or if the plug-in disk controller includes EFI-capable firmware. It could be handy, perhaps in conjunction with a filesystem driver, to enable the EFI to read a boot loader or kernel from a disk on a plug-in controller, though.</li>
<p>As a side note, using an ISO-9660 driver can theoretically help you keep the size of a custom Linux boot CD/DVD down to a reasonable value. This is because EFI systems normally boot from optical discs by reading a FAT image file in El Torito format and treating that file as an ESP. If you need to store the kernel both in that file and directly in the ISO-9660 filesystem (to maintain bootability on BIOS systems), that can represent an unwanted extra space requirement. Placing rEFInd and an ISO-9660 driver in the FAT image file should enable you to store the kernel on the disc only once. Unfortunately, this doesn't work in practice. When the ISO-9660 driver is loaded from the El Torito image, the driver discovers that the optical disc is in use and refuses to access it. It's possible to use EFI shell commands to give the ISO-9660 driver access to the shell device, but this causes the El Torito access to go away, which means that anything loaded from the El Torito image (such as rEFInd) is likely to malfunction. Also, some EFI implementations include ISO-9660 drivers, so you might not need a separate ISO-9660 driver if you're building a disc for a particular computer.</p>
+<a name="using">
<h2>Using rEFInd's EFI Drivers</h2>
+</a>
<p class="sidebar"><b>Note:</b> If you want to use the drivers with a Mac, be sure to use at least version 0.4.3. Earlier versions were incompatible with the Mac's EFI 1.x firmware. Alternatively, you can use the drivers that came with <a href="http://refit.sourceforge.net">rEFIt,</a> which work on Macs.</p>
used in the same way as the ReiserFS driver. Although it's called an
"ext2fs" driver, it also works with ext3fs.</li>
-<li><b>Ext4fs</b>—Stefan Agner modified the rEFIt/rEFInd ext2fs
- driver so that it could handle ext4fs. I'm including this as a separate
- driver from the ext2fs driver, although the ext4fs version seems to be
- able to handle ext2fs and ext3fs, too.</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. (I may eventually retire the
+ original ext2fs driver, but I want to be conservative about this in
+ case there's an undiscovered problem with the new driver.) 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>ISO-9660</b>—This driver originated with rEFIt's author, but
he never released a final version. Its code was improved by Oracle for
<p>All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer. They all suffer from speed problems on some systems, as described later in <a href="#notes">"Notes on Specific Drivers;"</a> however, these problems are very minor on most systems.</p>
-<p class="sidebar"><b>Note:</b> rEFInd's <tt>install.sh</tt> script does not install drivers by default
. It does if you pass it the <tt>--drivers</tt> option, though. If you installed manually, you may also have installed rEFInd's drivers. See the <a href="installing.html">Installing rEFInd</a> page for details.</p>
+<p class="sidebar"><b>Note:</b> rEFInd's <tt>install.sh</tt> script does not install drivers by default
on OS X, but on Linux, it installs the driver required to read the <tt>/boot</tt> directory, if one is available. The script installs all the available drivers if you pass it the <tt>--drivers</tt> option. 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>ext2_x64.efi</tt> for the 64-bit ext2fs 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>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>
fs0: <tt class="userinput">map -r</tt>
</pre>
-<p>If you build rEFInd from source, you should be aware that the drivers rely on <a href="https://sourceforge.net/projects/tianocore/">TianoCore's development kit,</a> whereas rEFInd itself can use either TianoCore's kit or <a href="http://sourceforge.net/projects/gnu-efi/">GNU-EFI.</a> Thus, to compile both, you'll need to install TianoCore, with GNU-EFI being optional but providing no additional benefits. Unfortunately, the TianoCore kit is a bit unusual from a Linux developer's perspective, and you'll probably have to build it from source code. Consult the <tt>BUILDING.txt</tt> file in the source package for more information. None of this is important if you use a binary build of rEFInd, unless you've obtained it from a third party who hasn't built the drivers. If that's the case, you'll have to download rEFInd from Sourceforge (see the <a href="http://www.rodsbooks.com/refind/getting.html">Getting rEFInd page</a> for details) or use drivers from another source.</p>
-
+<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>
<h2>Notes on Specific Drivers</h2>
</a>
-<p>I've tested several of the drivers described on this page on a handful of systems. The Pfisterer ext2fs driver (from any source) works on both ext2fs and ext3fs, but not on ext4fs—but Agner's derivative ext4fs driver handles ext4fs, so that's not a problem. The ReiserFS driver is obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as far as I know.) Given that ext2fs, ext3fs, and ReiserFS are getting a bit on in age by Linux standards, you might do well to use them on a separate Linux <tt>/boot</tt> partition; however, if you're willing to use ext3fs or ReiserFS on your root (<tt>/</tt>) filesystem, you can use the EFI drivers to read your kernel from it. If you use ext4fs on your root (<tt>/</tt>) filesystem, you can use the ext4fs driver rather than a separate <tt>/boot</tt> partition. Note that this assumes you use conventional partitions; to the best of my knowledge, there's no EFI driver for Linux's Logical Volume Manager (LVM) or Redundant Array of Independent Disks (RAID) configurations, so the EFI can't access filesystems stored in these ways.</p>
+<p>I've tested several of the drivers described on this page on a handful of systems. The Pfisterer ext2fs driver (from any source) works on both ext2fs and ext3fs, but not on ext4fs—but Agner's derivative ext4fs driver handles ext4fs, so that's not a problem. The ReiserFS driver is obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as far as I know.) Given that ext2fs, ext3fs, and ReiserFS are getting a bit on in age by Linux standards, you might do well to use them on a separate Linux <tt>/boot</tt> partition; however, if you're willing to use ext3fs, ext4fs, or ReiserFS on your root (<tt>/</tt>) filesystem, you can use the EFI drivers to read your kernel from it. Note that this assumes you use conventional partitions; to the best of my knowledge, there's no EFI driver for Linux's Logical Volume Manager (LVM) or Redundant Array of Independent Disks (RAID) configurations, so the EFI can't access filesystems stored in these ways.</p>
<p>The Pfisterer ReiserFS and ext2fs drivers work, but they are a bit sluggish—particularly the ext2fs driver. The Agner ext4fs driver, when handling an actual ext4 filesystem, is in-between these two drivers in speed. The extent of the problem depends on the computer. In my tests so far, VirtualBox has fared the worst. On it, loading a Linux kernel with EFI stub loader from a FAT partition takes 2 seconds, from the moment of selecting the OS in rEFInd to the moment the kernel messages begin to appear. The equivalent time using ReiserFS or HFS+ is 20 seconds, with ext4fs it's 75 seconds, and with ext2fs it's 200 seconds (that is, 3 minutes and 20 seconds). On a 32-bit Mac Mini, though, the speed problem is much less pronounced—my kernel loads in just 3 seconds from a ReiserFS partition and in 13 seconds from an ext2 filesystem. Speeds were similar with my newest computer, an ASUS P8H77-I board. Times with ext2fs on a UEFI PC with an Intel motherboard are in the 2–4 second range. If you try the ext2fs driver and it seems to hang, be patient; it may finally boot up. If so, and if the delay is too great for you to accept, you might consider using ext4fs or ReiserFS instead of ext2fs or ext3fs, at least if a change is practical. (For a <tt>/boot</tt> partition, it almost certainly is practical; you can back it up quite easily, create a fresh filesystem on it, and restore it. You may need to adjust your <tt>/etc/fstab</tt> entry for a new UUID value, though. As noted earlier, be sure to use <tt>notail</tt> as an option in <tt>/etc/fstab</tt> for ReiserFS if you want to read it from EFI.) You can even use HFS+ on a Linux <tt>/boot</tt> partition, although this makes the most sense on a Mac, which has its own EFI HFS+ driver. Of course, you can also create a FAT <tt>/boot</tt> partition and not deal with drivers at all. Mounting your ESP at <tt>/boot</tt> is a practical solution for many users.</p>
<hr />
-<p>copyright © 2012 by Roderick W. Smith</p>
+<p>copyright © 2012–2013 by Roderick W. Smith</p>
<p>This document is licensed under the terms of the <a href="FDL-1.3.txt">GNU Free Documentation License (FDL), version 1.3.</a></p>