The rEFInd Boot Manager:
Using EFI Drivers
by Roderick W. Smith, rodsmith@rodsbooks.com
Originally written: 4/19/2012; last Web page update:
2/1/2014, referencing rEFInd 0.8.5
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!
Donate $1.00 |
Donate $2.50 |
Donate $5.00 |
Donate $10.00 |
Donate $20.00 |
Donate another value |
|
|
|
|
|
|
This page is part of the documentation for the rEFInd boot manager. If a Web search has brought you here, you may want to start at the main page.
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.
Why Should You Use EFI 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 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.
- You can load a driver for a plug-in network card to enable the computer to boot from the network, or to access the network without booting an OS. Note that rEFInd does not currently support network boots itself, though.
- You can load a video card driver to set an appropriate video mode or to support a plug-in card that lacks EFI support in ts own firmware.
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 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.
Using rEFInd's EFI Drivers
Since version 0.4.0, rEFInd has shipped with a small collection of read-only EFI filesystem drivers. These are:
- 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.
- 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.
- 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. 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 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.
- 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.
- ISO-9660—This driver originated with rEFIt's author, but
he never released a final version. Its code was improved by Oracle for
use in its VirtualBox product, and then further modified by the authors
of the Clover boot
loader. If your firmware doesn't provide its own ISO-9660 driver, this
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.
- NTFS—Samuel Liao contributed this driver, which uses the
rEFIt/rEFInd driver framework. My own testing of it is limited, but it
does work for me. Note that this driver is not required
to boot Windows with rEFInd, since Windows stores its boot loader on
the (FAT) ESP. You might use this driver if you want to store large
boot files, such as EFI-accessible RAM disk images, from Windows.
All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.
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:
fs0: load reiserfs_x64.efi
fs0: map -r
Finding Additional EFI Drivers
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:
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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.
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 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).
copyright © 2012–2014 by Roderick W. Smith
This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.
If you have problems with or comments about this Web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Go to the main rEFInd page
Learn about how to adjust rEFInd's appearance
Return to my main Web page.