Added more material and shuffled things around. Still working on setting up framework for article

1 files changed, 151 insertions, 19 deletions

diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index e23da5c..da24fc7 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -7,37 +7,65 @@
 <section id="UEFI-win">
   <title>Booting with Windows</title>
   <para>
+  The good news is that 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.
+  
   Notes:
   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
+ --------------------------------------------------------------------------------
+ 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. These EFI applications then call winload.efi as the boot loader. winload.efi is located at /WINDOWS/System32/Boot.
+ 
+  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...
   
-  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.
+  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 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 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 bootx64.efi.
+  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.
   
   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 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. 
   
-  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. 
+  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.
   
-  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.
+    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.
+  
+  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. 
+  
+  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.
   
+  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. 
+  
+    GRUB2, on the other hand, is designed from the gound up to handle all forms of operating systems.
+  
+    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:
+  
+  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.
+  -----------------------------
   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.
+  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.
   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.
@@ -48,24 +76,128 @@ It will boot to the first removable device that meets that criteria. When you en
 
   ------------------- 
   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.
+  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. 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. 
+  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. 
   
   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/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 -- 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-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.
  ----------------------------------------------
 
-  
-  
-  
+ File system stuff:
+  
+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
+
+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
+
+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" 
+
+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
+
+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' {
+	insmod part_gpt
+	insmod msdos
+	set root='hd0,gpt1'
+	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
+	boot
+}
+
+
   </para>
 </section>