by Roderick W. Smith, rodsmith@rodsbooks.com
Originally written: March 14, 2012; last Web page update: April 6, 2024, referencing rEFInd 0.14.2
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.
Before you invest time in downloading and trying to install rEFInd, you may want to verify that you can actually use the program at all. rEFInd is useful only on EFI-based computers, not older BIOS-based computers. In fact, most EFI-based x86-64 computers provide a Compatibility Support Module (CSM), which is essentially a BIOS emulation mode. Some EFI implementations are in fact built atop a conventional BIOS, and retain BIOS's boot abilities via this underlying code. Thus, it's possible that you're currently booting a modern EFI-capable computer in BIOS mode. In addition to this page, you may want to check out my page on the CSM, which describes why the CSM exists, how to control it, and how it can create problems.
Unfortunately, determining which mode you're using can be tricky; the clues are subtle or hidden in ways that require specialized knowledge to extract. This page will help you figure it out. I first present general information on identifying your hardware's capabilities. I then describe ways to identify your current boot mode in both Linux and Windows.
Let's get the easy case out of the way: If you have a Macintosh with an Intel CPU, it's got EFI capabilities, and you'll be able to use rEFInd. Earlier Macs with PowerPC CPUs use OpenFirmware, not EFI, and rEFInd can't be used with them. The latest Macs (introduced late in 2020) use ARM CPUs — but as of early 2021, many Macs are still based on Intel CPUs. I don't yet own one of the new ARM-based Macs, but my understanding is that they are also EFI-based; however, I don't know if the current ARM build of rEFInd will run on them, and it's still early days for multi-booting such computers. See this blog post for information on an early attempt (which does not seem to use rEFInd). If you want to use rEFInd on one of these new ARM-based Macs, you'll definitely be playing on the "bleeding edge."
If your computer shipped new with Windows 8 or later, it almost certainly supports EFI; Microsoft requires that desktop and laptop computers that bear a Windows 8 (or later) logo support EFI, and boot in EFI mode. Most x86 and x86-64 computers released after late 2011 support EFI, although there are some laggards, particularly among server-class machines. Almost everything sold new since about 2014 is based on a decent EFI implementation.
For everything else, it can be harder to tell. Your best bet is to locate a PDF version of your computer's or motherboard's manual and search it for the string EFI. Checking your firmware's options via the firmware setup utility (typically access by pressing Del, Esc, F2, F10, or F12 at boot time) is also worth doing, but you'll need to check every option yourself. Most EFI-enabled PCs include at least one reference to an option you can set; however, manuals and firmware setup tools often don't make a big deal of this feature, particularly on boards with relatively primitive EFI support. For instance, the manual for a Gigabyte GA-78LMT-S2P motherboard includes the following paragraph, on p. 28:
A casual reader might easily overlook this option, or misinterpret it to mean that the feature is much less important than it is. In fact, this particular motherboard offers very poor control over its EFI vs. BIOS booting features. (See my Web page on this EFI implementation for details.)
Some manuals omit even mention of EFI, and instead refer to "legacy boot" or some similar term, referring to BIOS-style booting. The firmware for my ASUS P8H77-I motherboard uses the technical term CSM, which of course will be baffling to the uninitiated. (I referred to it earlier. It's the Compatibility Support Module—in other words, the BIOS support code.) Such references may imply that the firmware supports EFI booting if the "legacy boot" mode is disabled or restricted in some way.
Understated EFI features often indicate a slapdash approach to EFI. Such systems sometimes implement EFI as a layer atop a conventional BIOS. More modern EFIs, though, completely replace the BIOS. Some manufacturers, such as ASUS and its sibling ASRock, are now actively promoting their more advanced EFI implementations. Such products often come with flashy new GUIs in their firmware.
Positive identification of EFI support in your firmware does not guarantee that your current OSes are booting in EFI mode. (MacOS booting on an Intel-based Mac is an exception to this rule, though.) For that, you'll need to run some tests in your running OSes.
Identifying your boot mode in Linux is relatively straightforward. The simplest way is to check for the presence of a /sys/firmware/efi directory. The mere existence of this directory indicates that the computer has booted in EFI mode. Its absence suggests a BIOS-mode boot—but see below for an important caveat.
Another test, which produces more detailed information about the EFI implementation, is to check the kernel ring buffer for references to EFI. You can do this as follows:
The result on a BIOS-based computer should be few or no lines of output. On an EFI-based computer, though, the output will be extensive:
[ 0.000000] efi: EFI v2.31 by INSYDE Corp. [ 0.000000] efi: ACPI=0x9cffe000 ACPI 2.0=0x9cffe014 SMBIOS=0x9cebef98 [ 0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB) [ 0.000000] efi: mem01: type=2, attr=0xf, range=[0x0000000000001000-0x0000000000008000) (0MB) ... [ 0.000000] efi: mem62: type=11, attr=0x8000000000000001, range=[0x00000000ff980000-0x0000000100000000) (6MB) [ 0.000000] ACPI: UEFI 000000009cffc000 00236 (v01 LENOVO CB-01 00000001 ACPI 00040000) [ 0.632723] efifb: probing for efifb [ 0.634127] efifb: framebuffer at 0xa0000000, mapped to 0xffffc90021780000, using 8100k, total 8100k [ 0.634129] efifb: mode is 1920x1080x32, linelength=7680, pages=1 [ 0.634130] efifb: scrolling: redraw [ 0.634132] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 0.644648] fb0: EFI VGA frame buffer device [ 0.754748] EFI Variables Facility v0.08 2004-May-17 [ 1.305636] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
I've actually cut quite a few lines from this output; there are a total of 62 EFI: mem## lines on this computer. (Another of my computers has 148 such lines!) A BIOS-based computer will lack most or all of these lines, and certainly the EFI: mem## lines. I've heard of some BIOS-based computers that produce the EFI Variables Facility line, though.
One caveat exists to these tests: It's possible to boot Linux in EFI mode but disable the EFI features that create the /sys/firmware/efi directory and the copious EFI output in dmesg. This can happen because your kernel was compiled without EFI support or because you've added the noefi line to your existing BIOS boot loader configuration. Some of these features will also be absent if the efivars driver is not built into the kernel and is not loaded as a module. Typing modprobe efivars should load this module, so you might try that before concluding you've booted in BIOS mode. To the best of my knowledge, no major Linux distribution ships with EFI support disabled in any of these ways, so chances are your tests won't mislead you to thinking you're using BIOS mode unless you've recompiled your kernel or deliberately added a noefi parameter to your boot loader configuration.
Depending on your Windows version, at least two ways of identifying your boot mode exist. The first method, using the Windows msinfo32 tool, works in Windows 8 and later, and is likely to be more reliable. The second method, checking your partition table, works in any version of Windows but can be tricky or misleading, particularly if your computer has multiple hard disks.
To use System Information to identify your boot mode, follow these steps:
Note that there are other ways to launch the System Information tool, so feel free to use one of them if you prefer it. Unfortunately, although Windows 7 provides the System Information utility, that version of the tool does not provide the boot mode information, so if you're using Windows 7, you must use another method to determine your boot mode.
If you can't use System Information to determine your boot mode, you can examine your partitions to identify your boot mode. Microsoft has tied use of the GUID Partition Table (GPT) to EFI booting. If you've booted from a GPT disk, then you must be using EFI, and if you've booted from a Master Boot Record (MBR) disk, you have almost certainly booted in BIOS mode. (I've heard of some exceptions to this rule, but they're exceedingly rare.) Therefore, you can check your partition table type as a proxy for your boot mode. To do this in Windows 7, follow these steps:
An important caveat with this method is that you must examine your boot disk. It's possible to use GPT on a data disk even on a BIOS-based computer, or to use an MBR data disk even on an EFI-based computer. Thus, if you examine the wrong disk, you can be led to an incorrect conclusion about your computer's boot mode.
Another caveat relates to the use of a hybrid MBR, which is a variant on a GPT disk that's most often used on Macs to permit booting Windows in BIOS mode and macOS in EFI mode. Most Windows tools will identify a hybrid MBR disk as an MBR disk, but most non-Windows tools will identify it as a GPT disk. Of course, as hybrid MBRs are generally used to enable dual-booting Windows and macOS, and as macOS boots in EFI mode, you should be able to install rEFInd from macOS to help manage such a dual-boot configuration.
copyright © 2012–2024 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.
Return to my main Web page.