Figure 1: The boot process for a BIOS-only or EFI-only computer is relatively simple.
Originally written: 6/13/2015; last update: 7/7/2018
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 another value |
This page is part of my Managing EFI Boot Loaders for Linux document. If a Web search has brought you to this page, you may want to start at the beginning.
Most modern Extensible Firmware Interfaces (EFIs) and Unified EFIs (UEFIs) include a feature called the Compatibility Support Module (CSM). This feature enables an EFI-based computer to use BIOS-mode boot loaders, much like WINE enables Linux to run Windows binaries. CSM is often activated in the firmware setup utility by enabling a feature called "legacy mode." Thus, three names (BIOS, CSM, and legacy) may refer to the same thing.
Although CSM sounds like a wonderful feature, it has some serious drawbacks, as this document explains. If you must use it, you should understand how to make best use of it on your computer.
Before delving into the main points of this page, I'd like to address some common misconceptions. First, an EFI is not a BIOS. Many people (even manufacturers) refer to EFIs as "BIOSes," but this nomenclature encourages thinking of EFIs in BIOS terms, as if an EFI were a simple add-on to a BIOS. An EFI is a fundamentally new type of firmware, though, and if you think of it in BIOS terms, you're likely to apply a lot of BIOS assumptions to EFI that are flat-out wrong.
Related to this is the way the CSM interacts with the EFI. The CSM is an add-on EFI feature. Some people refer to "enabling EFI support," but that's exactly backwards—on most EFI-based computers, EFI is the native mode. It's the CSM (aka "legacy mode") that may be optionally enabled. (The sidebar to the right describes an exception to this rule.) When the CSM is enabled, the EFI is still working. In fact, as described in more detail shortly, enabling the CSM does not guarantee a BIOS-mode boot. Note, however, that some EFIs' user interfaces present EFI/UEFI and BIOS/CSM/legacy options as if they were mutually exclusive. In some cases this user interface design is accurate; the EFI might create strict one-mode boot pathways. In other cases, the user interface is deceptive; the selected boot mode is more of a suggestion than a command.
Most OSes released for x86 and x86-64 computers since the mid-1980s assume that the computer has a conventional BIOS similar to the one developed by IBM for its original IBM PC line. Without a CSM, a modern EFI-based computer is cut off from all BIOS-based OSes, with the exception of OSes that also provide EFI compatibility, such as Windows 7 and later and most modern Linux distributions.
All but very old versions of Linux can boot using EFI-based boot loaders such as GRUB 2, so BIOS compatibility isn't a compelling feature for a Linux-only computer. If you happen to want to boot an older OS, though, BIOS compatibility becomes desirable. In this context, an "older OS" might include certain BSDs, DOS, Windows XP, OS/2, BeOS, and many other obscure OSes. Also, some emergency tools (especially older ones) can boot in BIOS mode but not in EFI mode. Thus, a CSM can be an important feature for certain emergency maintenance tasks.
Another advantage of the CSM is that it interfaces with the firmware on most plug-in cards that provide firmware, such as most video cards. To work in native EFI mode, a plug-in card that requires firmware must provide EFI-compatible firmware. Note that this advantage of a CSM can be important even if you boot your OSes in EFI mode; the firmware itself relies on the CSM to display boot-time messages, including the menus created by your boot manager.
BIOS-mode boots of modern OSes involve switching the bit depth from the 16-bit code used by the BIOS to the 32- or 64-bit depth used by the OS. EFI, on the other hand, is designed to work in the CPU's native bit depth, so a 64-bit computer has a 64-bit EFI, with no switching of bit depth required. The drawback to this setup is that it becomes more difficult to install an OS whose bit depth doesn't match that of the firmware. Normally, this is a problem when installing a 32-bit OS on a system with a 64-bit EFI; but a few machines (mostly some very early Intel-based Macs and some modern tablets) have 64-bit CPUs but 32-bit EFIs. In any of these cases, the presence of a CSM makes it easier to install an OS using a bit depth that doesn't match the EFI.
For all of these reasons, having a CSM on your computer is desirable. As time goes on, though, these reasons for having a CSM will all fade. Even today, DOS, Windows XP, OS/2, and BeOS are pretty dated; and eventually most plug-in cards with firmware will provide EFI-compatible firmware.
To understand the dark side to a CSM, consider the boot process. Figure 1 shows a summary of the BIOS boot process. This figure simplifies things a bit; for instance, the "Valid Loader" decision point may involve checking for loaders in several locations (hard disk, USB flash drives, optical discs, and so on). Furthermore, once the boot loader has started any number of problems can prevent an OS from booting (such as an incorrect root= specification passed to the kernel).
Figure 1: The boot process for a BIOS-only or EFI-only computer is relatively simple.
Importantly, Figure 1 also describes the EFI boot process when a CSM is not available or is disabled. The main difference from BIOS at this level of analysis is that there are more options for boot loader locations under EFI than under BIOS, so the "Valid Loader" decision point hides more for an EFI boot than for a BIOS boot. EFI also supports Secure Boot, which can render a loader invalid because it lacks an appropriate signature.
If you have an EFI with a CSM that is enabled, the boot process becomes much more complex, as shown in Figure 2. This added complexity is especially important in a multi-boot configuration, because it's easy to accidentally install one OS in BIOS mode and another in EFI mode. Such mixed-mode installations can be nightmares to maintain. Importantly, even if you haven't yet installed Linux, the extra complexity of Figure 2 can make it harder to install the OS, particularly if the computer already hosts another OS.
Figure 2: The boot process becomes much more complex when CSM is activated.
To understand this better, consider some of the complexity of an EFI with CSM enabled, as illustrated by Figure 2:
Some EFI installation instructions for Linux explicitly call on the user to enable the CSM. This can work OK for a single-boot installation. The reason is that whatever decision point the computer takes for the initial boot mode will normally (but not always) result in the OS installing itself in the same mode. With the computer set up in BIOS mode, the computer will be likely to try a BIOS-mode boot of the installed OS; and with it set up in EFI mode, an EFI-mode boot will thereafter likely be attempted. I've heard of a few cases where this rule is violated, though, which can be very frustrating—once the system is set up and installed in BIOS mode, the firmware might refuse a BIOS-mode boot from the hard disk! Typically, the cause is an unusually fine-grained set of BIOS-vs.-EFI options in the firmware, enabling you to set BIOS-mode booting of external media but not internal disks, for instance.
Most modern PCs ship with Windows 8 or later, and these installations almost always boot in EFI mode. The computers are configured as in Figure 1—with the CSM disabled, the boot path is simple. Enabling the CSM on such a system creates two problems:
The usual symptom of a computer with an EFI-mode Windows installation and a BIOS-mode Linux installation is that it will boot straight to one OS or the other. If it boots to Linux, GRUB might or might not appear; and if it does appear, any Windows option it contains will not work. You may be able to switch OSes by using the computer's built-in boot manager, but this isn't always the case. Repairing such a problem is best done by installing an EFI-mode boot loader. For Ubuntu and closely-related distributions, this can be done by the Boot Repair utility, but this is best done from an EFI-mode boot—and of course booting in this way becomes a chance affair with the CSM enabled. Furthermore, Boot Repair might or might not work on unrelated distributions.
Despite the preceding problems, using BIOS/CSM/legacy mode to install Linux is not always without merit. The trouble with a purely EFI-mode installation is that EFI is still new enough that there are numerous glitches that await the unwary. Most of these problems affect a tiny fraction of all users, but they can add up to a significant number of problems:
If you run into one of these problems, it's best to try to resolve it without enabling your CSM; however, this isn't always possible, so you may need to resort to a CSM-enabled installation. In a worst-case scenario, you might need to re-install Windows in BIOS mode or manage your mixed-mode (EFI plus BIOS) installation by using your firmware's built-in boot manager or rEFInd.
No matter what your plans, it's best to understand how to manage your CSM. Unfortunately, details differ significantly from one computer to another, so there's no way to tell you how to do this that is universally applicable. There are, however, two broad use categories you should understand: Setting permanent options and using the built-in boot manager.
Permanent options are set in the firmware setup utility's main options pages. There are several ways to access these screens:
Some computers have a "fast start" or similar option that can make it difficult or impossible to access the setup utility via boot-time function keys. Disabling this fast start feature may enable the ability to enter the setup utility via a keypress—but of course this poses a chicken-and-egg conundrum. The workaround is to use another method of entering this utility for the first time.
Once you're in the setup utility, you should search for your CSM options. Note that there is no standardization of names for these options; they may be called "CSM," "legacy support," or other things. Figure 3 shows a typical example. You should experiment with these options, as well as those around them; sometimes options appear and disappear as others are adjusted, so you may need to change several options to find the combination you need. For instance, on one computer I own, the CSM option appears only after Secure Boot is disabled.
Figure 3: Names and locations of CSM options in EFI setup utilities vary greatly.
Most EFI-based computers provide a built-in boot manager. From a user interface point of view, these tools are typically expansions of the device-selection menus of BIOSes. You can typically access this menu by pressing Esc, F8, F10, or some other function key soon after you power on the computer. As with entering the firmware setup utility, there is no standardization from one computer to another. On Macs, holding the Option key (or the Alt key if you have a PC keyboard) enters the built-in boot manager.
The same fast-start option that can complicate access to the setup utility can make it difficult or impossible to use the computer's built-in boot manager. Worse, some early EFIs provide such a basic boot manager that it's useless—it presents no more options than a BIOS's device selection screen, omitting the true EFI boot loader variables from the list.
One key point to understand about EFI boot managers is that, with the CSM active, they often present two boot options for removable media. One option typically includes the string "UEFI" and the other doesn't, as shown in Figure 4. Selecting the "UEFI" option boots in that mode, whereas selecting the option without that string boots in BIOS mode. You can use this feature to force a boot in one mode or the other—but beware of the "BIOS Fallback" decision point in Figure 2! Even though you select an EFI-mode boot, if that fails the firmware may decide to try to boot the medium in BIOS mode, so you may end up with a BIOS-mode boot even though you explicitly told the computer to boot in EFI mode!
Figure 4: To boot an external disk in EFI mode, select the option for that disk that includes the string "UEFI"; to boot in BIOS mode, select the option that lacks this string.
CSM problems usually arise when a Linux installation goes awry. As noted earlier, users often accidentally create USB flash drives that omit the critical EFI boot loaders. The EFI Boot Loader Installation page of this document describes how to install an EFI boot loader in general terms. You may need to use that page and place your chosen boot loader under the fallback filename (EFI/BOOT/bootx64.efi for x86-64 systems). If you're using a popular distribution that supports both BIOS-mode and EFI-mode installations, though, there's often an easier solution.
Users of such distributions often use custom Windows or Linux tools to create their USB flash drives. Some of these tools omit one or the other boot loader by default, so you must select options or switch tools to create a boot medium that's bootable in EFI mode. My observations on a few tools include:
All of these tools except for Pen Drive Linux/YUMI/MultiSystem were able to create EFI-bootable disks in my tests in June of 2015. In the past, I've used tools that explicitly required enabling an EFI-boot option, but I don't recall if these were earlier versions of some of the preceding tools or unrelated programs. Very old tools lack EFI support entirely, and the same might be true even of some more recent tools.
It should also be noted that different EFIs may respond differently to certain disk features, such as the use of MBR vs. GPT and to the unusual partition table that results from a dd-created disk. Furthermore, different distributions set up their disks in different ways, and one tool might work better than another for certain distributions.
Some users have reported that they can more easily boot optical discs than USB drives in EFI mode. I don't know if these reports are indications of finicky EFIs or if the users made mistakes when preparing their USB media. In any event, if your computer has an optical drive and you have problems booting USB media, it's worth trying an optical disc.
The bottom line is that you may need to experiment, particularly if you're trying to install an unusual distribution. It may be worth checking your distribution's instructions on how to install on an EFI-based computer. If you have problems with one method (even if it's the method recommended in your distribution's documentation), try another one rather than activating the CSM; use the CSM only as a last resort.
The CSM is a useful stop-gap tool, but it should not be over-used. Unfortunately, many in the Linux community have been doing just that—advice to activate the CSM as a routine part of Linux installation is common. (This advice is becoming less common as EFI support improves and as EFI knowledge spreads.) As you should understand if you've read this page, this advice leads to a lot of problems because people create mixed-mode installations that they must then repair with very little understanding of the nature of the problem.
My advice is therefore to use the CSM only when it's absolutely required or in single-boot configurations, and to avoid it in other situations. Specifically:
If you do enable the CSM, pay attention to your boot mode. Use the built-in boot manager, as described earlier, to boot in your desired mode—but be aware of the risk of the firmware ignoring your instructions and booting in the other way. In Linux, you can check your actual boot mode by looking for the directory called /sys/firmware/efi. If that directory is present, you've booted in EFI mode; if it's absent, you've probably booted in BIOS mode. (There are ways to boot in EFI mode and yet have no /sys/firmware/efi file. This type of setup is rare with modern distributions, though. See the rEFInd documentation's What's Your Boot Mode? page for more on this topic.)
Another point requires mention: Many EFIs are very buggy. Of particular note for this page, some EFIs tend to forget or ignore their boot manager entries, meaning that they end up booting nothing but the fallback (EFI/BOOT/bootx64.efi on x86-64 systems) or Windows (EFI/Microsoft/Boot/bootmgfw.efi) loader. This works fine when booting external media, but the installed Linux may then fail to boot. Users who run into this problem sometimes throw their hands up in frustration and try a BIOS-mode installation. This often works on single-boot systems, but as you should now see, using the CSM has serious problems on a computer that already boots Windows in EFI mode. The fallback.efi program provides a better solution to this problem. Another is to rename your boot programs so that your preferred boot manager (probably GRUB, rEFInd, or gummiboot/systemd-boot) is installed in place of the Windows boot loader, and the Windows boot loader takes on another name. This basic process is described on the EFI Boot Loader Installation page. The rEFInd documentation provides more rEFInd-specific instructions on how to do this.
Return to "Managing EFI Boot Loaders for Linux" main page
copyright © 2015–2018 by Roderick W. Smith
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.