Parted out material. Reached rough draft stage

1 files changed, 52 insertions, 163 deletions

diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 95a1389..cf3bc02 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -7,11 +7,14 @@
 <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 all environments; including Secure Boot.
+    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.
   </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.
+    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.
+</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/" /> 
   </para>
+</section>
 <section id="Boot_Manager_vs_BootLoader">
   <title>Boot Managers and Boot Loaders Defined</title>
   <para>
@@ -46,7 +49,7 @@
    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. 
+   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>
 </section>
 <section id="BCD_vs_GRUB">
@@ -55,13 +58,13 @@
     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. 
+    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. <filename>bootmgrfw.efi</filename>, using <filename>BCD</filename>, is designed to handle Windows. Period. It provides a straight shot to the Windows installation and that's it. Adding additional entries to the <filename>BCD</filename> is done through a commandline tool called <filename>bcdedit</filename> which is poorly documented and not intuitive to use at all; primarilly becuase it is formatted as a proprietary database file (registry hive). 
    </para>
    <para>
-    GRUB2, on the other hand, is designed from the gound up to handle all forms of operating systems.
+    GRUB2, on the other hand, is designed from the gound up to handle all types of operating systems and makes it relatively easy to make changes to its configuration file.
   </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.
+    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">
@@ -86,12 +89,50 @@
   <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 id="If_You_Must">
+ <title>Using BCD to dual boot</title>
+ <para>
+     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.
+   </para><para>
+     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/
+   </para><para>
+   <literal>However! Please keep reading!</literal>
+   </para><para>
+   <literal>Note!:</literal> There are reports that Windows, 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 GRUB boot manager 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. 
+  </para><para>
+  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="GRUB_EFI_Files">
-  <title>GRUB EFI Partition Files</title>
+<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>
-  <!-- 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>
@@ -113,7 +154,7 @@
     </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:
+    The Default Boot Behavior, which initiates fallback, happens in the event that any of the following conditions are met:
     <orderedlist>
       <listitem>
         <para>
@@ -128,7 +169,6 @@
 </para>
 </listitem>
     </orderedlist>
-    </para>
     <para>
     Before moving on, I would like to add a few notes to help clariy the above information:
     </para>
@@ -192,154 +232,6 @@
  </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.
-  
-  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/
-  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 "/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. 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.
- 
-
- Using df -H:
- 
-root@localhost /: df -H
-Filesystem               Size  Used Avail Use% Mounted on
-/dev/mapper/fedora-root   62G  8.0G   51G  14% /
-devtmpfs                 4.2G     0  4.2G   0% /dev
-tmpfs                    4.2G  189k  4.2G   1% /dev/shm
-tmpfs                    4.2G  1.2M  4.2G   1% /run
-tmpfs                    4.2G     0  4.2G   0% /sys/fs/cgroup
-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
-Model: ATA TOSHIBA MQ01ABD1 (scsi)
-Disk /dev/sda: 1000GB
-Sector size (logical/physical): 512B/4096B
-Partition Table: gpt
-Disk Flags: 
-Number  Start   End     Size    File system  Name                          Flags
- 1      1049kB  525MB   524MB   fat32        EFI System Partition          boot
- 2      525MB   567MB   41.9MB  fat32        Basic data partition
- 3      567MB   701MB   134MB   fat32        Microsoft reserved partition  msftres
- 4      701MB   1488MB  786MB   ntfs         Microsoft recovery partition  hidden, diag
- 5      1488MB  753GB   752GB   ntfs         Basic data partition
- 7      753GB   753GB   210MB   fat16        EFI System Partition          boot
- 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
-/dev/sda1: LABEL="ESP" UUID="6481-E0BE" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="dfb7601a-7aab-4cd5-9469-50ea6d52c429" 
-/dev/sda2: LABEL="DIAGS" UUID="3AEE-450D" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="d6e615b6-5622-49b5-b1a8-26fc2c292ace" 
-/dev/sda3: UUID="3015-2D1B" TYPE="vfat" PARTLABEL="Microsoft reserved partition" PARTUUID="635e137d-cd6f-407d-bcc6-a4910caf4c1f" 
-/dev/sda4: LABEL="WINRETOOLS" UUID="6CA219D3A219A31E" TYPE="ntfs" PARTLABEL="Microsoft recovery partition" PARTUUID="7c6fb1d0-c57f-4406-9dbd-48aa944eb7f6" 
-/dev/sda5: LABEL="OS" UUID="A0C4A657C4A63008" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="10d5a99c-e2c2-4b33-a795-2444cd59b339" 
-/dev/sda6: UUID="C21C237B1C236A1D" TYPE="ntfs" PARTLABEL="Microsoft recovery partition" PARTUUID="e986d425-2360-43e0-828f-833aa84a4fd7" 
-/dev/sda7: SEC_TYPE="msdos" UUID="E085-2C94" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="2c746a4d-6539-4553-9ebb-b7b9603c446f" 
-/dev/sda8: UUID="4821d546-440e-47da-8272-50a97f711c3e" TYPE="ext4" PARTUUID="081594eb-5430-49b0-a068-7759bc62130e" 
-/dev/sda9: UUID="c32b5719-857f-48fb-a782-6086dd05d008" TYPE="crypto_LUKS" PARTUUID="9ce3fa3d-f995-4327-9989-520f938b6d5a" 
-/dev/mapper/luks-c32b5719-857f-48fb-a782-6086dd05d008: UUID="XRrOfA-n5wr-FdY2-oT8D-sLr9-hziR-UugtSv" TYPE="LVM2_member" 
-/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:
-
-root@localhost /: vi /etc/fstab
-#
-# /etc/fstab
-# Created by anaconda on Sat Sep 20 20:40:25 2014
-#
-# Accessible filesystems, by reference, are maintained under '/dev/disk'
-# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
-#
-/dev/mapper/fedora-root /                       ext4    defaults,x-systemd.device-timeout=0 1 1
-UUID=4821d546-440e-47da-8272-50a97f711c3e /boot                   ext4    defaults        1 2
-UUID=E085-2C94          /boot/efi               vfat    umask=0077,shortname=winnt 0 0
-/dev/mapper/fedora-home /home                   ext4    defaults,x-systemd.device-timeout=0 1 2
-/dev/mapper/fedora-swap swap                    swap    defaults,x-systemd.device-timeout=0 0 0
-~                                                                                                                                                      
-~                                                                                                                                                                                                                                                                                                      
-"/etc/fstab" 13L, 688C
-
-
-Looking at crypttab;
-Modifying crypttab:
-
-root@localhost /: vi /etc/crypttab
-luks-c32b5719-857f-48fb-a782-6086dd05d008 UUID=c32b5719-857f-48fb-a782-6086dd05d008 none
-~                                                                                                                                                      
-~                                                                                                                                                      
-~                                                                                                                                                      
-                                                                                                                         
-"/etc/crypttab" 1L, 90C
-
-
-Copying the Fedoara-created ESP files to the Microsoft-created ESP  (for whatever reason)
-
-# cd /mnt
-# mkdir msftesp
-# mount /dev/sda1 /mnt/msftesp
-# cd /boot/efi/EFI
-# cp -r * fedora /mnt/msftesp
-
-Verify the copy...
-
-# cd /mnt/msftesp
-# ls
-# cd fedora
-# ls
-# 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...
-
-menuentry 'Windows Boot Manager - Windows 8.1' {s
-
-	insmod part_gpt
-	insmod msdos
-	set root='hd0,gpt1'
-	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
-	boot
-}
-
-
 Refs:
 
 http://www.rodsbooks.com/efi-bootloaders/index.html
@@ -361,6 +253,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>