Product SiteDocumentation Site

8. Multiboot on UEFI Systems

8.1. UEFI Basics

This section of the guide covers the UEFI boot process in general and how Fedora successfully handles a Secure Boot environment.
We hope that you will find this information both interesting and helpful. With the information outlined in this and other sections of 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 and here

8.1.1. EFI Boot Sequence Explained

In this section we will consider 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 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.
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.
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.
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.
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."
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.
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.

8.1.2. What is Default Boot Behavior?"

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.
It begins by enumerating all removable devices and then passing execution to the first instance of bootx64.efi it finds.
bootx64.efi uses fallback.efi to scan the entire EFI partition looking for boot.csv files in each sub-directory within the EFI partition. Everytime it finds one, fallback.efi 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.

8.1.3. "What is Fallback and How Does it Work?"

The reason this process is referred to as "fallback" is because, as noted above, bootx64.efi checks to see if a file named fallback.efi is in the same directory as itself, and if so, will execute it as an EFI application.
It is the fallback.efi application that enumerates the various boot.csv 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.
The Default Boot Behavior, which initiates fallback, happens in the event that any of the following conditions are met:
  1. There aren't any existing NVRAM entires for any installed operating systems
  2. That the entries that were listed in the BootOrder resulted in a 'no boot' situation from all installed, fixed devices
  3. 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.
Before moving on, I would like to add a few notes to help clariy the above information:
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.
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.
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 it may never get to the point where it loads fallback.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.