Some markup corrections:

- Move top level section tags to include all other sections in the file
- correct misspelled tags
- Use <para> for listitem contents (although other tags may also apply)

1 files changed, 38 insertions, 24 deletions

diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index eb54c0e..95a1389 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -12,7 +12,6 @@
   <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>
@@ -42,16 +41,16 @@
     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...
+   <filename>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>
+   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 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>
+  <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>
@@ -66,30 +65,30 @@
    </para>
 </section>  
 <section id="Windows_EFI_Files">
-  <titile>Windows EFI Partition Files</title>
+  <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>
-    <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.
+    <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>
-   <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>.
+   <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 <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.
+   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>
-   <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. 
+   <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>
-    <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>.
+    <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>
 </section>  
 <section id="GRUB_EFI_Files">
-  <titile>GRUB EFI Partition Files</title>
+  <title>GRUB EFI Partition Files</title>
   <para>
   <!-- Comment Listing of GRUB2 files and their purposes here.... -->
   </para><para>
@@ -101,9 +100,9 @@
   <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. 
+  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. 
+    <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>
@@ -116,10 +115,18 @@
   </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>
+      <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>
     <para>
@@ -149,11 +156,15 @@
   <para>
   In this section we will consider two scenarios:
   <orderedlist>
-  <listitem>
-  How EFI handles a normal boot cycle - no intervention.
+    <listitem>
+      <para>
+        How EFI handles a normal boot cycle - no intervention.
+      </para>
   </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>
+    <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.
@@ -350,3 +361,6 @@ 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>