Adding content, shuffling things around. Trying my hand at formatting.

1 files changed, 188 insertions, 109 deletions

diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 3ad4f71..eb54c0e 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -5,111 +5,185 @@
 %BOOK_ENTITIES;
 ]>
 <section id="UEFI-win">
-  <title>Booting with Windows</title>
+  <title>Introduction</title>
   <para>
-  Intro:
-  
-  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 all environments; including Secure Boot.
-  
-  This article will cover the UEFI boot process in general, as well as how both Fedora and Windows boot in both standard UEFI and Secure Boot modes. Finally, it will cover how you can use Fedora's GRUB2 to multiboot all of the OS's you wish to install.
-  -------------------------------------------------------------------------------
-  The Difference Between a Boot Manager and a Boot Loader:
-  Discuss the definition and differences between boot managers and boot loaders:
-  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
- --------------------------------------------------------------------------------
- Files within the Microsoft EFI Partition:
- Microsoft uses bootmgr.efi and bootmgrfw.efi as boot managers; bootmgr.efi is the 32 bit version and bootmgrfw.efi is the 64 bit version. Both of these files are located in the root directory of the Microsoft-created EFI partition (usually found at /dev/sda1). For EFI compatibility, they are both located at /EFI/Microsoft/Boot/ as well. These EFI applications then call winload.efi as the boot loader. winload.efi is located at /WINDOWS/System32/Boot.
- 
- Other files found withing the /EFI/Microsoft/Boot directory structure are the BCD (a registry formatted configuration file), sub-directoris for language files, a memory test efi application, and the BCD log files. The BOOTSTAT.DAT file is used to flag whether a recovery mode is required.   Mui stands for Multilingual User Interface and the *.mui files located in the bg-BG sub-directory are used to provide language support in other-than-english installations. There isn't any information at all on what boot.stl is or what functions it may perform.
- ---------------------------------------------------------------------------------
- Similarities and Differences Between bootmgrfw.efi and bootx64.efi:
- While you could say that bootmgrfw.efi acts in the same way as GRUB2 there are technical differences that show this not to be the case. 
-  
-  Explanation:
-  bootmgrfw.efi is roughly equivilent to GRUB2's bootx64.efi (which will be covered in more detail later) What happens as each is called (and the format of the files involved) is where the differences start to show up...
-  
-  They are similar in that both look for a configuration file: bootmgrfw.efi looks for BCD and bootx64.efi looks for Boot.csv
-  The main difference is that GRUB2's bootx64.efi is only used when the EFI firmware goes into 'Default Boot Behavior' 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 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 the  Microsoft's boot manager.
-  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 and appends an entry in the EFI NVRAM and changes the NextBoot 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. 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. 
-    
-    This happens in the event that there are either no existing NVRAM entires for any installed operating systems, that the entries that were listed in the BootOder resulted in a 'no boot' situation from all installed, fixed devices, or that your removable device settings in your EFI Boot Order Priority are such that removable devices (USB's, Live media, etc) are listed above your installed OS's  -- in which case (as noted below) the expected directory structure for normal EFI booting is not present.
-  --------------------------------------------------
-  What is Fallback and How Does it Work?
-  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" (looking for removable devices to boot from by searching for and calling \EFI\Boot\bootx64.efi) provides a way to place boot entries into the EFI NVRAM by a process that uses an EFI application, typically called fallback.efi.
- ------------------------------------------------------------------------ 
- Booting Live Media in EFI:
-  As indicated above, 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. Removable devices are enumerated -- usually -- after the BootOrder list has been exhausted without a boot. However, removable device enumeration will take place before you are presented with the EFI Boot Manager menu 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 page whenever you press the 'magic' key during power on. That is because the removable device enumeration process is occurring and adding entries for any/all removable media that may be inserted. Once the enumeration process has completed, the EFI will halt the boot process and you are presented with the EFI Boot Manager Menu from which you can make your selection.
-  ----------------------------------------------------
-  More Details on EFI's Default Boot Behavior:
-  One caveat to all that has been said about "Default Boot Behavior":
-  If you already have installed OS's on your system that will boot normally....
-  And you want "Default Boot Behavior" to boot your removable media...
-  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 OS's. This allows the EFI to find and boot the removable media (if inserted) prior to attempting to run down the normal BootOrder list.
-  IF that is the case, then "Default Boot Behavior" will occur on that removable device and it will boot.
-  IF the implementation of EFI on your system is not compliant and it gets to the enumeration of removable devices, and fallback.efi enumerates, creates and appends the BootOrder list, and modifies the NextBoot variable, and passes control back to the EFI - it still might not boot.
-  
-  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.
-  
-  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.
-  ------------------------------------------------------
-  BCD's Limitations vs GRUB's universality:
-  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. 
-  
+    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 all environments; including Secure Boot.
+  </para>
+  <para>
+    This article begins by covering both the Windows and Fedora UEFI boot process in general. From there, it moves on to explain the specifics of both standard and Secure Boot modes.
+  </para>
+</section>
+<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
+  </para>
+</section>
+<section id="Files_within_the_Microsoft_EFI_Partition">
+  <title>Files within the Microsoft EFI Partition</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>.
+  </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. 
+  </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. 
+    </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="Similarities_and_Differences">
+  <title>Similarities and Differences Between <filename>bootmgrfw.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>
+  <para>
+   <filname>bootmgrfw.efi</filename> is roughly equivilent to both of the GRUB2 files <filename>bootx64.efi</filename> and <filename>grubx64.efi</filename> (which will be covered in more detail later). What happens as each is called (and the format of the files involved) is where the differences start to show up...
+  </para><para>
+   They are similar in that they all look for a configuration file: <filenmane>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 an 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>
+</section>
+<section id="BCD_vs_GRUB">
+  <title>BCD's Limitations vs GRUB2's Universality<title>
+  <para>
+    BCD, by default, only knows about ONE installation (Windows); which it boots by loading winload.efi
+   </para>
+   <para>
+    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. 
+   </para>
+   <para>
     GRUB2, on the other hand, is designed from the gound up to handle all forms of operating systems.
-  
+  </para>
+  <para>
     Under normal boot operations, the GRUB2 manager/loader (grubx64.efi) is called directly (via shim.efi in Secure Boot), which then reads the grub.cfg file and displays its entries for user intervention.
- -----------------------------------------------------
-  EFI Boot Sequence Explained:
-  
-  Two scenarios:
-  1.  How EFI handles a normal boot cycle - no intervention.
-  2.  What happens when you press the appropriate key to enter the EFI Settings prior to a successful boot of an operating system.
-  -----
+   </para>
+</section>  
+<section id="Windows_EFI_Files">
+  <titile>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>
+    <filenmane>BCD</filename> is actually formatted as a registry hive and is therefore totally Microsoft-centric. While <filenmane>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>
+   <filenmane>BCD</filename> contains configuration data that controls the operation of the  Microsoft's boot manager.
+   <filenmane>Boot.csv</filename> contains entries that will be added to the EFI NVRAM by <filenmane>fallback.efi</filename>; which is called by <filename>bootx64.efi</filename>.
+  </para>
+  <para>
+   If <filenmane>BCD</filename> is missing, or corrupt, you can't boot into Windows.<br></br>
+   If your <filenmane>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>
+   <filenmane>Bootx64.efi</filename> is essentially shim.efi acting in a different manner:
+   The <filenmane>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 <filenmane>grub.cfg</filename> file to the screen for selection by the user. 
+  </para>
+  <para>
+    <filenmane>bootmgrfw.efi</filename> is called at every boot into windows and, after reading the <filenmane>BCD</filename> to determine the location of the windows installation, goes straight to loading windows via its boot loader -- <filenmane>winload.efi</filename>.
+ </para>
+</section>  
+<section id="GRUB_EFI_Files">
+  <titile>GRUB EFI Partition Files</title>
+  <para>
+  <!-- Comment Listing of GRUB2 files and their purposes here.... -->
+  </para><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>
+    <filenmane>bootx64.efi</filename> uses <filename>fallback.efi</filename> to scan the entire EFI partition looking for <filenmane>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, with initiates fallback, happens in the event that any of the following conditions are met:
+    <orderedlist>
+    <listitem>
+    There aren't any existing NVRAM entires for any installed operating systems</listitem><listitem>
+    That the entries that were listed in the BootOrder resulted in a 'no boot' situation from all installed, fixed devices</listitem><listitem>
+    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.</listitem>
+    </orderedlist>
+    </para>
+    <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>
+  How EFI handles a normal boot cycle - no intervention.
+  </listitem>
+  <listitiem>
+  What happens when you press the appropriate key to enter the EFI Settings prior to a successful boot of an operating system.
+  </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
+ Booting Live Media in EFI:
+  As indicated above, 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. Removable devices are enumerated *usually* after the BootOrder list has been exhausted without a boot. However, removable device enumeration will take place before you are presented with the EFI Boot Manager menu 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 page whenever you press the 'magic' key during power on. That is because the removable device enumeration process is occurring and adding entries for any/all removable media that may be inserted. Once the enumeration process has completed, the EFI will halt the boot process and you are presented with the EFI Boot Manager Menu from which you can make your selection.
   
-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 BCD to Dual-Boot:
   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/
@@ -120,18 +194,19 @@ When you enter the "EFI Settings" of your computer and look at the menu, all of
  
   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. Letting Anaconda create, and use, a 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.
+
  File reference, example information for further use in explaining other aspects of multibooting and repairing an installation...
  
  FIles listing for EFI partition created by Fedora:
  
-    ./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.
-    ./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 -- This is the file that performs the signing mechanism for grubx64.efi in a Secure Boot scenario
-    ./EFI/fedora/shim.efi -- This is the version of shim that's signed with Microsoft's key.
- --------------------------------------------------------------------------------
+    ./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.
+    ./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: This is the file that performs the signing mechanism for grubx64.efi in a Secure Boot scenario
+    ./EFI/fedora/shim.efi: This is the version of shim that's signed with Microsoft's key.
+ 
+
  Using df -H:
  
 root@localhost /: df -H
@@ -145,7 +220,8 @@ tmpfs                    4.2G   58k  4.2G   1% /tmp
 /dev/sda8                500M  104M  366M  23% /boot
 /dev/sda7                210M   10M  200M   5% /boot/efi
 /dev/mapper/fedora-home  162G   26G  128G  17% /home
-----------------------------------------------------------------------------------
+
+
 Using parted print:
 
 root@localhost /: parted /dev/sda print
@@ -164,7 +240,8 @@ Number  Start   End     Size    File system  Name                          Flags
  8      753GB   754GB   524MB   ext4
  9      754GB   989GB   235GB
  6      989GB   1000GB  10.8GB  ntfs         Microsoft recovery partition  hidden, diag
-------------------------------------------------------------------------------
+
+
 Using blkid:
 
 root@localhost /: blkid
@@ -181,7 +258,8 @@ root@localhost /: blkid
 /dev/mapper/fedora-root: UUID="6302bae0-5a18-4fdb-84da-a83bf512ad82" TYPE="ext4" 
 /dev/mapper/fedora-swap: UUID="7a4fabaf-3385-40c3-822f-b3ba3d33caaf" TYPE="swap" 
 /dev/mapper/fedora-home: UUID="96872f18-6312-43ea-a177-447fdbee98df" TYPE="ext4" 
-------------------------------------------------------------------------------
+
+
 Looking at fstab entries;
 Modifying fstab:
 
@@ -201,7 +279,8 @@ UUID=E085-2C94          /boot/efi               vfat    umask=0077,shortname=win
 ~                                                                                                                                                      
 ~                                                                                                                                                                                                                                                                                                      
 "/etc/fstab" 13L, 688C
------------------------------------------------------------------------------
+
+
 Looking at crypttab;
 Modifying crypttab:
 
@@ -212,7 +291,8 @@ luks-c32b5719-857f-48fb-a782-6086dd05d008 UUID=c32b5719-857f-48fb-a782-6086dd05d
 ~                                                                                                                                                      
                                                                                                                          
 "/etc/crypttab" 1L, 90C
-----------------------------------------------------------------------------
+
+
 Copying the Fedoara-created ESP files to the Microsoft-created ESP  (for whatever reason)
 
 # cd /mnt
@@ -230,11 +310,12 @@ Verify the copy...
 # cd /
 # umount /mnt/msftesp
 # rm -r -f   /mnt/msftesp
-------------------------------------------------------------------------------
+
 Make an EFI entry:
 
 # efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi -L Fedora
- -----------------------------------------------------------------------------
+
+
 A proper Windows GRUB entry:
 Place inside the 'custom' section...
 
@@ -246,10 +327,11 @@ menuentry 'Windows Boot Manager - Windows 8.1' {s
 	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
 	boot
 }
------------------------------------------------------------------------------------
+
+
 Refs:
 
-<!-- comment url:http://www.rodsbooks.com/efi-bootloaders/index.html
+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
@@ -268,6 +350,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 -->
-
-  </para>
-</section>