The rEFInd Boot Manager:
Using EFI Drivers

by Roderick W. Smith,

Originally written: 4/19/2012; last Web page update: 3/4/2023, referencing rEFInd 0.14.0

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.

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:

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 most hardware, although the Clover boot loader project provides a few such drivers. I haven't tested these, though. Hardware 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. EFI filesystem drivers can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as a too-small ESP created by an OS installation 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.

I've seen reports of (very rare) computers that provide built-in NTFS drivers. Unfortunately, these drivers are sometimes buggy, and can cause rEFInd to hang; see this discussion of a problem with an HP computer for an example. If you suspect you're running into such a problem, the best solution is to disable scanning of the affected partition(s) by using the dont_scan_volumes token in refind.conf. Pass it the filesystem name, partition name, or GUID of the volume(s) in question, as in:

dont_scan_volumes B034F306-A900-4AC7-9BF7-737601DAE627,Windows

This example prevents rEFInd from scanning the partition with a partition-unique GUID of B034F306-A900-4AC7-9BF7-737601DAE627 or any partition called Windows. Identifying a partition by its GUID (which you can learn using gdisk or some other partitioning tools) is most reliable, but the partition's name can also work, and is sometimes easier to determine. Another possible solution to this problem is to run a filesystem check on the filesystem; this may correct a filesystem error, if that is tripping up the driver.

Installing rEFInd's EFI Drivers

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:

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.

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:

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 btrfs_x64.efi
fs0: map -r

Selecting an EFI Driver

rEFInd ships with a small collection of read-only EFI filesystem drivers. These are:

All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.

Although Linux filesystems are all case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work; however, rEFInd gnores 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).

Finding Additional EFI Drivers

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:

The rEFIt, Clover filesystem, 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:

The first two of these drivers are useful mainly for developers, but the Clover filesystem drivers could be useful to ordinary people.

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.

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.

copyright © 2012–2023 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 Thanks.

Go to the main rEFInd page

Learn about how to adjust rEFInd's appearance

Return to my main Web page.