diff -Nru refind-0.12.0/BUILDING.txt refind-0.13.2/BUILDING.txt
--- refind-0.12.0/BUILDING.txt 2020-02-13 03:28:13.000000000 +0000
+++ refind-0.13.2/BUILDING.txt 2021-02-27 04:01:39.000000000 +0000
@@ -1,3 +1,14 @@
+NOTE
+====
+
+The rEFInd Makefiles are complex, in order to support building in three ways
+(described shortly). As a consequence (and, likely, because I'm not exactly
+a Makefile guru), tracking of header files is basically non-existent.
+Therefore, if you use git to update to a later version of rEFInd, you should
+do a "make clean" before building a new version of rEFInd, to be sure any
+changed data structures are cleanly applied to all the object files that use
+them.
+
Requirements
============
@@ -23,10 +34,15 @@
"frozen" forms (UDK2014, UDK2017, UDK2018, and so on); however, the term
"EDK2" is often used in reference to the TianoCore toolkit generally. To
simplify matters, I officially support only one UDK version at any given
- moment. Currently (rEFInd 0.11.3), this version is UDK2018; however, I
- used UDK2017 for rEFInd 0.10.9 through 0.11.2, and UDK2014 unofficially
- works via a different build procedure (see below), which is now
- deprecated.
+ moment. Currently (rEFInd 0.12.1), this version is UDK2018; however, I
+ used UDK2017 for rEFInd 0.10.9 through 0.11.2, and UDK2014 may
+ unofficially work via a different build procedure (see below), which is
+ now deprecated. (This build process is broken with Ubuntu 20.04 and GCC
+ 9.3.) The UDK2018 version I use is available from
+ https://github.com/tianocore/tianocore.github.io/wiki/UDK2018. I tried a
+ newer version in February of 2021 (edk2-edk2-stable202011), but it
+ failed to compile because of the removal of in-tree libraries and other
+ problems.
* The GNU-EFI package (http://sourceforge.net/projects/gnu-efi/). You can
install this from a package called "gnu-efi"; however, rEFInd relies on
@@ -39,18 +55,29 @@
a package manager. If you install from source code, you may need to
adjust those Makefiles' paths.
-Of the two toolkits, I prefer to use TianoCore because it produces binaries
-that are about 5-30KiB smaller than those made by GNU-EFI, and I can easily
-build 32-bit binaries on my 64-bit Linux installations. Also, I've had
-problems on a 32-bit Mac Mini with the drivers produced by GNU-EFI hanging
-the system. (I haven't encountered this problem on UEFI-based PCs.) That
-said, the TianoCore EDK2 package is much harder to install, so you may
-prefer to use GNU-EFI unless you have a specific need for the TianoCore
-toolkit. Also, somewhere between GCC 5.4 and 7.3, problems have appeared
-that prevent compiling the i386/IA32 binaries via TianoCore. Automated build
-tools like the OpenSUSE Build Service (OBS) and the Ubuntu Personal Package
-Archive (PPA) mechanism don't yet support TianoCore.
-
+Of the two toolkits, I recommend using GNU-EFI if you're compiling for your
+native architecture (e.g., X64 on an X64/x86-64/AMD64 system). GNU-EFI is
+*MUCH* easier to install, particularly if you're using an unsupported
+version of TianoCore -- the TianoCore developers keep making changes that
+break its ability to compile; and even the procedures I document here can
+break on distributions other than what I use -- Ubuntu 20.04, currently. (I
+suspect the TianoCore developers are trying to support too many build
+platforms.). In the past, TianoCore-based rEFInd binaries supported some
+features didn't work when building with GNU-EFI; but these GNU-EFI
+limitations have long been in the past. Because GNU-EFI is a standard part
+of most Linux distributions but TianoCore's EDK2 is not, binaries built for
+most distributions and in archives like my own Ubuntu PPA for rEFInd are
+built with GNU-EFI. TianoCore still has some advantages, though. One of
+these is that cross-compiling with it is easier (if you can get the
+TianoCore package to build). For this reason, I use it to build my binary
+.zip files, since I can build the X64, IA32, and AARCH64 binaries on one
+computer. Also, I've had problems on a 32-bit Mac Mini with the drivers
+produced by GNU-EFI hanging the system. (I haven't encountered this problem
+on UEFI-based PCs.) The TianoCore EDK2 is also usable on a wide variety of
+OSes, including macOS and Windows, so you might be able to get rEFInd to
+compile on these OSes using TianoCore, although I do not provide support for
+such attempts. (The upcoming section, "Compiling rEFInd Under MacOS," does
+provide some pointers, though.)
Preparing Your Development Kit
==============================
@@ -134,7 +161,7 @@
- TARGET_ARCH = X64 (on x86-64; leave this as IA32 on x86 or change it
to AARCH64 on ARM64). If you plan to build multiple architectures,
you can set this to "IA32 X64" or some other combination.
- - TOOL_CHAIN_TAG = GCC49 (or other value depending on your GCC version;
+ - TOOL_CHAIN_TAG = GCC5 (or other value depending on your GCC version;
type "gcc -v" to learn your GCC version number). Note that support
for the latest GCC version takes a while to make it into the
TianoCore toolkit, so if you're using a very recent GCC, you may need
@@ -151,8 +178,8 @@
6. The documentation refers to editing Conf/tools_def.txt in addition to
Conf/target.txt, but doesn't specify what to change in
- Conf/tools_def.txt. I haven't found it necessary to make any changes in
- Conf/tools_def.txt EXCEPT for two cases:
+ Conf/tools_def.txt. Some of the changes I've needed to make in various
+ build environments include:
* When using GCC 4.7 on a Fedora 17 system with the original UDK2014,
GCC 4.7 was newer than the most recent GCC that TianoCore supported at
@@ -172,11 +199,26 @@
*_GCC49_AARCH64_CC_PATH = /usr/bin/aarch64-linux-gnu-gcc
Similar changes for other variables in the same block are necessary.
-7. Type "make -C BaseTools/Source/C". (This step is not documented on the
+ * When compiling for x86 (IA32) on an x86-64 system running Ubuntu
+ 20.04, I needed to add "-fno-pie -fno-pic" to the GCC5_IA32_CC_FLAGS
+ definition. (At this time, TianoCore's UDK2018 and November 2020
+ snapshots' GCC definitions maxed out at GCC5, but Ubuntu 20.04 shipped
+ with GCC 9.3.)
+
+ * When compiling for ARM64 (AARCH64) on an x86-64 system running
+ Ubuntu 20.04, I needed to add "-fno-unwind-tables" to the
+ GCC5_AARCH64_CC_FLAGS definition.
+
+7. You may need to remove "-Werror" from two locations in
+ BaseTools/Source/C/Makefiles/header.makefile. I found this to be
+ necessary under Ubuntu 20.04 (using GCC 9.3), but not under Ubuntu 18.04
+ (using GCC 7.5).
+
+8. Type "make -C BaseTools/Source/C". (This step is not documented on the
EDK Web page.) Note that this requires the g++ compiler and UUID
development libraries.
-8. Type "build" to build the main set of EDK2 files. This process is
+9. Type "build" to build the main set of EDK2 files. This process is
likely to take a few minutes. This step requires Python 2; if you have
Python 3 installed, you may need to adjust the default python for this
build (for instance, by typing "eselect python set python2.7" in
@@ -222,13 +264,12 @@
"gptsync_ia32.efi", "gptsync_x64.efi", or "gptsync_aa64.efi" program
file, in the "gptsync" subdirectory. If you want to build IA32 binaries
on an x86-64 (X64) system and if you're using TianoCore, type "ARCH=ia32
- make". (As noted earlier, this facility broke somewhere between GCC 5.4
- and GCC 7.3.) Similarly, you can specify "ARCH=aarch64" to cross-compile
- for ARM64, but this works only if you're using the TianoCore build kit,
- and only if you set up TianoCore for cross-compiling. If you plan to
- build multiple architectures, be sure to copy the .efi file for the first
- build out of the refind subdirectory and type "make clean" before
- building the second architecture.
+ make". Similarly, you can specify "ARCH=aarch64" to cross-compile for
+ ARM64, but this works only if you're using the TianoCore build kit, and
+ only if you set up TianoCore for cross-compiling. If you plan to build
+ multiple architectures, be sure to copy the .efi file for the first build
+ out of the refind subdirectory and type "make clean" before building the
+ second architecture.
The top-level rEFInd Makefile supports three toolchains, each of which
provides several options to compile a subset of rEFInd's programs. (Note
@@ -243,14 +284,16 @@
GNU-EFI toolkit.
* all_gnuefi -- This target builds everything (refind_x64.efi,
gptsync_x64.efi, and the filesystem drivers) with the GNU-EFI toolkit.
-* tiano -- This deprecated target builds refind_x64.efi and gptsync_x64.efi
- with the TianoCore toolkit by using custom Makefile rules, bypassing the
- TianoCore toolkit's "build" command. The result is slightly faster
- compilation in a more traditional Unix/Linux way; but the compilation
- rules are fragile and work only with the UDK2014 toolkit. Also, the
- gptsync_x64.efi program is not built on ARM64/AARCH64 because the build
- process fails. (As hybrid MBRs are likely to be useless on this platform,
- the inability to build gptsync_aa64.efi is no great loss.)
+* tiano -- This deprecated, and increasingly unreliable, target builds
+ refind_x64.efi and gptsync_x64.efi with the TianoCore toolkit by using
+ custom Makefile rules, bypassing the TianoCore toolkit's "build" command.
+ The result is slightly faster compilation in a more traditional Unix/Linux
+ way; but the compilation rules are fragile and work only with the UDK2014
+ toolkit. They worked with Ubuntu 18.04 and GCC 7.5, but now fail with
+ Ubuntu 20.04 and GCC 9.3. Also, the gptsync_x64.efi program is not built
+ on ARM64/AARCH64 because the build process fails. (As hybrid MBRs are
+ likely to be useless on this platform, the inability to build
+ gptsync_aa64.efi is no great loss.)
* gptsync_tiano -- This target works like the preceding one, but builds
only gptsync_x64.efi.
* fs_tiano -- This target works like the preceding two, but builds the
@@ -260,21 +303,23 @@
* edk2 -- Like the "tiano" target, this one builds with the TianoCore
toolkit; but it employs a build method more like that favored by
TianoCore. It relies on .dsc, .dec, and .inf files as well as the "build"
- program that comes with TianoCore. This method works with UDK2014,
- UDK2018, and the latest (as of July, 2017) EDK2 snapshot. It also works
- under OS X, if TianoCore is properly prepared. One limitation is that
- building with UDK2014 for ARM64/AARCH64 requires modifying the .inf files
- to remove the reference to CompilerIntrinsicsLib. This build method is
- also a little bit slower than the preceding ones, in part because
- EVERYTHING is built; narrower targets simply copy fewer of the resulting
- files from within the TianoCore directory tree. Note that this method,
- unlike the preceding ones, requires WRITE access to the TianoCore build
- tree, or at least to the Build and Conf subdirectories of that tree, as
- well as to the root of the tree. (This method creates a symbolic link of
- the main rEFInd directory into the root of the TianoCore tree, and the
- build process creates a subdirectory called Build/Refind to hold temporary
- files and the final .efi files. The "make" utility then copies these files
- to the same locations used by the tiano and gnuefi targets.)
+ program that comes with TianoCore. This method works with UDK2014 and
+ UDK2018. It might work with more recent EDK2 snapshots, but as noted
+ earlier, my attempt to use a November 2020 snapshot failed because I
+ couldn't get it to compile. This method also works under macOS, if
+ TianoCore is properly prepared. One limitation is that building with
+ UDK2014 for ARM64/AARCH64 requires modifying the .inf files to remove the
+ reference to CompilerIntrinsicsLib. This build method is also a little bit
+ slower than the preceding ones, in part because EVERYTHING is built;
+ narrower targets simply copy fewer of the resulting files from within the
+ TianoCore directory tree. Note that this method, unlike the preceding
+ ones, requires WRITE access to the TianoCore build tree, or at least to
+ the Build and Conf subdirectories of that tree, as well as to the root of
+ the tree. (This method creates a symbolic link of the main rEFInd
+ directory into the root of the TianoCore tree, and the build process
+ creates a subdirectory called Build/Refind to hold temporary files and the
+ final .efi files. The "make" utility then copies these files to the same
+ locations used by the tiano and gnuefi targets.)
* gptsync_edk2 -- This target copies just the gptsync_x64.efi binary to its
final destination.
* fs_edk2 -- This target works like the "edk2" target, but copies only
@@ -350,9 +395,9 @@
"build" command. rEFInd can be compiled in this way. I am providing
instructions on compiling in this way because it may work better than
rEFInd's Makefiles in some cases, especially if you're using a non-Linux
-platform for development. I've successfully compiled rEFInd 0.10.8 under OS
-X in this way. (I present details and caveats shortly.) Note that the "edk2"
-and related Makefile targets use this method behind the scenes. The
+platform for development. I've successfully compiled rEFInd 0.10.8 under
+macOS in this way. (I present details and caveats shortly.) Note that the
+"edk2" and related Makefile targets use this method behind the scenes. The
procedure is:
1. Download and prepare the TianoCore toolkit, as described earlier,
@@ -401,18 +446,18 @@
Build/Refind/RELEASE_GCC49/X64/refind.efi
Build/Refind/RELEASE_GCC49/X64/reiserfs.efi
-I've tested this procedure under Ubuntu 16.04 with GCC 5.4.0 and under OS X
+I've tested this procedure under Ubuntu 16.04 with GCC 5.4.0 and under macOS
10.11 with both Clang 7.0.0/XCode 7.1.1 and Clang 8.0.0/XCode 8.1.1. (See
below for Mac caveats.) In theory, it might work under Windows, but if you
use anything but a GCC- or Clang-derived compiler, there's a good chance
you'll run into a compiler-specific code incompatibility.
-Compiling rEFInd Under OS X
-===========================
+Compiling rEFInd Under MacOS
+============================
-Building under OS X is *NOT SUPPORTED.* I've tested this procedure and it
-seems to work in minimal testing. My build under OS X required several
+Building under macOS is *NOT SUPPORTED.* I've tested this procedure and it
+seems to work in minimal testing. My build under macOS required several
changes for compilation to succeed:
* A relatively recent TianoCore EDK2 from the TianoCore git repository is
@@ -436,7 +481,7 @@
prevented the rEFInd binary from compiling with "-Werror" intact related
to ((sysv_abi)) declarations in mok/mok.h. This makes me think that the
resulting binary may be incompatible with Shim, although I've not tested
- this; my only testing of the binary built under OS X were on systems with
+ this; my only testing of the binary built under macOS were on systems with
Secure Boot disabled or with the Secure Boot system under my complete
control and without Shim installed.
@@ -445,7 +490,8 @@
* I've been unable to get the Btrfs driver to build. To adjust the package
to omit this driver, edit the RefindPkg.dsc file and remove the line near
- the bottom that reads "RefindPkg/filesystems/btrfs.inf".
+ the bottom that reads "RefindPkg/filesystems/btrfs.inf". (This limitation
+ may be resolved with rEFInd 0.12.1, but I haven't tested it.)
Note that if you want to use macOS or Windows to compile rEFInd, you might
be able to create a project or Makefile for your non-GCC compiler or use a
@@ -477,7 +523,7 @@
* Copy the icons subdirectory, including all its files, to EFI/refind.
You'll then need to activate rEFInd in your EFI. This can be done with
-tools such as "efibootmgr" under Linux or "bless" under OS X. See the
+tools such as "efibootmgr" under Linux or "bless" under macOS. See the
docs/refind/installing.html file for details.
diff -Nru refind-0.12.0/debian/changelog refind-0.13.2/debian/changelog
--- refind-0.12.0/debian/changelog 2020-07-22 21:00:56.000000000 +0000
+++ refind-0.13.2/debian/changelog 2021-10-25 22:44:40.000000000 +0000
@@ -1,3 +1,17 @@
+refind (0.13.2-1) unstable; urgency=medium
+
+ [ Debian Janitor ]
+ * Remove constraints unnecessary since stretch:
+ + Build-Depends: Drop versioned constraint on debhelper.
+
+ [ Tianon Gravi ]
+ * Update to 0.13.2 upstream release
+ - see http://www.rodsbooks.com/refind/revisions.html for changes
+ - "Updated CentOS Secure Boot (MOK) keys" (Closes: #958744)
+ * Backport "gnu-efi" fix (Closes: #995623)
+
+ -- Tianon Gravi
Originally written: 4/24/2016; last Web page update: -3/13/2020, referencing rEFInd 0.12.0
+3/13/2021, referencing rEFInd 0.13.2This 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!
@@ -180,7 +180,7 @@This page describes tools and techniques you can use to keep rEFInd set as your default boot manager, or at least to recover it as the default boot option if something else takes over. This page is organized by OS, describing the tools and techniques you can use in each OS to recover from a boot coup—or in some cases, to prevent one from occurring. I begin and end with information on firmware-based tools, though. Chances are you should not read this page straight through; instead, peruse the Contents to the left and pick an OS and, perhaps, a recovery tool or technique you wish to pursue and read the relevant section. In most cases, the recovery technique is fairly quick and painless, once you understand how to do it. Note also that, in extreme cases, a full rEFInd re-installation may be required. It may also be easier to re-run refind-install than to learn about esoteric commands such as efibootmgr, bless, or bcdedit.
-Most EFIs provide their own built-in boot managers. These tools are primitive, and in some cases they can be difficult to reach, but they can be useful if you need to bypass a new system default in order to boot an OS that has the tools you need to control the boot process.
@@ -332,7 +332,9 @@The Startup Disk utility appears in the System Preferences tool. Unfortunately, it will likely be useless if you installed rEFInd using refind-install and its default options, since Startup Disk is designed to switch between macOS installations; it's not smart enough to detect a rEFInd installation and re-activate it.
-If, however, you installed rEFInd by using the --ownhfs option to refind-install, your rEFInd installation volume should show up as an option in the Startup Disk utility. You should be able to click on it and then click Restart. Note that the name of the rEFInd volume may not be rEFInd, as it is in this screen shot; the name will match whatever volume holds rEFInd on your computer.
+ + +If, however, you installed rEFInd by using the --ownhfs option to refind-install, your rEFInd installation volume may show up as an option in the Startup Disk utility. You should be able to click on it and then click Restart. Note that the name of the rEFInd volume may not be rEFInd, as it is in this screen shot; the name will match whatever volume holds rEFInd on your computer.
The more general solution to resetting rEFInd as the default boot manager from macOS is to follow a subset of the manual macOS installation instructions. Unfortunately, some details depend on where rEFInd is installed—on the ESP, on the main macOS root (/) partition, or on a separate HFS+ volume. If rEFInd is installed on its own HFS+ partition, using Startup Disk, as described in the previous section, is likely to be the easier solution—if that approach works for you. For the other two options, or for a dedicated HFS+ installation if Startup Disk balks at making it bootable, you should first figure out where rEFInd is installed and then follow this procedure:
The list provides up to four pices of information about each boot entry: its boot number (such as Boot0004; its description (such as rEFInd Boot Manager, its filename (such as EFI\refind\refind_x64.efi, and its volume name (such as ESP). Sometimes one or more of these pieces of information can be missing. In the preceding example, for instance, the final four items on the list lack filenames and volume names. (This is common for entries created by the firmware for its own hardware devices.) If you can't figure out which entry you want to delete or elevate to the first position, I recommend booting into Linux or Windows and using efibootmgr or the commercial EasyUEFI, respectively.
+The list provides up to four pices of information about each boot entry: its boot number (such as Boot0004); its description (such as rEFInd Boot Manager); its filename (such as EFI\refind\refind_x64.efi); and its volume name (such as ESP). Sometimes one or more of these pieces of information can be missing. In the preceding example, for instance, the final four items on the list lack filenames and volume names. (This is common for entries created by the firmware for its own hardware devices.) If you can't figure out which entry you want to delete or elevate to the first position, I recommend booting into Linux or Windows and using efibootmgr or the commercial EasyUEFI, respectively.
-You can use the arrow keys to move up and down in the list to select a boot entry. Once you've picked an option, you can perform either of three actions from this menu:
+You can use the arrow keys to move up and down in the list to select a boot entry. Once you've picked an option, you can perform any of three actions from this menu:
rEFInd's EFI boot maintenance tool does not enable you to fine-tune the order of multiple items all at once. You can do so by making repeated calls to the program, however. For instance, to convert the entries shown earlier to a boot order of 0006, 0005, 0004, you would call the function twice — once to move 0005 to the top of the list and then to move 0006 there.
+rEFInd's EFI boot maintenance tool does not enable you to fine-tune the order of multiple items all at once. You can do so by making repeated calls to the feature, however. For instance, to convert the entries shown earlier to a boot order of 0006, 0005, 0004, you would call the function twice — once to move 0005 to the top of the list and then to move 0006 there.
As with most of the fixes described on this page, this method of recovering from a boot coup will not protect you from future boot coups. Preparing a USB flash drive or CD-R with rEFInd on it can help you when boot coups occur, though, especially if the boot coup corrupts your boot list so that you can't start rEFInd. If you can boot from the external medium, you can use it to launch rEFInd and adjust the boot order, or even completely re-install rEFInd from the external disk.
@@ -500,13 +502,29 @@This procedure is only an example for one EFI. In fact, some EFIs, including the one in the ASUS P8 H77-I, feature multiple user interface modes. The ASUS has an "Advanced" mode, for instance, in which the procedure would be slightly different. They key point, though, is to locate whatever menu displays the boot order and use that menu to adjust it. Such a menu may be shown on the main screen, as in the case of the ASUS' "EZ-Mode," or on a menu you must select—often called "Boot" or something similar. Some EFIs, particularly for low-end fully-assembled desktop and laptop computers, lack this functionality altogether.
-As with most other fixes described on this page, this one won't protect you from future boot coups. Most boot coups are caused by actions of an OS, so prevention must be handled on an OS-by-OS basis.
+One other example (documented in more detail by Macworld) deserves mention. On many (maybe all) Intel-based Macs, you can adjust the boot order as follows:
+ +This Mac-specific procedure presents only a limited selection of options. In particular, it will show macOS, bootable removable disks, and rEFInd installed to a dedicated HFS+ partition via the refind-install --ownhfs procedure; but it will not show rEFInd (or other boot programs) installed to the ESP, even if those options have EFI boot entries. Thus, it may not do what you need; but if you install rEFInd to an HFS+ volume, this procedure could be a useful tool for recovering from a boot coup.
+ +As with most other fixes described on this page, recovering from a boot coup using your firmware's setup tools won't protect you from future boot coups. Most boot coups are caused by actions of an OS, so prevention must be handled on an OS-by-OS basis.
Version 2 of the EFI shell provides a command, bcfg, which can adjust the EFI boot order. Unfortunately, this tool is not present in version 1 of the EFI shell, and version 2 is reliable only with EFI version 2.3 and later, although at least one binary claims to work around that problem. To date (early 2020), all Intel-based Macs use EFI 1.1, and many PCs sold prior to Windows 8's release use UEFI (EFI 2.x) versions prior to 2.3. Thus, this approach may not work for you.
+Version 2 of the EFI shell provides a command, bcfg, which can adjust the EFI boot order. Unfortunately, this tool is not present in version 1 of the EFI shell, and version 2 is reliable only with EFI version 2.3 and later, although at least one binary claims to work around that problem. To date (early 2021), most Intel-based Macs use EFI 1.1 (although some newer Intel-based Macs now have UEFI [EFI 2.x] firmware), and many PCs sold prior to Windows 8's release use UEFI versions prior to 2.3. Thus, this approach may not work for you.
Even if your computer works with a version 2 shell, it may not have one built in. In fact, most EFIs I've seen lack a built-in shell. If a shell is available, it should appear on the EFI's built-in boot manager, as described earlier, in Evading the Guards: Performing a One-Time Boot to Your Desired OS. If a shell is not built into your firmware, you can add one; here are a couple of links that may be helpful:
@@ -564,10 +582,10 @@Because of the complexity of the procedure for starting an EFI shell if one is not already prepared, this procedure works best if one is built into your EFI or if you already have one ready.
-If your computer simply refuses to boot into rEFInd, chances are your firmware is either ignoring its boot entries or forgetting them. For the most part, which is the case doesn't really matter, since the solutions are similar for both cases. There are a few obscure exceptions, though; for instance, an entry will be ignored if it's malformed—such as if the filename specification includes a typo. Also, there is at least one known bug that causes the computer to ignore boot loader entries except for those named "Windows Boot Manager" or "Red Hat Enterprise Linux." Such problems can be fixed by creating a fresh NVRAM entry for rEFInd that fix the typo or give the entry the name that the EFI expects (even if it's a misleading name).
+If your computer simply refuses to boot into rEFInd, chances are your firmware is either ignoring its boot entries or forgetting them. For the most part, which is the case doesn't really matter, since the solutions are similar for both cases. There are a few exceptions, though; for instance, an entry will be ignored if it's malformed—such as if the filename specification includes a typo. Also, there is at least one known bug that causes the computer to ignore boot loader entries except for those named "Windows Boot Manager" or "Red Hat Enterprise Linux." Such problems can be fixed by creating a fresh NVRAM entry for rEFInd that fix the typo or give the entry the name that the EFI expects (even if it's a misleading name).
More common are problems in which the firmware ignores or forgets its boot entries. Such problems used to be quite common, but are becoming rarer as manufacturers (slowly) improve their products. My general advice for fixing such problems is to attempt each of the following, in more-or-less the stated order:
@@ -581,7 +599,7 @@Another thing that can produce symptoms similar to a persistent boot coup is Secure Boot. If Secure Boot is enabled on your computer and you install rEFInd without a Shim or PreLoader program, your computer will probably refuse to launch rEFInd. In this case, inserting Shim or PreLoader into the boot process, as described on the rEFInd Secure Boot page, normally overcomes this problem. On rare occasions, though, Shim or PreLoader won't work with a particular computer. In such a case, you may need to disable Secure Boot. Note that this level of Secure Boot malfunction is quite rare. I see many posts in online forums that jump to the conclusion that Secure Boot is causing a problem, when in fact there's another more likely cause. Thus, I urge you to investigate other possibilities before concluding that Secure Boot is causing an inability to boot rEFInd.
-One type of boot problem is similar to a boot coup, but has a unique cause: Some EFIs, especially older ones (mostly from 2012 or earlier) have a tendency to forget their NVRAM entries. Such computers boot from the fallback boot loader (EFI/BOOT/bootx64.efi) or from the Microsoft boot loader (EFI/Microsoft/Boot/bootmgfw.efi), but that's about it. A similar problem is that some computers remove invalid boot entries from their boot lists. This is helpful if you delete a boot loader, but it's less than helpful if you temporarily unplug your boot disk and then plug it back in.
-In either of these cases, your computer may boot to an unwanted OS or completely fail to boot. One solution to this problem is to install rEFInd to the fallback filename, as described earlier, in The Unstable State: Dealing With Persistent Boot Coups. Another is to use an EFI program called fallback.efi, fbx64.efi, or an equivalent filename on other platforms. To use this program, you would install it to EFI/BOOT on the ESP, either renaming it to bootx64.efi (that is, fallback.efi uses the fallback filename) or installing Shim as bootx64.efi. Shim will try to launch fallback.efi or fbx64.efi when it boots, so either way, this program will launch. (Be sure to match your Shim and fallback.efi/fbx864.efi binaries, so that Shim launches the correct program!) For simplicity, I call this program fallback.efi hereafter.
+In either of these cases, your computer may boot to an unwanted OS or completely fail to boot. One solution to this problem is to install rEFInd to the fallback filename, as described earlier, in The Unstable State: Dealing With Persistent Boot Coups. Another is to use an EFI program called fallback.efi, fbx64.efi, or an equivalent filename on other platforms. To use this program, you would install it to EFI/BOOT on the ESP, either renaming it to bootx64.efi (that is, fallback.efi uses the fallback filename) or installing Shim as bootx64.efi. Shim will try to launch fallback.efi or fbx64.efi when it boots, so either way, this program will launch. (Be sure to match your Shim and fallback.efi/fbx64.efi binaries, so that Shim launches the correct program!) For simplicity, I call this program fallback.efi hereafter.
-When fallback.efi launches, it reads every subdirectory of EFI on the ESP except for EFI/BOOT and looks for a file called BOOT.CSV. If this file exists and contains a UCS-2 (UTF-16 also seems to work) text file, that file is read and used to create a new NVRAM boot variable. The format of BOOT.CSV is simple; it consists of one or more lines, each of which consists of four comma-separated fields:
+When fallback.efi launches, it reads every subdirectory of EFI on the ESP except for EFI/BOOT and looks for a file called BOOT.CSV, BOOTX64.CSV, or file with a similar but architecture-appropriate name. If this file exists and contains a UCS-2 (UTF-16 also seems to work) text file, that file is read and used to create a new NVRAM boot variable. The format of BOOT.CSV is simple; it consists of one or more lines, each of which consists of four comma-separated fields:
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.
-Note that fallback.efi can create boot coups, in addition to fixing them. If it's run inappropriately, this program can modify your NVRAM-based boot list, causing something you don't want to run to become the default boot loader. Thus, if you're experiencing boot coups, you may want to check for the presence of this program and either delete it or adjust the BOOT.CSV files on your ESP. You can find all the BOOT.CSV files as follows, assuming the ESP is mounted at /boot/efi:
+Note that fallback.efi can create boot coups, in addition to fixing them. If it's run inappropriately, this program can modify your NVRAM-based boot list, causing something you don't want to run to become the default boot loader. Thus, if you're experiencing boot coups, you may want to check for the presence of this program and either delete it or adjust the BOOT.CSV files on your ESP. You can find all the BOOT.CSV (and similarly-named) files as follows, assuming the ESP is mounted at /boot/efi:
-$ find /boot/efi -iname BOOT.CSV+
$ find /boot/efi -iname "BOOT*.CSV"
By default, Fedora and its relatives install fallback.efi in the fallback position (typically launched by Shim, actually) and set up a @@ -654,7 +672,7 @@
copyright © 2016–2020 by Roderick W. Smith
+copyright © 2016–2021 by Roderick W. Smith
This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.
diff -Nru refind-0.12.0/docs/refind/bootmode.html refind-0.13.2/docs/refind/bootmode.html --- refind-0.12.0/docs/refind/bootmode.html 2020-03-13 12:46:26.000000000 +0000 +++ refind-0.13.2/docs/refind/bootmode.html 2021-03-14 00:01:57.000000000 +0000 @@ -17,7 +17,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.comOriginally written: 3/14/2012; last Web page update: -3/13/2020, referencing rEFInd 0.12.0
+3/13/2021, referencing rEFInd 0.13.2This 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!
@@ -153,12 +153,14 @@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, and rEFInd can't be used with them. If your computer shipped new with Windows 8 or later, it almost certainly supports EFI; Microsoft requires that 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.
+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."
-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, 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:
+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:
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 a Mac is an exception to this rule, though.) For that, you'll need to run some tests in your running OSes.
+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.
copyright © 2012–2020 by Roderick W. Smith
+copyright © 2012–2021 by Roderick W. Smith
This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.
@@ -282,7 +284,7 @@ - +Return to my main Web page.