href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 4/19/2012; last Web page update:
-6/27/2013, referencing rEFInd 0.7.0</p>
+7/28/2014, referencing rEFInd 0.8.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>
+<p>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>
<table border="1">
<tr>
<!-- <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 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 EFI System Partition (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>
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
+ 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>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. As of rEFInd 0.7.0, this driver is new and should be
- considered experimental. I've tested this driver with a simple
- one-partition filesystem and with a filesystem that spans two physical
- devices (although I've made no attempt to ensure that the driver can
- actually read files written to both devices). Lamuel Liao has used the
- driver with a compressed Btrfs volume. I don't know if the driver will
- handle other advanced Btrfs features, such as snapshots and
- subvolumes.</li>
+ 2.0 Btrfs driver. I've tested this driver with a simple one-partition
+ filesystem and with a filesystem that spans two physical devices
+ (although I've made no attempt to ensure that the driver can actually
+ read files written to both devices). Lamuel 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, on a
+ test installation of Ubuntu 14.04 alpha on such a system, I needed to
+ set <tt>also_scan_dirs + @/boot</tt> in <tt>refind.conf</tt> and add
+ <tt>rootflags=subvol=@</tt> to the kernel options in my
+ <tt>refind_linux.conf</tt> file. Without the first of these options,
+ rEFInd could not locate my kernel; and without the second, the boot
+ failed with a message to the effect that the initial RAM disk could not
+ find <tt>/sbin/init</tt>.</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
<ul>
+<li><b><a href="https://github.com/pbatard/efifs">Pete Batard's efifs drivers</a></b>—This project is an EFI driver wrapper around GRUB 2's filesystem drivers. Once compiled, the result is that GRUB 2's drivers become standalone EFI filesystem drivers, loadable independently or by rEFInd. (rEFInd version 0.8.3 or later is required.) At present (early July, 2014), several drivers, including NTFS, exFAT, JFS, and XFS, are usable, albeit with some caveats. For instance, using a <tt>root=UUID={uuid-value}</tt> specification to tell a Linux kernel about its root partition doesn't work, although <tt>root=PARTUUID={guid=value}</tt> does work, as does <tt>root=/dev/sd{xy}</tt>. I have no doubt that these drivers will improve rapidly in usability in the near future.</li>
+
<li><b><a href="http://refit.sourceforge.net">rEFIt's ext2fs and ReiserFS drivers</a></b>—You can gain read-only access to ext2fs, ext3fs, and ReiserFS volumes with these drivers, originally written by Christoph Pfisterer. You can use the binaries in the <tt>refit-bin-0.14/efi/tools/drivers</tt> directory of the binary package directly on a Mac. On a UEFI-based PC, though, you'll need to break the Mac-style "fat" binary into its 32- and 64-bit components. You can use my <a href="http://www.rodsbooks.com/thin/index.html"><tt>thin</tt></a> program for this job. As a practical matter, there's no advantage to using these drivers over rEFInd's drivers, since the latter are updated versions of the former.</li>
<li><b><a href="https://sourceforge.net/projects/cloverefiboot/">Clover EFI's ISO-9660, ext2fs, ext4fs, and HFS+ drivers</a></b>—This project is an offshoot of TianoCore, the main UEFI project. It's primarily a Hackintosh boot loader, but it includes drivers for <a href="http://cloverefiboot.svn.sourceforge.net/viewvc/cloverefiboot/VBoxFsDxe/">ISO-9660, ext2fs, ext4fs, and HFS+;</a> however, building them requires a fair amount of expertise. These drivers served as a starting point for rEFInd's drivers, except for the ext4fs driver, which the Clover developers based on rEFInd's ext4fs driver. Thus, as with the rEFIt drivers, there's likely to be no advantage to using the Clover drivers over the rEFInd drivers.</li>
<li><b>Ext2Pkg</b>—This driver, based on <a href="https://bitbucket.org/alinrus/ext2pkg">bitbucket</a> and with a backup on <a href="https://github.com/the-ridikulus-rat/Tianocore_Ext2Pkg">github,</a> appears to be an ext2fs/ext3fs driver built independently of the driver written by Christoph Pfisterer. The linked-to sites provide access to source code via <tt>git</tt> but do not provide binaries. When I built binaries, they failed to work. Under VirtualBox, the driver loaded but then hung when I tried to access an ext2 filesystem. On a 32-bit Mac Mini, I got error messages when I tried to access an ext2 filesystem. As I write, the code was last updated in March of 2012. If you check the project and it's been updated more recently, it might be worth trying. Otherwise, I can't recommend this driver. I mention it here only in case it improves in the future.</li>
+<li><b>Paragon's UFSD</b>—According to <a href="http://blog.paragon-software.com/?p=2951">this blog post,</a> Paragon Software has ported its <a href="http://www.paragon-software.com/technologies/ufsd.html">Universal File System Drivers (UFSD)</a> to EFI, providing "transparent access to NTFS, HFS+, ExFAT, and ExtFS" (sic). The entry doesn't provide any download links, and it's unclear if the product is (or will be) available for free or on a pay basis. I haven't tried these drivers, so I can't comment on their quality.</li>
+
</ul>
<p>Most of these cross-project drivers appear to be related, and most of them have fed into rEFInd's drivers. I used the Clover package, which in turn was based on the VirtualBox drivers, as a starting point. Everybody else has dropped rEFIt's original ReiserFS driver, but I added that back. Of these drivers, only the Clover EFI Tools NTFS driver is missing from rEFInd. Specific versions can have their own quirks, though. For instance, the Clover (and I suspect VirtualBox) drivers don't return volume labels, which causes rEFInd to display loaders on those volumes as being on a disk called <tt>Unknown</tt>. (I fixed that bug for rEFInd's version, and it wasn't present in the original rEFIt drivers.) Most of these drivers also suffer from speed problems on some computers. This is worst with the ext2fs drivers under VirtualBox; on my main computer, that combination takes 3 minutes to load a Linux kernel and initial RAM disk file! Most real computers don't suffer nearly so badly, but some can take an extra five seconds or so to boot a kernel. I've fixed the speed problems in rEFInd's drivers as of version 0.7.0.</p>
<hr />
-<p>copyright © 2012–2013 by Roderick W. Smith</p>
+<p>copyright © 2012–2014 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>