href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 4/19/2012; last Web page update:
-3/9/2014, referencing rEFInd 0.7.8</p>
+12/8/2014, referencing rEFInd 0.8.4</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>
<!-- <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. 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>
+ 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>