Clarified Default BOot Behavior on UEFI

1 files changed, 21 insertions, 3 deletions

diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 3eb9e4b..1fb6fd3 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -42,14 +42,32 @@
   
   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. When finished, it directs execution back to EFI Boot Manager to boot the first one it found. It does this by changing the BootOrder 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 in the event that there are either no existing NVRAM entires for any installed operating systems or that the entries that were there resulted in a 'no boot' situation from all installed, fixed devices.
+    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.
   
+  Note 1:
   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 (calling \EFI\Boot\bootx64.efi as a 'last resort') provides a way to place boot entries into the EFI NVRAM by a process that uses an EFI application, typically called fallback.efi.
+  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.
   
-  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. You will notice a short delay in getting into the EFI Settings having pressed the 'magic' key during power on. That is because the enumeration process is still ongoing and adding entries for the USB key you just inserted. Once the enumeration process has completed, you have interruped the boot process and are presented with the EFI Boot Manager Menu and can make your selection.
+  Note 2:
+  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.
+  ----------------------------------------------------
+  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.
+ 
+  End of caveat
+  ------------------------------------------------------
   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.