Originally written: 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.
As described in EFI Boot Principles, the EFI boot process relies on both EFI boot loaders on the ESP and pointers to those boot loaders in the computer's NVRAM. Unfortunately, many circumstances can break the link between these two components—some EFIs have bugs, or the NVRAM entries can become damaged or lost; some EFIs deliberately delete invalid NVRAM entries, which can cause them to disappear if you deliberately (but temporarily) unplug a hard disk; you might intentionally or accidentally move a boot loader file; and so on. Such common occurrences can render a computer unbootable and necessitate using a recovery disk to restore bootability by re-creating the NVRAM entry with a tool such as efibootmgr, as described in EFI Boot Loader Installation. Such a repair can be beyond the abilities of the average user, or at least, can require following (not to mention first locating!) technical instructions that the user may find challenging.
Windows is not greatly affected by this problem. Because Windows is the 800-pound gorilla of the OS world, many EFIs are designed to look for the Windows boot loader (EFI/Microsoft/Boot/bootmgfw.efi) if nothing else is available. Windows also installs a copy of this boot loader in the fallback position of EFI/BOOT/bootx64.efi (or similar names for other architectures). Thus, Windows tends to keep booting even if its NVRAM entry is lost. Linux distributions, though, are another matter; if their NVRAM entries are lost, they tend to stop booting—or perhaps the computer will begin booting straight to Windows, which can be as frustrating to users.
To mitigate this problem, Linux developers created a program, originally called fallback.efi, but seldom installed using that name, to deal with the issue. This program is usually delivered as part of the shim or shim-signed package, and often appears in the Linux filesystem as fbx64.efi. It may be installed to the ESP using the fallback filename of EFI/BOOT/bootx64.efi; or it may be installed as EFI/BOOT/fbx64.efi, with Shim, the Secure Boot manager, installed as EFI/BOOT/bootx64.efi. (On IA32, AARCH64, and other architectures, of course, all of these filenames are adjusted appropriately.) With Shim in the picture, it hands off to fbx64.efi, so you can pretend that it launched directly.
Under any filename, fallback.efi is a sort of boot manager—but rather than present a menu of boot options, it scans the subdirectories of EFI on its own disk for files called BOOT.CSV, BOOTX64.CSV, or other architecture-specific variants of that filename. With this file found, it's read and processed to generate a new NVRAM entry. The program then launches the first of the new NVRAM entries it creates. A comma-separated value (CSV) file holds multiple data elements separated by commas; and in this case, the values are:
An example BOOT.CSV file for rEFInd might look like this:
refind_x64.efi,rEFInd,,This is the boot entry for rEFInd
This example is suitable for use with rEFInd if Secure Boot is not in use. (If you're using Secure Boot with Shim, you'd probably specify shimx64.efi rather than refind_x64.efi in this file and give rEFInd the filename grubx64.efi.) This example adds an entry for refind_x64.efi, with a label of rEFInd, to the NVRAM-based boot order list. In sum, the ESP's directory tree will look something like this, with this configuration in place and Secure Boot not in use:
EFI/
BOOT/
BOOTX64.EFI — really fallback.efi
refind/
BOOT.CSV
refind_x64.efi
(additional rEFInd support files)
Note that this is a minimal configuration involving fallback.efi; with Secure Boot and Shim involved, there will be two Shim binaries (one in each subdirectory of EFI); and if multiple boot loaders or boot managers are installed, each may have its own BOOT.CSV—but see below for some caveats. The more complex setup might look like this:
EFI/
BOOT/
BOOTX64.EFI — really Shim
fbx64.efi
refind/
BOOT.CSV — references shimx64.efi
shimx64.efi
grubx64.efi — really rEFInd
(additional rEFInd support files)
ubuntu/
BOOT.CSV — references shimx64.efi
shimx64.efi
grubx64.efi
(additional GRUB support files)
One key point is that BOOT.CSV must be a UCS-2 or UTF-16 file. Most Linux (and Windows and macOS) text editors create ASCII files by default. You can use iconv to convert to an appropriate format. For instance, suppose you have an ASCII file called boot.csv in your home directory and you want to write it to /boot/efi/EFI/refind as a UCS-2 file. You could do so in two steps as follows:
$ iconv -t UCS-2 < ~/boot.csv > ~/BOOT.CSV $ sudo cp ~/BOOT.CSV /boot/efi/EFI/refind/
Depending on permissions on your ESP and the account you use, you could do the same thing in a single step by writing directly to the ESP.
Many Linux distributions now set up fallback.efi and BOOT.CSV files in such a way that, if the NVRAM entries are all lost, fallback.efi will run to re-create the entries. Thus, ideally you won't even know that a problem existed and has been corrected. The point of this page is to enable you to set up fallback.efi yourself if your distribution doesn't, and to give you enough information to manage the situation if your distribution has set it up but something you don't expect or want happens as a result....
If you install a typical Linux distribution that installs GRUB 2, and if it sets up fallback.efi, and if you then install another boot manager or boot loader to take priority over GRUB 2, and if your NVRAM entries are then lost, chances are the system will boot to GRUB 2 when you try to boot again. This can be frustrating.
One solution is to create a BOOT.CSV file in the directory of your preferred boot loader or boot manager. This should cause fallback.efi to create an entry for your preferred program, as well as for GRUB 2. The trouble is that fallback.efi provides no way to specify the order of boot entries, so the one that's set to launch first is effectively random. Thus, with two boot loaders, there's a 50% chance that the one you want will be launched. With more boot loaders, the odds of your preferred program being launched go down.
To deal with this problem, you may want to delete the BOOT.CSV files of your non-preferred boot loaders; however, automatic package updates may restore these files. Deleting them also means that they won't be available in the event of a more serious problem that involves your preferred boot program failing in some way that's unrelated to its NVRAM entry. Thus, unless you have a recurring problem, you might prefer to permit one boot through your non-preferred tool and then use efibootmgr to restore your preferred program as the default boot program. (If you use rEFInd, its refind-mkdefault script will do this automatically.)
Another option is to delete fallback.efi from EFI/BOOT, and instead move your preferred boot program to that location using the fallback filename of bootx64.efi (or the equivalent for non-x86-64 architectures). This approach is described toward the end of EFI Boot Loader Installation. As a general rule, I recommend this approach only if your EFI is flaky—if you lose your boot loader entry on a regular basis. It has the disadvantage that OS installers and utilities may assume they can do what they like with the files in this location, so you might lose your preferred boot program when installing a new OS or performing maintenance or system upgrades.
Go on to "Dealing with Secure Boot"
Return to "Managing EFI Boot Loaders for Linux" main page
copyright © 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.