[multiboot-guide] master: Light cleanup and minor editing (970402d)

immanetize at fedoraproject.org immanetize at fedoraproject.org
Tue Jan 6 03:38:46 UTC 2015 

Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git

On branch  : master

>---------------------------------------------------------------

commit 970402d59c4feddcbc47e00fd10572ef4c9d67cd
Author: Roger Baran <rapidrecoveryit at gmail.com>
Date:   Fri Sep 26 16:38:55 2014 -0500

    Light cleanup and minor editing


>---------------------------------------------------------------

 en-US/UEFI-win.xml |   35 ++++++++++++++++++++++++-----------
 1 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 90f033a..3eb9e4b 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -32,20 +32,23 @@
  BCD is actually formatted as a registry hive and is therefore totally Microsoft-centric. While BCD 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.
   
   BCD contains configuration data that controls the operation of Microsoft's boot manager.
-  Boot.csv contains entries to that will be added to the EFI NVRAM by fallback.efi; which is called by bootx64.efi.
+  Boot.csv contains entries that will be added to the EFI NVRAM by fallback.efi; which is called by bootx64.efi.
+  
+  If BCD is missing, or corrupt, you can't boot into Windows.
+  If your grub.cfg file is missing you will go to a command prompt where you can still get the information you need to boot your Fedora installation.
   
   Bootx64.efi is essentially shim.efi acting in a different manner:
   The shim.efi file, located in /EFI/fedora 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 OS's from the grub.cfg file to the screen for selection by the user. 
   
   bootmgrfw.efi is called at every boot into windows and, after reading the BCD to determine the location of the windows installation, goes straight to loading windows via its boot loader -- winload.efi.
   
-    GRUB2's bootx64.efi, on the other hand, scans the entire EFI partition looking for Boot.csv files in each sub-directory within the EFI partition. Everytime it finds one, it creates/appends an entry in the EFI NVRAM. When finished, it directs execution back to EFI Boot Manager to boot the first one it found. This process is sometimes referred to as "fallback" but it is a standard part of the EFI specification under such circumstances and is called the "Default Boot Behavior" by that specification.  "Default Boot Behavior" specifically refers to the loading of \EFI\Boot\bootx64.efi in the event that there are either no existing NVRAM entires for installed operating systems or that the entries that were there resulted in a 'no boot' situation from any installed, fixed device.
+    GRUB2's bootx64.efi, on the other hand, scans the entire EFI partition looking for Boot.csv files in each sub-directory within the EFI partition. Everytime it finds one, it creates and appends an entry in the EFI NVRAM. When finished, it directs execution back to EFI Boot Manager to boot the first one it found. It does this by changing the BootOrder variable. This process is sometimes referred to as "fallback" but it is a standard part of the EFI specification under such circumstances and is called the "Default Boot Behavior" by that specification.  "Default Boot Behavior" specifically refers to the loading of \EFI\Boot\bootx64.efi in the event that there are either no existing NVRAM entires for any installed operating systems or that the entries that were there resulted in a 'no boot' situation from all installed, fixed devices.
   
-  The reason it is referred to as "fallback" is because, bootx64.efi will look to see if fallback.efi is in the same directory as itself, and if it is, will execute it as an EFI application. It is the fallback.efi application that enumerates the various boot.csv's 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 it does by changing the BootOrder variable. 
+  The reason it is referred to as "fallback" is because, bootx64.efi will look to see if fallback.efi is in the same directory as itself, and if it is, will execute it as an EFI application. It is the fallback.efi application that enumerates the various boot.csv's 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 NextBoot variable. 
   
-  In other words, the Default Boot Behavior (calling \EFI\Boot\bootx64.efi as a 'last resort') provides a way to place boot entries into the EFI NVRAM by a process called fallback that uses an EFI application, typically called fallback.efi.
+  In other words, the Default Boot Behavior (calling \EFI\Boot\bootx64.efi as a 'last resort') provides a way to place boot entries into the EFI NVRAM by a process that uses an EFI application, typically called fallback.efi.
   
-  As a side note, this is the way that removable media gets listed in the NVRAM for booting. LiveCD's, as well as other Live Media (USB, etc.) are missing the standard directory structure called for in the EFI specifications -- unless an OS has actually been installed to that device (such as a USB). Since that directory sturcture is not there, it won't be added to the EFI Boot Manager menu until removable devices are enumerated. This all typically takes place before you are presented with the EFI Boot Manager menu that you see when you hold down the correct key (while powering on) to enter the EFI firmware screen.
+  As a side note, this is the way that removable media gets listed in the NVRAM for booting. LiveCD's, as well as other Live Media (USB, etc.) are missing the standard directory structure called for in the EFI specifications -- unless an OS has actually been installed to that device (such as a USB). Since that directory sturcture is not there, it won't be added to the EFI Boot Manager menu until removable devices are enumerated. This all typically takes place before you are presented with the EFI Boot Manager menu that you see when you hold down the correct key (while powering on) to enter the EFI firmware screen. You will notice a short delay in getting into the EFI Settings having pressed the 'magic' key during power on. That is because the enumeration process is still ongoing and adding entries for the USB key you just inserted. Once the enumeration process has completed, you have interruped the boot process and are presented with the EFI Boot Manager Menu and can make yo
 ur selection.
   
   BCD, by default, only knows about ONE installation (Windows); which it boots by loading winload.efi
   While BCD can be configured to allow for other entries, including pointing its default loader to a particular GRUB2 installation, it doesn't work very well. bootmgrfw.efi, using BCD, is designed to handle Windows. Period. It provides a straight shot to the Windows installation and that's it. 
@@ -65,24 +68,34 @@
   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)
   
-  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(a0341d0,0) which then provides access to PCI(1f,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.
+  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.
   
-  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 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. Right now, we are looking at what happens automatically if EFI cannot find a bootable device by traversing its BootOrder entries.
+  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.
+  
+  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.
+  
+  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.
   
-  As EFI Boot Manger moves on to find a bootable, removable device, it looks for an EFI partition, formatted in VFat32, with a \EFI\Boot\ directory structure and that bootx64.efi is in that directory.
-It will boot to the first removable device that meets that criteria. 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.
+  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."
 
+  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.
 
+In any event, EFI will boot to the first device it can either find on its own, or to the one its told to.
+
+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.
   ------------------- 
   Using the default windows boot manager (which in turn uses BCD), to dual boot can be accomplished by entering 'bcdedit /set {bootmgr} path \EFI\fedora\shim.efi' at an administrator's command prompt. That command causes the windows boot manager to point to the Fedora shim.efi, which will in turn call grubx64.efi and present the gurb menu. The only caveat with this, is that the Fedora EFI partition files have to be moved to the windows-created EFI partition (usually /dev/sda1). 
   For ease of understanding, this could be notated as /dev/sda1/boot/EFI/
   That is the location to copy the fedora directory to. The actual procedure for doing so is covered later in this article. For now, just the concept and overview is being presented.
   /dev/sda1/boot/EFI will already have directories for Boot and Microsoft; you will be adding in the fedora directory sturcture at that location.
   
-  During an installation of Fedora, where Anaconda creates the partitions automatically, there will be a separate EFI partition for the Fedora installation. To make BCD the boot manager for booting into your fedora installation, you will need to copy all of the files from the Fedora-created EFI partition (starting at the fedora sub-directory) to the EFI partition created by Microsoft during its installation. You can also choose, during installation, to manually set up your partitions; in which case you can simply indicate a mount point of '/boot/efi' for the Microsoft created partition and tell it not to format that partition. Grub will then create the /boot/efi/EFI/fedora directory and populate it with the necessary files. 
+  During an installation of Fedora, where Anaconda creates the partitions automatically, there will be a separate EFI partition for the Fedora installation. To make BCD the boot manager for booting into your fedora installation, you will need to copy all of the files from the Fedora-created EFI partition (starting at the fedora sub-directory) to the EFI partition created by Microsoft during its installation. You can also choose, during installation, to manually set up your partitions; in which case you can simply indicate a mount point of '/boot/efi' for the Microsoft created partition and tell it not to format that partition. Grub will then create the "/dev/sda1/EFI/fedora directory and populate it with the necessary files and upon restart, /dev/sda1 will be mounted at /boot/efi/
+ 
+  However! Please keep reading!
   
-  Note!: There are reports that Microsoft, upon seeing another OS listing in "its" EFI partition, will (either inadvertantly or deliberately -- no one knows which one for sure) destroy the directory structure for the other OS -- thus disallowing the EFI Boot Manager to access the shim.efi file pointed to by the modified BCD. It is recommended to maintain a separate EFI partition (by letting Anaconda do the grunt work of setting up all of the partitions) and then tweaking their sizes as desired. The separate EFI partition ensures that what has happened to others will not happen to you.
+  Note!: There are reports that Microsoft, upon seeing another OS listing in "its" EFI partition, will (either inadvertantly or deliberately -- no one knows which one for sure) destroy the directory structure for the other OS -- thus disallowing the EFI Boot Manager to access the shim.efi file pointed to by the modified BCD. It is recommended to maintain a separate EFI partition (by letting Anaconda do the grunt work of setting up all of the partitions) and then tweaking their sizes as desired. Letting Anaconda create, and use, a separate EFI partition ensures that what has happened to others will not happen to you.
  ----------------------------------------------
  FIles listing for EFI partition created by Fedora:

More information about the docs-commits mailing list