Originally written: 4/19/2012; last Web page update:
-5/15/2014, referencing rEFInd 0.8.1
+4/24/2016, referencing rEFInd 0.10.3
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!
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.
+
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.
You can load a driver for a plug-in disk controller to give the EFI access to its disks. Note that this is not 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.
ReiserFS—This driver originated with rEFIt. It's useful
+
Ext2fs—This driver originated with rEFIt. It's useful
for reading Linux kernels from a separate /boot partition, or
- even from a root (/) filesystem, if you use ReiserFS on it.
- Caution: If you use this driver, you should use the
- notail option in Linux's /etc/fstab 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 notail.
-
-
Ext2fs—This driver also originated with rEFIt. It can be
- used in the same way as the ReiserFS driver. Although it's called an
- "ext2fs" driver, it also works with ext3fs.
+ even from a root (/) filesystem, if you use ext2fs on it.
+ Although it's called an "ext2fs" driver, it also works with ext3fs.
ReiserFS—This driver originated with rEFIt. It can be used
+ in the same way as the ext2fs and ext4fs drivers. Caution: If you
+ use this driver, you should use the notail option in Linux's
+ /etc/fstab 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 notail.
+
Btrfs—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 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 also_scan_dirs + @/boot in refind.conf and add
- rootflags=subvol=@ to the kernel options in my
- refind_linux.conf 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 /sbin/init.
+ 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, also_scan_dirs +
+ @/boot must be set in refind.conf and
+ rootflags=subvol=@ must be added to the kernel options in
+ refind_linux.conf. 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
+ /sbin/init. rEFInd 0.10.0 adds @/boot as a standard
+ option to also_scan_dirs, and its refind-install and
+ mkrlconf 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.
ISO-9660—This driver originated with rEFIt's author, but
he never released a final version. Its code was improved by Oracle for
@@ -247,22 +246,46 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
one can be helpful; however, you may need to install it on your hard
disk before you can read an optical disc.
-
HFS+—Oracle seems to have written 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. I'm providing the driver
- mainly because it compiled cleanly with no extra work, aside from
- providing a Makefile entry for it.
+
HFS+—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.
+
+
Warning: 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 may fix this problem, but these checks may also have no effect.
+
+
NTFS—Samuel Liao contributed this driver, which uses the
+ rEFIt/rEFInd driver framework. Note that this driver is
+ not 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:
+
+
If you want to store large boot files to be read from EFI, such as
+ RAM disk images, from Windows.
+
If you have a Mac and NTFS data partitions, loading this driver
+ should exclude those data partitions from the boot menu.
+
If you have a Mac that dual-boots with Windows, using this driver
+ should provide NTFS volume names in the boot menu.
+
+
All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.
-
Note: rEFInd's install.sh script does not install drivers by default on OS X, but on Linux, it installs the driver required to read the /boot directory, if one is available. The script installs all the available drivers if you pass it the --drivers option. See the Installing rEFInd page for details.
+
Note: rEFInd's refind-install script, when run from Linux, installs the driver required to read the /boot directory. Under OS X, the refind-install 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 --alldrivers option. (I do not 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 Installing rEFInd page for details.
If you want to use one or more of these drivers, you can install them from the rEFInd binary package from the refind/drivers_arch directory, where arch is a CPU architecture code—x64 or ia32. The files are named after the filesystems they handle, such as ext4_x64.efi for the 64-bit ext4fs driver. You should copy the files for the filesystems you want to use to the drivers or drivers_arch 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.
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 /drivers on the ESP's root. You can then load these drivers manually with the EFI shell's load command if the need arises in the future. You can then tell the shell to re-assign drive identifiers with map -r:
Pete Batard's efifs drivers—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 (driver version 0.7; January 2015), several drivers, including NTFS, exFAT, ext2fs, ReiserFS, Btrfs, JFS, and XFS, are usable, albeit with some caveats. Some drivers are slow, and they hang on some computers, such as one of my Macs. I have no doubt that these drivers will improve rapidly in usability in the near future. Note that the ext2fs driver from this set works with ext3fs and ext4fs, too. In addition to the main link, you can check the github repository for the source code.
+
rEFIt's ext2fs and ReiserFS drivers—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 refit-bin-0.14/efi/tools/drivers 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 thin 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.
Clover EFI's ISO-9660, ext2fs, ext4fs, and HFS+ drivers—This project is an offshoot of TianoCore, the main UEFI project. It's primarily a Hackintosh boot loader, but it includes drivers for ISO-9660, ext2fs, ext4fs, and HFS+; 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.
@@ -297,9 +322,38 @@ fs0: map -r
-
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 Unknown. (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.
+
The rEFIt, Clover, and VirtualBox drivers are related, and all of them
+have fed into rEFInd's drivers. 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 Unknown. (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.
+
+
Although I know of no readily-available hardware drivers, I do know of a couple of non-hardware non-filesystem drivers:
-
Driver availability could increase in the future. Source code to a wide variety of filesystems is available in GRUB Legacy, GRUB 2, Linux, various BSD kernels, and in other projects. Sooner or later somebody's likely to begin porting those drivers to EFI. If you do so, or if you know of additional EFI drivers, please tell me about it, so I can share the information here. Likewise if you know of a source for other EFI drivers—say, for a video card or disk controller card.
+
+
+
CrScreenshot—This driver adds a screenshot capability to any EFI. Note that it's available only as source code that requires the Tianocore EDK2 to build. I have not tested it. (Note also that rEFInd provides its own screen shot capability; pressing F10 takes a screen shot within rEFInd.)
+
+
RamDiskPkg—This is a rudimentary RAM disk driver. It must be compiled with a RAM disk image; the resulting binary is hard-coded with a fixed RAM disk image. It's therefore useful mostly for developers.
+
+
+
+
Both of these drivers are useful mainly for developers.
+
+
+
+
Driver availability could increase in the future. If you know of
+additional EFI drivers, please tell
+me about them, so I can share the information here. Likewise if you
+know of a source for other EFI drivers—say, for a video card or disk
+controller card.
Once you've obtained an EFI driver, you can install it in rEFInd just as you would install rEFInd's own drivers, as described earlier.
@@ -307,9 +361,27 @@ fs0: map -r
Notes on Specific Drivers
-
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.) The Btrfs driver is the newest of the lot, and so I've tested it the least, but it's worked for me on two test systems. 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 /boot partition; however, if you're willing to use ext3fs, ext4fs, Btrfs, or ReiserFS on your root (/) 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.
-
-
As noted earlier, rEFInd's drivers prior to version 0.7.0, as well as related drivers from rEFIt, Clover, and VirtualBox, suffer from speed problems. These problems are mostly minor, adding a second or two to boot times; but on some computers, the speed problems can be dramatic, boosting kernel-load times up to as much as three minutes (under VirtualBox). If you run into excessive boot times with such a driver, try switching to the latest rEFInd driver instead.
+
Warning: When compiled with GNU-EFI, rEFInd's drivers hang when run on my 32-bit Mac Mini. The TianoCore-compiled versions are fine, and the GNU-EFI-built binaries are fine on a 32-bit VirtualBox. The 64-bit GNU-EFI-built versions are fine on a MacBook Pro. Thus, the problem is very limited in scope. The problem can be quite serious if you run into it, though, since you must bypass rEFInd to boot the computer. In debugging the problem, I found that a key funtion was being entered mid-function, which suggests either an EFI bug or a problem with the compiler or related tools. In any event, the solution is simple: Use driver binaries built with TianoCore if you have a 32-bit Mac.
+
+
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.) The Btrfs driver is the newest of the Linux filesystem
+drivers included with rEFInd, and so I've tested it the least, but it's
+worked for me on several test systems. 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 /boot partition; however, if
+you're willing to use ext3fs, ext4fs, Btrfs, or ReiserFS on your root
+(/) 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.
+
+
As noted earlier, rEFInd's drivers prior to version 0.7.0, as well as related drivers from rEFIt, Clover, and VirtualBox, suffer from speed problems. These problems are mostly minor, adding a second or two to boot times; but on some computers, the speed problems can be dramatic, boosting kernel-load times up to as much as three minutes (under VirtualBox). If you run into excessive boot times with such a driver, try switching to the latest rEFInd driver instead. You might also try Pete Batard's efifs drivers.
Although ext2fs, ext3fs, ext4fs, and ReiserFS are all case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work; however, rEFInd 0.6.11 and later ignore symbolic links, since many distributions use them in a way that creates redundant or non-functional entries in the rEFInd menu. You should be able to use hard links if you want to use a single kernel file in multiple ways (say for two distributions).
+
@@ -56,8 +57,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
-
-