Added notes that will be used to form the foundation of the article

1 files changed, 64 insertions, 3 deletions

diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 94afc1d..e23da5c 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -1,10 +1,71 @@
 <?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" 
+[
 <!ENTITY % BOOK_ENTITIES SYSTEM "Fedora_Multiboot_Guide.ent">
 %BOOK_ENTITIES;
-
 ]>
 <section id="UEFI-win">
   <title>Booting with Windows</title>
-  <para />
+  <para>
+  Notes:
+  Discuss the definition and differences between boot managers and boot loaders.
+  
+  Everything that Microsoft's boot manager does can be done using the EFI boot manager directly
+   
+  bootmgrfw.efi is equivilent to bootx64.efi;
+  both look for a configuration file: bootmgrfw.efi looks for BCD and bootx64.efi looks for Boot.csv
+  The main difference is that bootx64.efi is only used when the EFI firmware goes into 'Default' mode as a result of not finding any bootmanagers to load on the first time through the BootOrder listing in NVRAM; bootmgrfw.efi is called every time for a Windows boot.
+  
+ On legacy, BIOS-based, PC's the BCD is located at \Boot\BCD 
+ On EFI firmware-based PC's it is located at \EFI\Microsoft\Boot\
+ BCD is totally Microsoft-centric but it can be configured to boot other OS's -- but not without a certain measure of difficulty and an even greater level of un-dependability.
+  
+  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 bootx64.efi.
+  
+  Bootx64.efi is essentially shim.efi acting in a different manner:
+  shim.efi simply passes control to GRUB2, which then lists the various OS's it is aware of to the screen for selection by the user. bootx64.efi, on the other hand, scans the entire EFI partition looking for a Boot.csv file 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 were incorrect in some way resulting in a 'no boot' situation from any installed, fixed device.
+  
+  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 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. 
+  
+  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.
+  
+  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.
+  
+  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)
+  
+  The EFI Boot Manager begins loading of 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.
+  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.
+  
+  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.
+
+
+  ------------------- 
+  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). 
+  This could be notated with: /dev/sda1/boot/EFI/ as the location to copy the fedora directory to.
+  /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. You will need to copy all of the files from that partition (starting at the fedora sub-directory) to the EFI partition created by Microsoft during its installation, if you want to use BCD to jump over to your Fedora installed GRUB. 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. 
+  
+  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.
+ ----------------------------------------------
+ FIles listing for EFI partition created by Fedora:
+ 
+    ./EFI/fedora/MokManager.efi -- This program comes with shim and enables you to add keys to the Machine Owner Key (MOK) list from the EFI. It's launched automatically by shim if shim's normal follow-on program (grubx64.efi) fails Secure Boot tests.
+    ./EFI/fedora/gcdx64.efi -- used to boot live media -- called by shim.
+    ./EFI/fedora/grubx64.efi -- This is the main GRUB executable signed with Fedora's key.
+    ./EFI/fedora/shim-fedora.efi -- I'm not 100% positive, but I believe this is an unsigned version of shim. I'm not sure why it's installed.
+    ./EFI/fedora/shim.efi -- This is the version of shim that's signed with Microsoft's key.
+ ----------------------------------------------
+
+  
+  
+  
+  </para>
 </section>