Originally written: 4/19/2012; last Web page update:
-8/12/2012, referencing rEFInd 0.4.5
+3/4/2017, referencing rEFInd 0.10.5
-
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!
+
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!
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.
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:
-
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.
Note that most of these uses are theoretical, at least to me; I don't know of any specific examples of EFI drivers (available as separate files) for disk controller hardware, network cards, or video cards. Such drivers are often embedded in the firmware of the devices themselves, and should be loaded automatically by the EFI. Chances are good that a few such drivers are available, unknown to me, and more may become available in the future. If you happen to have a device and need support for it under EFI, searching for drivers is certainly worth doing.
-
To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with EFI stub loader support from booting from the ESP of at least some Macs.
+
To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently somewhat limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with EFI stub loader support from booting from the ESP of at least some Macs.
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.
If you install rEFInd via the refind-install script or by installing an RPM or Debian package in a Linux distribution, the script should install the driver that matches the filesystem on which your kernels are stored automatically, with a couple of important caveats:
+
+
+
+
The driver must be included with the rEFInd package. As described in the next section, Selecting an EFI Driver, drivers for ext2fs, ext3fs, ext4fs, ReiserFS, Btrfs, and a few non-native filesystems come with rEFInd. If your kernels reside on XFS, JFS, ZFS, or some other more exotic filesystem, you'll need to track down drivers elsewhere, as described in Finding Additional Drivers, and install them manually.
Note: 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 rEFIt, which work on Macs.
-
Since version 0.4.0, rEFInd has shipped with a small collection of read-only EFI filesystem drivers. These are:
+
If you run refind-install from OS X, the script installs only the ext4fs driver, and that only if the script finds an existing Linux partition. Thus, if you install rEFInd before installing Linux, chances are refind-install will not install any Linux driver. Also, if you use any filesystem other than ext2/3/4fs to hold your kernel, refind-install won't install the correct driver. If you install rEFInd followed by Linux and want to use rEFInd's driver, you can either re-install rEFInd or install the appropriate driver manually. The refind-install 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.
+
+
+
+
rEFInd's filesystem drivers reside in the refind/drivers_arch subdirectory of the rEFInd .zip file, where arch is a CPU architecture code, such as x64 or ia32. If you installed rEFInd using an RPM or Debian package, chances are the relevant files will be stored in /usr/share/refind/refind/drivers_x64/ or a similar location. You can type find /usr/share/ -name "ext4*" to find the exact location, or use your package manager to list all the files installed from the refind package. The files are named after the filesystems they handle, such as ext4_x64.efi for the x86-64 ext4fs driver. You should copy the files for the filesystems you want to use to (You may need to create this subdirectory.)
+
+
To install a driver, you must copy it from the package .zip file or from where the rEFInd RPM or Debian package placed it to the drivers or drivers_arch subdirectory of the main rEFInd installation directory. The main rEFInd directory is usually either EFI/refind or EFI/BOOT on the EFI System Partition (ESP). How to identify and access the ESP varies from one OS to another:
-
ReiserFS—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.
+
Under Linux, the ESP is normally mounted at /boot/efi, or sometimes /boot.
+
+
On OS X, the ESP is not normally mounted, but the mountesp script that comes with rEFInd will mount it and identify the mount point.
+
+
Windows also does not normally mount the ESP, but it can be mounted from an Administrator command prompt window by typing mountvol S: /S. (You can change S: to another drive identifier, if you like.)
+
+
+
+
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.
+
+
Warning:Do not place EFI program files in your driver directories! Unfortunately, EFI uses the same .efi 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.
+
+
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:
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.
-
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.
+
Since version 0.4.0, rEFInd has shipped with a small collection of read-only EFI filesystem drivers. These are:
+
+
+
+
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 ext2fs on it. Although
+ it's called an "ext2fs" driver, it also works with ext3fs.
+
+
Ext4fs—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
+ can handle ext2fs and ext3fs, too. Providing both drivers enables easy
+ filesystem separation—for instance, you can use ext2fs on a
+ /boot partition and ext4fs on your root (/) partition,
+ to have the EFI scan only the former. This driver has some limitations
+ and may not work with all ext4 filesystems. Although it supports (as of
+ version 0.10.4) 64-bit pointers, this support is untested on over-16TiB
+ volumes. As of version 0.6.1, this driver supports the meta_bg
+ 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
+ dumpe2fs /dev/sda2 | grep features,
+ changing /dev/sda2 to your
+ filesystem's device.
+
+
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. In my tests,
+ this is the fastest of rEFInd's EFI filesystem drivers, so if you find
+ your kernel load times are slow, you might consider moving your kernel
+ to a ReiserFS /boot partition. (Such problems affect a small
+ subset of EFI-based computers.)
+
+
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 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 that span 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.
+
+
Tip: If you partition a USB flash drive and use dd to copy Linux .iso images to the drive's individual partitions, the rEFInd ISO-9660 driver enables rEFInd to boot multiple Linux distributions' installers from the USB flash drive. I can't promise this feature will work with all distributions, but it does work with some.
ISO-9660—This driver originated with rEFIt's author, but
he never released a final version. Its code was improved by Oracle for
@@ -145,75 +295,113 @@ 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. Various rEFInd versions include fixes intended to address this problem, but I can't be sure it's been completely eliminated.
+
+
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 use Windows to write large files, such as RAM
+ disk images, to be read from EFI.
+
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. They all suffer from speed problems on some systems, as described later in "Notes on Specific Drivers;" however, these problems are very minor on most systems.
+
All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.
-
Note: rEFInd's install.sh script does not currently install drivers; however, if you installed manually, you may have already installed rEFInd's drivers. See the Installing rEFInd page for details.
+
Although Linux filesystems 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).
-
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 ext2_x64.efi for the 64-bit ext2fs 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.
Warning:Do not place EFI program files in your driver directories! Unfortunately, EFI uses the same .efi 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.
+
As already noted, I know of few 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:
-
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:
-
-
-fs0: load reiserfs_x64.efi
-fs0: map -r
-
+
-
If you build rEFInd from source, you should be aware that the drivers rely on TianoCore's development kit, whereas rEFInd itself uses GNU-EFI. Thus, to compile both, you'll need to install both development kits. 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 BUILDING.txt 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 Getting rEFInd page for details) or use drivers from another source.
+
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 1.0; July 2016), several drivers, including NTFS, exFAT, ext2fs, ReiserFS, Btrfs, JFS, and XFS, are usable. The last time I tested them (version 0.7), some drivers were slow, and they hung on some computers, such as one of my Macs. They may have improved since then, and are likely to improve more in the 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.
-
Finding Additional EFI Drivers
+
The LKL driver project—I have yet to look closely at this project, but I think it's a porting of the Linux kernel's filesystem drivers to EFI. The developer stated on the EFI developers' mailing list that they aren't yet stable, as of November 2016.
-
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:
+
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 are closely related to rEFInd's own drivers. Thus, as with the rEFIt drivers, there's likely to be no advantage to using the Clover drivers over the rEFInd drivers.
-
rEFIt's ext2fs and ReiserFS drivers—You can gain read-only access to ext2fs, ext3fs, and ReiserFS volumes with these drivers. 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.
+
Clover's EFI Tools package—This osx86.net thread includes links to a package called EFI_Tools_Clover_v2_r1888_EN.zip, which holds an OS X application (a directory with a .app extension, as seen from other platforms) with a number of drivers in the Contents/Resources/EFI/drivers64 directory (and an equivalent for 32-bit binaries). Some of these, such as keyboard drivers, are unlikely to be useful unless your system is badly broken as delivered. Three that caught my eye, however, are VBoxExt2-64.efi, VBoxIso9600-64.efi, and NTFS-64.efi. The first two of those are presumably variants on rEFInd's drivers, but the NTFS driver is not. I don't know this driver's provenance, so I'm reluctant to recommend its use, but it bears mentioning.
-
Clover EFI's ISO-9660, ext2fs, 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, and HFS+; however, building them requires a fair amount of expertise. These drivers served as a starting point for rEFInd's drivers.
+
VirtualBox's HFS+ and ISO-9660 drivers—These drivers are available in source code form, and come with VirtualBox binaries. I've not attempted to compile them myself, but I've seen a report that suggests they may include assumptions that require use of MinGW, a GCC-based compiler for Windows (and cross-compiler to build Windows executables under Linux). I don't know of a source for binaries suitable for use on EFI-based computers; if you want to use them, you'll need to figure out how to compile them yourself. As noted earlier, rEFInd's drivers are closely related to these.
-
Clover's EFI Tools package—This osx86.net thread includes links to a package called EFI_Tools_Clover_v2_r447_EFI_x32_x64_EN.zip, which holds an OS X application (a directory with a .app extension, as seen from other platforms) with a number of drivers in the Contents/Resources/EFI/drivers64 directory (and an equivalent for 32-bit binaries). Some of these, such as keyboard drivers, are unlikely to be useful unless your system is badly broken as delivered. Three that caught my eye, however, are VBoxExt2-64.efi, NTFS-64.efi, and VBoxIso9600-64.efi.
+
Ext2Pkg—This driver, based on bitbucket and with a backup on github, 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 git 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.
-
VirtualBox's HFS+ and ISO-9660 drivers—These drivers are available in source code form, and come with VirtualBox binaries. I've not attempted to compile them myself, but I've seen a report that suggests they may include assumptions that require use of MinGW, a GCC-based compiler for Windows (and cross-compiler to build Windows executables under Linux). I don't know of a source for binaries suitable for use on EFI-based computers; if you want to use them, you'll need to figure out how to compile them yourself.
+
Paragon's UFSD—According to this blog post, Paragon Software has ported its Universal File System Drivers (UFSD) 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.
-
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.)
+
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 worst of the speed problems in rEFInd's drivers as of version 0.7.0; however, I still see occasional reports of speed problems on specific computers.
+
+
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.
+
-
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.
+
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.
-
I've tested several of the drivers described on this page on a handful of systems. The ext2fs driver (from any source) works on both ext2fs and ext3fs, but not on ext4fs—at least, not in my one test. (There may be options you can use when creating an ext4 filesystem that would enable the ext2fs driver to handle it, but if so I don't know what they are.) The ReiserFS driver is obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as far as I know.) Given that these filesystems 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 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.
+
-
The ext2fs and ReiserFS drivers work, but they are a bit sluggish—particularly the ext2fs driver. 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, 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 ReiserFS instead of ext2fs or ext3fs, at least if a change is practical. (For a /boot 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 /etc/fstab entry for a new UUID value, though. As noted earlier, be sure to use notail as an option in /etc/fstab for ReiserFS if you want to read it from EFI.) You can even use HFS+ on a Linux /boot partition, although this makes the most sense on a Mac, which has its own EFI HFS+ driver.
+
Both of these drivers are useful mainly for developers.
-
Since the ext2fs and ReiserFS drivers share a common origin, it should come as no surprise that they perform in much the same way no matter which version (rEFIt, Clover, or rEFInd) you use. The NTFS driver from the Clover Tools package is nice and speedy, so if for some reason you need to place a boot loader on an NTFS volume, this driver might be worth tracking down.
+
+
+
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.
-
Although both ext2fs and ReiserFS are case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work, which opens up possibilities for configuration, such as using a single kernel binary for multiple Linux distributions, with a link in one subdirectory pointing to a file in another directory. (If you try this, though, be sure to use relative links, as in ../otherdist/bzImage.efi, at least if the partition is not Linux's root filesystem.)
+
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.