The EFI boot process.

What is the boot process employed by EFI (Extensible Firmware Interface) machine firmware?

This is the Frequently Given Answer to such questions.

Bootstrapping on EFI involves a boot manager that is built in to the firmware. EFI systems do not rely upon bootstrap programs stored in boot records (VBRs or MBRs) at all. The firmware knows how to read a partition table and understands the FAT filesystem format. (IBM PC compatible firmware does neither.) A designated partition, that is formatted with the FAT filesystem format and identified with a specific well-known partition type, is known as the EFI System Partition. (The EFI System Partition has type 0xEF in the MBR Partition Table scheme, and a specific, well-known, GUID in the GUID Partition Table scheme.) It contains boot loader programs, which are EFI executable programs that are loaded and run by the EFI boot manager.

The details of the boot manager are up to the firmware implementor, but all boot managers are configured using well-known EFI variables, which are publicly defined and documented mechanisms for holding firmware configuration data. Boot managers are required to inspect the BootOrder EFI variable for a list of EFI boot options. A boot option contains the device and path name of an EFI executable program to load and run, and a set of parameters to pass to that program.

If there is no BootOrder EFI variable, EFI boot managers are required to enumerate all removable DASDs and fixed DASDs. For removable DASDs, the disc is treated as containing a single volume. For fixed DASDs, the disc is searched for an EFI system partition and that volume is used. In both cases, EFI boot managers look for an EFI executable program to run stored in the designated volume and called "\EFI\BOOT\BOOTtype.EFI" (where type is "IA32", "IA64", or some other such string, according to CPU architecture). This is a default operating system boot loader.

EFI executable programs are standalone programs, that use only machine firmware services and that do not require and underlying operating system in order to run. They can be either operating system boot loaders or "pre-boot" maintenance/diagnosis programs. By convention, all of the boot loaders for operating systems are stored in the EFI system partition on a partitionable DASD, in a vendor-specific subdirectory of the "\EFI\" directory.

Boot loaders

For the 64-bit x86 versions of Windows NT 5.x, the EFI boot loader is "\EFI\Microsoft\Boot\IA64LDR.EFI", which comprises NTLDR, the Windows NT boot loader that loads and executes the Windows NT kernel from files in the system volume.

64-bit x86 versions of Windows NT 5.x use EFI as it was designed to be used.

For Windows NT 6, the EFI boot loader is "\EFI\Microsoft\Boot\Bootmgfw.efi", which is the Microsoft Boot Manager — another boot manager, which presents a second menu of boot options, read from a database file in a Microsoft-proprietary format, which in turn list boot loader programs to invoke and options to pass to them.

Windows NT 6 needlessly duplicates the functionality of the EFI boot manager, and needlessly makes a user-visible distinction between all other operating systems (listed on the first boot manager menu, which Microsoft configures to be displayed for only 2 seconds in order to, in Microsoft's own words, "make it easier" for users) and Windows NT (listed on the second boot manager menu).

For the 64-bit x86 versions of Linux, the EFI boot loader is either "\EFI\RedHat\elilo.efi" or "\EFI\SuSE\elilo.efi", which comprises a modified version of LILO, the Linux boot loader that loads and executes the Linux kernel from files in the system volume.

ELILO, like the Microsoft Boot Manager, contains a second level of boot options, held in a separate elilo.conf configuration file, rather than integrating support for such multiple boot options into the EFI boot loader and EFI variables, as it should. Unlike the Microsoft Boot Manager, however, ELILO is a boot loader, incapable of loading any other operating system but Linux (the different boot options merely allowing one to specify which Linux kernel image file to use and various options specific to the Linux kernel such as the ramdisc size), not a boot manager, and so does not needlessly duplicate all of the functionality of the EFI boot manager.

For HP-UX, the EFI boot loader is "\EFI\HPUX\hpux.efi", which loads and executes the HP-UX kernel from an image file in the system volume (e.g. /vmlinux). The HP-UX boot loader also comprises an interactive shell, although the EFI Shell that comes with the EFI firmware provides much the same functionality.

How Apple makes even Microsoft seem well-behaved and conformant

Apple ignores or subverts large parts of the EFI specification on its Intel Macintoshes. The EFI System Partition is empty and unused, and the EFI boot manager is obscured by an Apple boot loader that is executed before it.

The Apple EFI firmware understands the HFS+ filesystem format, in addition to the FAT filesystem format mandated by the EFI specification. Apple's firmware boot loader reads the value of a variable stored in NVRAM. This can either point to a disc partition or to a specific file, depending from whether one has "blessed" a disc partition or a file/directory using the bless utility. (Blessing a directory is a shorthand for copying a platform-specific boot loader file into that directory and then blessing the file.)

If the value in NVRAM points to a disc partition, then the Apple boot loader assumes that this is an HFS+ formatted volume. HFS+ contains a file ID pointer in its volume header that points to a boot file. The Apple boot loader reads the HFS+ volume header, and loads and runs the indicated file as an EFI application. By default, this is "/System/Library/CoreServices/boot.efi", the boot loader for MacOS X.

If the value in NVRAM points to a specific file, that is the EFI executable that the Apple boot loader loads at boot, ignoring what any HFS+ volume headers may contain. One such file is xom.efi, an alternative EFI operating system boot loader application that loads Windows NT XP on Intel Macintoshes.

If, in either case, the EFI application is non-graphical, its user interface won't be seen, because the Apple boot loader switches the display to graphical mode. If the application exits, returning to the firmware, the EFI boot manager is finally invoked. But since the EFI boot manager has a textual user interface, its user interface will not be visible, either. (A TextMode.efi EFI application is freely available that simply switches the display back to text mode and returns to the firmware.)