[multiboot-guide] master: Move boot process to UEFI-general. Continue edit on UEFI-win. (fb30259)
immanetize at fedoraproject.org
immanetize at fedoraproject.org
Tue Jan 6 03:39:08 UTC 2015
Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit fb302598ea8c82c1b0a407b3b65007f4377c7a2e
Author: Roger Baran <rapidrecoveryit at gmail.com>
Date: Thu Oct 2 18:17:50 2014 -0500
Move boot process to UEFI-general. Continue edit on UEFI-win.
>---------------------------------------------------------------
en-US/UEFI-general.xml | 125 ++++++++++++++++++++++-
en-US/UEFI-win.xml | 270 ++++++++++++++++++------------------------------
2 files changed, 226 insertions(+), 169 deletions(-)
diff --git a/en-US/UEFI-general.xml b/en-US/UEFI-general.xml
index 9d7058f..388084c 100644
--- a/en-US/UEFI-general.xml
+++ b/en-US/UEFI-general.xml
@@ -6,5 +6,128 @@
]>
<section id="UEFI-general">
<title>UEFI Basics</title>
- <para />
+ <para>
+ This section of the guide covers the UEFI boot process in general and how Fedora successfully handles a Secure Boot environment.
+ </para>
+ <para>
+ We hope that you will find this information both interesting and helpful. With the information outlined in this and other sections of this guide, you will have a better understanding of what is happening 'behind the scenes'. That should prove useful when it comes time to work your way through troubleshooting a particular issue related to booting using UEFI. This guide represents our best effort at explaining a very technical and difficult to understand specification in terms that everyone can understand. For this reason, some parts of the explanation have been over-simplified for ease in understanding the overall concept or process that is taking place. For those that desire more information that what is available in this article, extensive information about UEFI is available here <ulink url="http://www.uefidk.com/learn" /> and here <ulink url="http://www.uefi.org/" />
+ </para>
</section>
+<section id="EFI_Boot_Explained">
+ <title>EFI Boot Sequence Explained</title>
+ <para>
+ In this section we will consider two scenarios:
+ <orderedlist>
+ <listitem>
+ <para>
+ How EFI handles a normal boot cycle - no intervention.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ What happens when you press the appropriate key to enter the EFI Settings prior to a successful boot of an operating system.
+ </para>
+ </listitem>
+ </orderedlist></para><para>
+ First, EFI attempts each entry in the order listed in its BootOrder variable.
+ It will boot the first entry that 'works' with the data listed for that entry.
+ A typical entry is in the format of:
+ ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(1,800,64000,12029cda-8961-470d-82ba-aeb17dba91a5) File(\EFI\fedora\shim.efi)
+ </para><para>
+ The EFI Boot Manager begins the process of loading the file (end result) by initializing each preceeding device in order. Thus, in the example above, it starts by initializing ACPI(a0248d0,0) which then provides access to PCI(1d,2) which then provides access to SATA(0,0,0) etc..
+ EFI just goes down the line until it can load the file called for in that entry. If anything in that chain is broken or missing the boot fails.
+ If it cannot boot the first entry in the BootOrder list, it will go to the second, and failing there, will move on to the third entry, etc.
+ </para><para>
+ If it gets to the end of the BootOrder list and still has not been able to transfer execution, it will begin to initialize every device connected to the system (fixed and removable) and begins to look specifically for removable devices. Remember, this is what happens automatically -- its what happens if you do not go into the "EFI Settings" and thereby stop the process at the end of initial enumeration of all connected devices. By hitting the 'magic' key, you alter the sequence of events and are, in effect, "Skip the boot process for now and just enumerate everything connected to the motherboard." Full enumeration is not conducted until after the BootOrder sequence has been exhausted during normal boots. Right now, we are looking at what happens automatically if EFI cannot find a bootable device by traversing its BootOrder entries.
+ </para><para>
+ As EFI Boot Manger moves on to find a bootable, removable device, it looks for an EFI partition, formatted in Fat32, Fat16 or Fat12 with an \EFI\Boot\ directory structure and that bootx64.efi is in that directory.
+ </para><para>
+ When that file is found and loaded, execution is passed to it. In Fedora, that means that bootx64.efi is going to check for the presence of fallback.efi; and if it finds it, will pass execution to it. Fallback.efi will then enumerate all of the boot.csv's it can find in its own partition, create and append an entry for each one to the EFI NVRAM, change the NextBoot variable and pass execution back to the EFI for processing. Having a valid entry, EFI will boot to that device and hand over execution.
+ </para><para>
+ At some point, either grubx64.efi or the kernel itself will issue a command to EFI to terminate its boot support processes and standby for a reboot, standby, hibernate or power down command. In effect, we are saying to EFI: "Ok. We got it from here."
+ </para><para>
+ Ubuntu, for example, has chosen to make that call just prior to loading the kernel, while Fedora continues to use EFI support services until after the kernel has verified the signatures on all boot files; thus continuing the 'chain of trust' a little further.
+ </para><para>
+ In any event, EFI will boot to the first device it can either find on its own, or to the one its told to.
+</para><para>
+ When you enter the "EFI Settings" of your computer and look at the menu, all of that enumeration is complete before the menu is displayed. All you then have to do is select which device you wish to boot from and hit Enter.
+ </para>
+</section>
+ <section id="Default_Boot_Behavior">
+ <title>What is Default Boot Behavior?"</title>
+ <para>
+ Default Boot Behavior is an EFI process that is initiated when the EFI boot process cannot find a suitable boot manager or boot loader to pass execution to after traversing the BootOrder list.
+ </para><para>
+ It begins by enumerating all removable devices and then passing execution to the first instance of <filename>bootx64.efi</filename> it finds.
+ </para><para>
+ <filename>bootx64.efi</filename> uses <filename>fallback.efi</filename> to scan the entire EFI partition looking for <filename>boot.csv</filename> files in each sub-directory within the EFI partition. Everytime it finds one, <filename>fallback.efi</filename> creates and appends an entry in the EFI NVRAM. It then changes the BootNext variable to point to the first one it found. When finished, it directs execution back to EFI Boot Manager to boot using the NextBoot variable.
+ </para>
+ <para></para>
+</section>
+<section id="Default_Boot_Behavior.Fallback">
+ <title>"What is Fallback and How Does it Work?"</title>
+ <para>
+ The reason this process is referred to as "fallback" is because, as noted above, <filename>bootx64.efi</filename> checks to see if a file named <filename>fallback.efi</filename> is in the same directory as itself, and if so, will execute it as an EFI application.
+ </para><para>
+ It is the <filename>fallback.efi</filename> application that enumerates the various <filename>boot.csv</filename> files that it finds, creates and appends the EFI NVRAM entries, and finally, passes control back to the EFI Boot Manager to boot the first entry it created; which, as mentioned earlier, it does by changing the BootNext variable.
+ </para><para>
+ The Default Boot Behavior, which initiates fallback, happens in the event that any of the following conditions are met:
+</para>
+ <orderedlist>
+ <listitem>
+ <para>
+ There aren't any existing NVRAM entires for any installed operating systems</para>
+ </listitem><listitem>
+ <para>
+ That the entries that were listed in the BootOrder resulted in a 'no boot' situation from all installed, fixed devices
+ </para>
+ </listitem><listitem>
+ <para>
+ That your removable device settings in your EFI Boot Order Priority are such that removable devices (Live media, etc) are listed above your installed Operating Systems menu entries.
+</para>
+</listitem>
+ </orderedlist>
+ <para>
+ Before moving on, I would like to add a few notes to help clariy the above information:
+ </para>
+ <para>
+ One caveat to all that has been said about "Default Boot Behavior":
+ If you already have installed Operating Systems on your system that will boot normally, and you want to use "Default Boot Behavior" to boot your removable media, then please read on.
+ </para><para>
+ Your EFI implementation has to be 'compliant' and your EFI Boot Settings have to indicate that removable devices are higher in the list than your installed Operating Systems. This allows the EFI to find and boot the removable media (if inserted) prior to attempting to run down the normal BootOrder list.
+ </para><para>
+ IF that is the case, then "Default Boot Behavior" will occur on that removable device and it will boot.
+ </para><para>
+ IF the implementation of EFI on your system is not compliant it may never get to the point where it loads <filename>fallback.efi</filename> - it still might not boot.
+ </para><para>
+ The only way to know for sure, is to plug in a USB, boot using the 'magic' key to enter your EFI Settings, change your boot priorites in the EFI to put the inserted USB at the top of the list, save and exit. Leave in the USB and power on without pressing any keys. If it boots to the USB automatically then everything is working as it should. If it won't boot, and/or it is not showing up on the list of devices provided by the EFI Boot Manager, then check that the device has an \EFI\Boot directory with bootx64.efi and fallback.efi in it. If all of that is there, then either the USB is 'bad', the port you plugged it into is 'bad' (something in the device path is 'bad') or your EFI implementaton is non-compliant.
+ </para><para>
+ If you do not have any installed OS's on your system...
+ Just plug in removable media that meets the criteria for EFI "Default Boot Behavior" and turn it on.
+ </para>
+ <para>
+ Many of these concepts will become clear as you continue with the EFI Boot Sequence Explained below.
+ </para>
+</section>
+<!-- comment
+Refs:
+
+http://www.rodsbooks.com/efi-bootloaders/index.html
+http://www.solvusoft.com/en/files/error-missing-download/mui/windows/microsoft/windows-8-pro/bootmgfw-efi-mui/
+http://blog.hansenpartnership.com/uefi-secure-boot/
+http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm
+https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
+http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/
+http://nwrickert2.wordpress.com/2013/05/13/notes-on-uefi-windows-and-linux/
+https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
+http://www.uefidk.com/
+https://www.youtube.com/watch?v=eAnlhkbMang&list=PLk2sjg_-F-McRbCBoVRkP1sYMbmDf6zJM
+https://www.youtube.com/watch?v=ALzySqflHJw
+https://www.youtube.com/user/metalx1000/videos
+https://www.youtube.com/watch?v=tDREcY5EzTQ&list=PLXEcKYHTGBdQPSchdZV2UONYf3ve0DCJK
+https://www.youtube.com/watch?v=dRMIvY7BiL4
+https://www.youtube.com/watch?v=amwujljr7pY
+https://www.youtube.com/watch?v=35D0_feZnK8
+http://superuser.com/questions/376470/how-to-reinstall-grub2-efi
+https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System_Administrators_Guide/index.html#ch-Working_with_the_GRUB_2_Boot_Loader
+https://en.wikipedia.org/wiki/GNU_GRUB#GRUB_version_2 -->
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 8197152..00fc8bc 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -7,38 +7,122 @@
<section id="UEFI-win">
<title>Introduction</title>
<para>
- Fedora is a great choice for all aspects of multibooting your system using UEFI! Fedora has gone to great lengths to ensure that you can install it in many different environments; including desktops, laptops (with or without Secure Boot enabled) and Apple/Macintosh based computers.
+ Fedora is a great choice for all aspects of multibooting your system using UEFI! Fedora has gone to great lengths to ensure that you can install it on many different platforms and in several different environments; including desktops, laptops (with or without Secure Boot enabled) as well as Apple/Macintosh based computers.
</para>
<para>
- This article begins by covering the more general aspects of the Windows and Fedora UEFI boot process; such as the files involved, their purposes, and locations. The next few sections deal with the similarities and the differences in the UEFI boot process for both operating systems. From there, the UEFI boot process is explained in detail. The final section covers how Fedora successfully handles a Secure Boot environment.
+ This section of the Multiboot Guide begins by covering a few important definitions as well as the more general aspects of the Windows and Fedora UEFI boot process. Windows and Fedora specific boot files, their purposes, and locations are then listed. After that, the guide deal with the similarities and the differences in the UEFI boot process for both operating systems. The final section is how to use <filename>BCD</filename> to dual boot; but there are a few, very important caveats to doing that, and they are pointed out within that section.
</para><para>
- We hope that you will find this information both interesting and helpful. With the information outlined in this guide, you will have a better understanding of what is happening 'behind the scenes'. That should prove useful when it comes time to work your way through troubleshooting a particular issue related to booting using UEFI. This guide represents our best effort at explaining a very technical and difficult to understand specification in terms that everyone can understand. For this reason, some parts of the explanation have been over-simplified for ease in understanding the overall concept or process that is taking place. For those that desire more information that what is available in this article, extensive information about UEFI is available here <ulink url="http://www.uefidk.com/learn" /> and here <ulink url="http://www.uefi.org/" />
+ We hope that you will find this information both interesting and helpful. With the information outlined in this, and other, sections of this guide, you will have a better understanding of what is happening 'behind the scenes'. That should prove useful when it comes time to work your way through troubleshooting a particular issue related to booting using UEFI.
+ </para><para>
+ This guide represents our best effort at explaining a very technical and difficult to understand specification in terms that everyone can understand. For this reason, some parts of the explanation have been over-simplified for ease in understanding the overall concept or process that is taking place. For those that desire more information that what is available in this article, extensive information about UEFI is available here <ulink url="http://www.uefidk.com/learn" /> and here <ulink url="http://www.uefi.org/" />
</para>
<section id="Boot_Manager_vs_BootLoader">
<title>Boot Managers and Boot Loaders Defined</title>
<para>
- Boot Manager: A utility that allows multiple operating systems to be booted from the same computer
- Boot Loader: The program that calls the operating system into memory
- GRUB2 acts as both a Boot Manager and a Boot Loader
+ Knowing the difference between a Boot Manager and Boot Loader is a good start to understanding the UEFI boot process for both Windows and Fedora.
</para>
+ <orderedlist>
+ <listitem>
+ <para>
+ <literal>Boot Manager:</literal> A utility that allows multiple operating systems to be booted from the same computer
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>Boot Loader:</literal> The program that calls the operating system into memory
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>GRUB2</literal> acts as both a Boot Manager and a Boot Loader
+ </listitem>
+ </para>
+</orderedlist>
</section>
-<section id="Files_within_the_Microsoft_EFI_Partition">
- <title>Files within the Microsoft EFI Partition</title>
+<section id="Windows_EFI_Files">
+ <title>Windows EFI Partition Files</title>
<para>
- Microsoft uses <filename>bootmgr.efi</filename> and <filename>bootmgrfw.efi</filename> as boot managers; <filename>bootmgr.efi</filename> is the 32 bit version and <filename>bootmgrfw.efi</filename> is the 64 bit version. Both of these files are located in the root directory of the Microsoft-created EFI partition (usually found at <filename class="directory">/dev/sda1</filename>). For EFI compatibility, they are both located at <filename class="directory">/EFI/Microsoft/Boot/</filename> as well. These EFI applications then call <filename>winload.efi</filename> as the boot loader. <filename>winload.efi</filename> is located at <filename class="directory">/WINDOWS/System32/Boot</filename>.
+ Microsoft uses <filename>bootmgr.efi</filename> and <filename>bootmgrfw.efi</filename> as Boot Managers. <filename>bootmgr.efi</filename> is the 32 bit version and <filename>bootmgrfw.efi</filename> is the 64 bit version. Both of these files are located in the root directory of the Microsoft-created EFI partition (usually found at <filename class="directory">/dev/sda1</filename>). For EFI compatibility, they are both located at <filename class="directory">/EFI/Microsoft/Boot/</filename> as well. These EFI applications then call <filename>winload.efi</filename>; which is the Windows Boot Loader. <filename>winload.efi</filename> is located at <filename class="directory">/WINDOWS/System32/Boot</filename>.
</para>
<para>
- Other files found withing the <filename class="directory">/EFI/Microsoft/Boot</filename> directory structure are the <filename>BCD</filename> (a registry formatted configuration file), sub-directories for language files, a memory test efi application, and the <filename>BCD</filename> log files. The <filename>BOOTSTAT.DAT</filename> file is used to flag whether a recovery mode is required.
+ Other files found within the <filename class="directory">/EFI/Microsoft/Boot</filename> directory structure are the <filename>BCD</filename> (a registry formatted configuration file), sub-directories for language files, a memory test efi application, and the <filename>BCD</filename> log files. The <filename>BOOTSTAT.DAT</filename> file is used to flag whether a recovery mode is required.
</para>
<para>
- Mui stands for Multilingual User Interface and the <filename>*.mui</filename> files located in the <filename class="directory">bg-BG</filename> sub-directory are used to provide language support in other-than-english installations.
+ Mui stands for 'Multilingual User Interface' and the <filename>*.mui</filename> files located in the <filename class="directory">bg-BG</filename> sub-directory are used to provide language support in other-than-english installations.
</para>
<para>
There doesn't seem to be any information at all on what <filename>boot.stl</filename> is or what functions it may perform.
</para>
</section>
+<section id="Fedora_EFI_Files">
+ <title>Fedora EFI Partition Files</title>
+ <para>
+ Within a Fedora-created EFI partition you will find the following files at the designated locations. The purpose of each file is also given:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ ./EFI/fedora/MokManager.efi: To launch a locally-compiled kernel, you must sign it with a MOK and register that MOK with the system. For example, if you recompiled the kernel with third-party kernel drivers, such as those needed by Nvidia's and AMD/ATI's proprietary video drivers. This file manages that process.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ ./EFI/fedora/gcdx64.efi: Used to boot live media; called by shim.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ ./EFI/fedora/grubx64.efi: The main GRUB executable (signed with Fedora's key for Secure Booting).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ ./EFI/fedora/shim-fedora.efi: Performs the signing mechanism for grubx64.efi in a Secure Boot scenario
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ ./EFI/fedora/shim.efi: This a Microsoft signed stub to allow booting using Secure Boot on 'Windows Ready Certified' computers.
+ </para>
+ </listitem>
+</orderedlist>
+</section>
+<section id="Bootfiles">
+<section id="Bootfiles.Windows_BCD">
+ <title>Windows uses <filename>bootmgrfw.efi</fliename> and <filename>BCD</filename> to boot</title> 64 bit Windows operating systems. <filename>bootmgr.efi</filename> is used in conjunction with <filename>BCD</filename> in 32 bit installations.
+ <para>
+ On a legacy, BIOS-based, PC the <filename>BCD</filename> is located at <filename class="directory">\Boot\BCD</filename>
+ On an EFI firmware-based PC it is located at <filename class="directory">\EFI\Microsoft\Boot\</filename>
+ </para><para>
+ <filename>BCD</filename> is actually formatted as a registry hive and is therefore totally Windows-centric and proprietary. While <filename>BCD</filename> can be configured to boot other operating systems, it cannot be done without a certain measure of difficulty and an even greater level of un-dependability after reboots.
+ </para>
+ <para>
+ <filename>BCD</filename> contains configuration data that controls the operation of the Windows Boot Loader. Since there is only one defined mechanism for booting, if <filename>bootmgr.efi</filename>, <filename>bootmgrfw.efi</filename> or the <filename>BCD</filename> is missing, or corrupt, you cannot boot into Windows.
+ </para>
+ </section>
+ <section id="Bootfiles.Fedora_GRUB">
+ <title>Fedora uses <filename> shim.efi</filename>, <filename>gurbx64.efi</filename> and <filename>grub.cfg</filename> to boot</title>
+ <!-- comment: need to finish filling in this section -->
+ <para>
+ Full text will be added here....
+ </para>
+ <para>
+ In the event that the normal files cannot be loaded, a process is provided that uses a process called "fallback".
+ </para>
+ <para>
+ In this process, <filename>bootx64.efi</filename> is loaded and executed by the UEFI firmware; which in turn loads <filemame>fallback.efi</filename>. Another file called <filename>Boot.csv</filename> contains entries that will be added 'on-the-fly' to the EFI NVRAM. <filename>fallback.efi</filename> will search the entire partition looking for Boot.csv files, read their data, and create entries in NVRAM for each one. It will then adjust the BootNext variable and pass execution back to the firmware to boot from that entry. This process is known as fallback and allows for a 'second chance' to get an operating system loaded in the event that its original entry in EFI firmware was deleted or corrupt.
+ </para>
+ <para>
+ If your <filename>grub.cfg</filename> file is missing you will go to a GRUB command prompt where (using various GRUB commands) you can gather the information you need to boot your Fedora installation.
+ </para>
+ <para>
+ As a side note, the <filename>shim.efi</filename> file, located in <filename class="directory">/EFI/fedora</filename> of the EFI Partition, is used in Secure Boot scenarios (covered in detail here: <xref linkend="UEFI-general" />) and simply passes control to GRUB2; which then lists the various Operating Systems entries from the <filename>grub.cfg</filename> file to the screen for selection by the user.
+ </para>
+ <para>
+ </section>
+</section>
<section id="Similarities_and_Differences">
- <title>Similarities and Differences Between <filename>bootmgrfw.efi</filename> and <filename>bootx64.efi</filename></title>
+ <title>Similarities and Differences Between <filename>bootmgrfw.efi</filename>, <filename>grubx64.efi</filename> and <filename>bootx64.efi</filename></title>
<para>
While you could say that <filename>bootmgrfw.efi</filename> acts in the same way as GRUB2 there are technical differences that show this not to be the case.
</para>
@@ -48,11 +132,14 @@
They are similar in that they all look for a configuration file: <filename>bootmgrfw.efi</filename> looks for <filename>BCD</filename>, <filename>grubx64.efi</filename> looks for <filename>grub.cfg</filename>, and <filename>bootx64.efi</filename> (using <filename>fallback.efi</filename> looks for <filename>Boot.csv</filename>
</para>
<para>
- The main difference is that GRUB2's <filename>bootx64.efi</filename> is used when the EFI firmware goes into 'Default Boot Behavior' as a result of not finding any bootmanagers to load on the first time through the BootOrder listing in NVRAM; <filename>bootmgrfw.efi</filename> is called every time for a Windows boot. The end result is that if either the <filename>bootmgrfw.efi</filename> or the <filename>BCD</filename> is corrupt, or otherwise inaccessible, then Windows will not boot. Its game over. GRUB, on the other hand, has alternative methods for booting, which is implemented using <filename>bootx64.efi</filename> as well as a GRUB command prompt. This is all explained in detail below.
- </para>
+ The main difference is that the GRUB2 <filename>bootx64.efi</filename> file is used when the EFI firmware goes into 'Default Boot Behavior' as a result of not finding any bootmanagers to load on the first time through the BootOrder listing in NVRAM; <filename>bootmgrfw.efi</filename> is called every time for a Windows boot. The end result is that if either the <filename>bootmgrfw.efi</filename> or the <filename>BCD</filename> is corrupt, or otherwise inaccessible, then Windows will not boot. Its game over.
+ </para>
+ <para>
+ GRUB, on the other hand, has alternative methods for booting, which are implemented using <filename>bootx64.efi</filename> as well as a GRUB command prompt. This is all explained in detail below.
+ </para>
</section>
<section id="BCD_vs_GRUB">
- <title>BCD's Limitations vs GRUB2's Universality</title>
+ <title>BCD Limitations vs GRUB2 Universality</title>
<para>
BCD, by default, only knows about ONE installation (Windows); which it boots by loading winload.efi
</para>
@@ -66,32 +153,6 @@
Under normal boot operations, the GRUB2 manager/loader (<filename>grubx64.efi</filename>) is called directly (via <filename>shim.efi</filename> in Secure Boot), which then reads the <filename>grub.cfg</filename> file and displays its entries for user intervention. Adding additional entries to <filename>grub.cfg</filename> can be done with any simple text editor. More specific nformation on GRUB is available here: <xref linkend="GRUB" />
</para>
</section>
-<section id="Windows_EFI_Files">
- <title>Windows EFI Partition Files</title>
- <para>
- On a legacy, BIOS-based, PC the <filename>BCD</filename> is located at <filename class="directory">\Boot\BCD</filename>
- On an EFI firmware-based PC it is located at <filename class="directory">\EFI\Microsoft\Boot\</filename>
- <filename>BCD</filename> is actually formatted as a registry hive and is therefore totally Microsoft-centric. While <filename>BCD</filename> can be configured to boot other OS's, it cannot be done without a certain measure of difficulty and an even greater level of un-dependability after reboots.
- </para>
- <para>
- <filename>BCD</filename> contains configuration data that controls the operation of the Microsoft's boot manager.
- <filename>Boot.csv</filename> contains entries that will be added to the EFI NVRAM by <filename>fallback.efi</filename>; which is called by <filename>bootx64.efi</filename>.
- </para>
- <para>
- If <filename>BCD</filename> is missing, or corrupt, you can't boot into Windows.
- If your <filename>grub.cfg</filename> file is missing you will go to a command prompt where you can still get the information you need to boot your Fedora installation.
- </para>
- <para>
- <filename>Bootx64.efi</filename> is essentially shim.efi acting in a different manner:
- The <filename>shim.efi</filename> file, located in <filename class="directory">/EFI/fedora</filename> of the EFI Partition, is used in Secure Boot scenarios (covered in detail later) and simply passes control to GRUB2; which then lists the various Operating Systems entries from the <filename>grub.cfg</filename> file to the screen for selection by the user.
- </para>
- <para>
- <filename>bootmgrfw.efi</filename> is called at every boot into windows and, after reading the <filename>BCD</filename> to determine the location of the windows installation, goes straight to loading windows via its boot loader -- <filename>winload.efi</filename>.
- </para>
- <para>
- GRUB2, on the other hand, takes advantage of two additional processes to boot: Default Boot Behavior (which includes the fallback process as outlined below) and a GRUB command prompt.
-</para>
-</section>
<section id="If_You_Must">
<title>Using BCD to dual boot</title>
<para>
@@ -108,131 +169,6 @@
Letting Anaconda create, and use, a separate EFI partition ensures that what has happened to others will not happen to you.
</para>
</section>
-<section id="Fedora_EFI_Files">
- <title>Fedora EFI Partition Files</title>
- <para>
- The below listed files are all found within the Fedora-created EFI partition:
- </para>
- <orderedlist>
- <listitem>
- <para>
- ./EFI/fedora/MokManager.efi: To launch a locally-compiled kernel, you must sign it with a MOK and register that MOK with the system. For example, if you recompiled the kernel with third-party kernel drivers, such as those needed by Nvidia's and AMD/ATI's proprietary video drivers. This file manages that process.
- </para>
- </listitem><listitem>
- <para>
- ./EFI/fedora/gcdx64.efi: used to boot live media; called by shim.</para>
- </listitem><listitem>
- <para>
- ./EFI/fedora/grubx64.efi: This is the main GRUB executable signed with Fedora's key.</para>
- </listitem><listitem>
- <para>
- ./EFI/fedora/shim-fedora.efi: This is the file that performs the signing mechanism for grubx64.efi in a Secure Boot scenario</para>
- </listitem><listitem>
- <para>
- ./EFI/fedora/shim.efi: This is the version of shim that's signed with Microsoft's key.</para>
- </listitem>
-</orderedlist>
- <para>
- GRUB2 takes advantage of two additional processes to boot: Default Boot Behavior (which includes the fallback process as outlined below) and a GRUB command prompt.
- </para>
-</section>
-<section id="Default_Boot_Behavior">
- <title>What is Default Boot Behavior?"</title>
- <para>
- Default Boot Behavior is an EFI process that is initiated when the EFI boot process cannot find a suitable boot manager or boot loader to pass execution to after traversing the BootOrder list.
- </para><para>
- It begins by enumerating all removable devices and then passing execution to the first instance of <filename>bootx64.efi</filename> it finds.
- </para><para>
- <filename>bootx64.efi</filename> uses <filename>fallback.efi</filename> to scan the entire EFI partition looking for <filename>boot.csv</filename> files in each sub-directory within the EFI partition. Everytime it finds one, <filename>fallback.efi</filename> creates and appends an entry in the EFI NVRAM. It then changes the BootNext variable to point to the first one it found. When finished, it directs execution back to EFI Boot Manager to boot using the NextBoot variable.
- </para>
- <para></para>
-</section>
-<section id="Default_Boot_Behavior.Fallback">
- <title>"What is Fallback and How Does it Work?"</title>
- <para>
- The reason this process is referred to as "fallback" is because, as noted above, <filename>bootx64.efi</filename> checks to see if a file named <filename>fallback.efi</filename> is in the same directory as itself, and if so, will execute it as an EFI application.
- </para><para>
- It is the <filename>fallback.efi</filename> application that enumerates the various <filename>boot.csv</filename> files that it finds, creates and appends the EFI NVRAM entries, and finally, passes control back to the EFI Boot Manager to boot the first entry it created; which, as mentioned earlier, it does by changing the BootNext variable.
- </para><para>
- The Default Boot Behavior, which initiates fallback, happens in the event that any of the following conditions are met:
-</para>
- <orderedlist>
- <listitem>
- <para>
- There aren't any existing NVRAM entires for any installed operating systems</para>
- </listitem><listitem>
- <para>
- That the entries that were listed in the BootOrder resulted in a 'no boot' situation from all installed, fixed devices
- </para>
- </listitem><listitem>
- <para>
- That your removable device settings in your EFI Boot Order Priority are such that removable devices (Live media, etc) are listed above your installed Operating Systems menu entries.
-</para>
-</listitem>
- </orderedlist>
- <para>
- Before moving on, I would like to add a few notes to help clariy the above information:
- </para>
- <para>
- One caveat to all that has been said about "Default Boot Behavior":
- If you already have installed Operating Systems on your system that will boot normally, and you want to use "Default Boot Behavior" to boot your removable media, then please read on.
- </para><para>
- Your EFI implementation has to be 'compliant' and your EFI Boot Settings have to indicate that removable devices are higher in the list than your installed Operating Systems. This allows the EFI to find and boot the removable media (if inserted) prior to attempting to run down the normal BootOrder list.
- </para><para>
- IF that is the case, then "Default Boot Behavior" will occur on that removable device and it will boot.
- </para><para>
- IF the implementation of EFI on your system is not compliant it may never get to the point where it loads <filename>fallback.efi</filename> - it still might not boot.
- </para><para>
- The only way to know for sure, is to plug in a USB, boot using the 'magic' key to enter your EFI Settings, change your boot priorites in the EFI to put the inserted USB at the top of the list, save and exit. Leave in the USB and power on without pressing any keys. If it boots to the USB automatically then everything is working as it should. If it won't boot, and/or it is not showing up on the list of devices provided by the EFI Boot Manager, then check that the device has an \EFI\Boot directory with bootx64.efi and fallback.efi in it. If all of that is there, then either the USB is 'bad', the port you plugged it into is 'bad' (something in the device path is 'bad') or your EFI implementaton is non-compliant.
- </para><para>
- If you do not have any installed OS's on your system...
- Just plug in removable media that meets the criteria for EFI "Default Boot Behavior" and turn it on.
- </para>
- <para>
- Many of these concepts will become clear as you continue with the EFI Boot Sequence Explained below.
- </para>
-</section>
-<section id="EFI_Boot_Explained">
- <title>EFI Boot Sequence Explained</title>
- <para>
- In this section we will consider two scenarios:
- <orderedlist>
- <listitem>
- <para>
- How EFI handles a normal boot cycle - no intervention.
- </para>
- </listitem>
- <listitem>
- <para>
- What happens when you press the appropriate key to enter the EFI Settings prior to a successful boot of an operating system.
- </para>
- </listitem>
- </orderedlist></para><para>
- First, EFI attempts each entry in the order listed in its BootOrder variable.
- It will boot the first entry that 'works' with the data listed for that entry.
- A typical entry is in the format of:
- ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(1,800,64000,12029cda-8961-470d-82ba-aeb17dba91a5) File(\EFI\fedora\shim.efi)
- </para><para>
- The EFI Boot Manager begins the process of loading the file (end result) by initializing each preceeding device in order. Thus, in the example above, it starts by initializing ACPI(a0248d0,0) which then provides access to PCI(1d,2) which then provides access to SATA(0,0,0) etc..
- EFI just goes down the line until it can load the file called for in that entry. If anything in that chain is broken or missing the boot fails.
- If it cannot boot the first entry in the BootOrder list, it will go to the second, and failing there, will move on to the third entry, etc.
- </para><para>
- If it gets to the end of the BootOrder list and still has not been able to transfer execution, it will begin to initialize every device connected to the system (fixed and removable) and begins to look specifically for removable devices. Remember, this is what happens automatically -- its what happens if you do not go into the "EFI Settings" and thereby stop the process at the end of initial enumeration of all connected devices. By hitting the 'magic' key, you alter the sequence of events and are, in effect, "Skip the boot process for now and just enumerate everything connected to the motherboard." Full enumeration is not conducted until after the BootOrder sequence has been exhausted during normal boots. Right now, we are looking at what happens automatically if EFI cannot find a bootable device by traversing its BootOrder entries.
- </para><para>
- As EFI Boot Manger moves on to find a bootable, removable device, it looks for an EFI partition, formatted in Fat32, Fat16 or Fat12 with an \EFI\Boot\ directory structure and that bootx64.efi is in that directory.
- </para><para>
- When that file is found and loaded, execution is passed to it. In Fedora, that means that bootx64.efi is going to check for the presence of fallback.efi; and if it finds it, will pass execution to it. Fallback.efi will then enumerate all of the boot.csv's it can find in its own partition, create and append an entry for each one to the EFI NVRAM, change the NextBoot variable and pass execution back to the EFI for processing. Having a valid entry, EFI will boot to that device and hand over execution.
- </para><para>
- At some point, either grubx64.efi or the kernel itself will issue a command to EFI to terminate its boot support processes and standby for a reboot, standby, hibernate or power down command. In effect, we are saying to EFI: "Ok. We got it from here."
- </para><para>
- Ubuntu, for example, has chosen to make that call just prior to loading the kernel, while Fedora continues to use EFI support services until after the kernel has verified the signatures on all boot files; thus continuing the 'chain of trust' a little further.
- </para><para>
- In any event, EFI will boot to the first device it can either find on its own, or to the one its told to.
-</para><para>
- When you enter the "EFI Settings" of your computer and look at the menu, all of that enumeration is complete before the menu is displayed. All you then have to do is select which device you wish to boot from and hit Enter.
- </para>
-</section>
-
<!-- comment
Refs:
@@ -255,5 +191,3 @@ https://www.youtube.com/watch?v=35D0_feZnK8
http://superuser.com/questions/376470/how-to-reinstall-grub2-efi
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System_Administrators_Guide/index.html#ch-Working_with_the_GRUB_2_Boot_Loader
https://en.wikipedia.org/wiki/GNU_GRUB#GRUB_version_2 -->
-
-</section>
More information about the docs-commits
mailing list