Efi Boot

Nov 27, 2017 UEFI is essentially a tiny operating system that runs on top of the PC’s firmware, and it can do a lot more than a BIOS. It may be stored in flash memory on the motherboard, or it may be loaded from a hard drive or network share at boot. Different PCs with UEFI will have different interfaces and features.

1. If Secure Boot keys aren't installed, you can select Install All Factory Default Keys and select either Windows & 3rd-party UEFI CA (Default) or Windows only. Configure Alternate System Boot Order To choose the order in which your Surface boots, select Configure Alternate System Boot Order and select one of the following options.
2. Jan 22, 2018 How to automatically restore EFI boot partition Windows 10. Open EaseUS Partition Master and click ' Partition Recovery ' on the top menu. A new window will pop up and ask you to select a disk to start searching for lost partition (s). So choose the desired disk and click ' Scan '.
3. EFI Boot Stub makes it possible to boot a Linux kernel image without the use of a conventional UEFI boot loader. By masquerading itself as a PE / COFF image and appearing to the firmware as a UEFI application, an x86 kernel image with EFI Boot Stub enabled can be directly loaded and executed by a UEFI firmware.

The EFI (Extensible Firmware Interface) system partition or ESP is a partition on a data storage device (usually a hard disk drive or solid-state drive) that is used by computers adhering to the Unified Extensible Firmware Interface (UEFI). When a computer is booted, UEFI firmware loads files stored on the ESP to start installed operating systems and various utilities.

An ESP contains the boot loaders or kernel images for all installed operating systems (which are contained in other partitions), device driver files for hardware devices present in a computer and used by the firmware at boot time, system utility programs that are intended to be run before an operating system is booted, and data files such as error logs.^[1]

Overview[edit]

The EFI system partition is formatted with a file system whose specification is based on the FAT file system and maintained as part of the UEFI specification; therefore, the file system specification is independent from the original FAT specification. The actual extent of divergence is unknown:^[2] Apple maintains a separate tool that should be used,^[3] while other systems use FAT utilities just fine.^[4] The globally unique identifier (GUID) for the EFI system partition in the GUID Partition Table (GPT) scheme is C12A7328-F81F-11D2-BA4B-00A0C93EC93B, while its ID in the master boot record (MBR) partition-table scheme is 0xEF. Both GPT- and MBR-partitioned disks can contain an EFI system partition, as UEFI firmware is required to support both partitioning schemes. Also, El Torito bootable format for CD-ROMs and DVDs is supported.^[1]

UEFI provides backward compatibility with legacy systems by reserving the first block (sector) of the partition for compatibility code, effectively creating a legacy boot sector. On legacy BIOS-based systems, the first sector of a partition is loaded into memory and execution is transferred to this code. UEFI firmware does not execute the code in the MBR, except when booting in legacy BIOS mode through the Compatibility Support Module (CSM).^[1]

The UEFI specification requires MBR partition tables to be fully supported.^[1] However, some UEFI implementations immediately switch to the BIOS-based CSM booting upon detecting certain types of partition table on the boot disk, effectively preventing UEFI booting to be performed from EFI system partitions contained on MBR-partitioned disks.^[5]

UEFI firmware supports booting from removable storage devices such as USB flash drives. For that purpose, a removable device is formatted with a FAT12, FAT16 or FAT32 file system, while a boot loader needs to be stored according to the standard ESP file hierarchy, or by providing a complete path of a boot loader to the system's boot manager. On the other hand, FAT32 is always expected on fixed drives.^[1]

Usage[edit]

Linux[edit]

GRUB 2 and elilo serve as conventional, full-fledged standalone UEFI boot loaders for Linux. Once loaded by a UEFI firmware, they both can access and boot kernel images from all devices, partitions and file systems they support, without being limited to the EFI system partition.

EFI Boot Stub makes it possible to boot a Linux kernel image without the use of a conventional UEFI boot loader. By masquerading itself as a PE/COFF image and appearing to the firmware as a UEFI application, an x86 kernel image with EFI Boot Stub enabled can be directly loaded and executed by a UEFI firmware. Such kernel images can still be loaded and run by BIOS-based boot loaders; thus, EFI Boot Stub allows a single kernel image to work in any boot environment.^[6]

Linux kernel's support for the EFI Boot Stub is enabled by turning on option CONFIG_EFI_STUB (EFI stub support) during the kernel configuration.^[7] It was merged into version 3.3 of the Linux kernel mainline, released on March 18, 2012.^[8]Gummiboot (a.k.a. systemd-boot) is a simple UEFI boot manager that loads and runs configured UEFI images, accessing only the EFI system partition. Configuration file fragments, kernel images and initrd images are required to reside on the EFI system partition, as Gummiboot does not provide support for accessing files on other partitions or file systems. Linux kernels need to be built with CONFIG_EFI_STUB enabled so they can be directly executed as UEFI images.^[9]

The mount point for the EFI system partition is usually /boot/efi, where its content is accessible after Linux is booted.^[10]

macOS[edit]

On macOS computers based on the x64 hardware architecture, the EFI system partition is initially left blank and unused for booting.^[11] However, the EFI system partition is used as a staging area for firmware updates.^[12] The logic usually goes as follows: the EFI first looks for a bootloader in ESP, and if there is none it will continue to the MacOS file system.^{[citation needed]}

The pre-UEFI Apple–Intel architecture (mactel) EFI subsystem used to require the EFI system partition to be formatted in HFS+. Any third-party bootloader also needs to be 'blessed' by a special IOCTL command before becoming bootable by the firmware, a relic of the system folder blessing from classic Mac OS. There is otherwise no limitations to what kinds of EFI operating system or bootloader a mactel machine can run.^[13][14]

Windows[edit]

On Windows XP 64-Bit Edition and later, access to the EFI system partition is obtained by running the mountvol /s command.

The Windows boot manager is located at the EFIMICROSOFTBOOT subfolder of the EFI system partition.

See also[edit]

References[edit]

1. ^ ^abcde'UEFI Specifications (versions 2.5 and older)'(PDF). UEFI.org. April 2015. Retrieved 2015-05-29.
2. ^'UEFI Specification Version 2.5, Section 12.3 File System Format'(PDF). UEFI.org. April 2015. pp. 536, 537. Retrieved 2015-05-29. The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.
3. ^'Technical Note TN2166: Secrets of the GPT'. Developer.Apple.com. 2006-11-06. Retrieved 2015-05-06.
4. ^'EFI system partition'. ArchWiki. Retrieved 14 March 2020.
5. ^'UEFI system booting from MBR partition table and GRUB legacy'. ArchLinux.org. June 2012. Retrieved 2013-10-06.
6. ^'Linux kernel documentation: Documentation/efi-stub.txt'. Kernel.org. 2014-06-16. Retrieved 2014-11-26.
7. ^'Linux kernel 3.11.1 arch/x86/Kconfig: CONFIG_EFI_STUB (line #1575)'. Kernel.org. Retrieved 2013-10-06.
8. ^'Linux kernel 3.3: 1.10. EFI boot support'. KernelNewbies.org. 2012-03-18. Retrieved 2013-10-06.
9. ^'gummiboot: Simple UEFI Boot Manager'. FreeDesktop.org. Archived from the original on 2013-09-12. Retrieved 2016-01-22.
10. ^'UEFI - Community Ubuntu Documentation'. Ubuntu.com. 2013-12-21. Retrieved 2013-12-27.
11. ^'rEFIt: Myths and Facts About Intel Macs – Myth: Mac OS X Requires a Hidden EFI System Partition'. rEFIt.SourceForge.net.
12. ^'Firmware updates for Intel-based Macs require a GUID partition scheme'. Apple Knowledgebase.
13. ^'Ubuntu + Mac: Pure EFI Boot'. The Slightly Disgruntled Scientist. Retrieved 17 November 2019.
14. ^'bless(8) Man Page'. macOS - SS64.com. [this is an earlier version that had Mac OS 9-specific flags]

External links[edit]

• EFI System Partition Subdirectory Registry – A registry of the subdirectories that lie below the /EFI directory on an EFI system partition

Linux[edit]

GRUB 2 and elilo serve as conventional, full-fledged standalone UEFI boot loaders for Linux. Once loaded by a UEFI firmware, they both can access and boot kernel images from all devices, partitions and file systems they support, without being limited to the EFI system partition.

EFI Boot Stub makes it possible to boot a Linux kernel image without the use of a conventional UEFI boot loader. By masquerading itself as a PE/COFF image and appearing to the firmware as a UEFI application, an x86 kernel image with EFI Boot Stub enabled can be directly loaded and executed by a UEFI firmware. Such kernel images can still be loaded and run by BIOS-based boot loaders; thus, EFI Boot Stub allows a single kernel image to work in any boot environment.^[6]

Linux kernel's support for the EFI Boot Stub is enabled by turning on option CONFIG_EFI_STUB (EFI stub support) during the kernel configuration.^[7] It was merged into version 3.3 of the Linux kernel mainline, released on March 18, 2012.^[8]Gummiboot (a.k.a. systemd-boot) is a simple UEFI boot manager that loads and runs configured UEFI images, accessing only the EFI system partition. Configuration file fragments, kernel images and initrd images are required to reside on the EFI system partition, as Gummiboot does not provide support for accessing files on other partitions or file systems. Linux kernels need to be built with CONFIG_EFI_STUB enabled so they can be directly executed as UEFI images.^[9]

The mount point for the EFI system partition is usually /boot/efi, where its content is accessible after Linux is booted.^[10]

macOS[edit]

On macOS computers based on the x64 hardware architecture, the EFI system partition is initially left blank and unused for booting.^[11] However, the EFI system partition is used as a staging area for firmware updates.^[12] The logic usually goes as follows: the EFI first looks for a bootloader in ESP, and if there is none it will continue to the MacOS file system.^{[citation needed]}

The pre-UEFI Apple–Intel architecture (mactel) EFI subsystem used to require the EFI system partition to be formatted in HFS+. Any third-party bootloader also needs to be 'blessed' by a special IOCTL command before becoming bootable by the firmware, a relic of the system folder blessing from classic Mac OS. There is otherwise no limitations to what kinds of EFI operating system or bootloader a mactel machine can run.^[13][14]

Windows[edit]

On Windows XP 64-Bit Edition and later, access to the EFI system partition is obtained by running the mountvol /s command.

The Windows boot manager is located at the EFIMICROSOFTBOOT subfolder of the EFI system partition.

See also[edit]

References[edit]

1. ^ ^abcde'UEFI Specifications (versions 2.5 and older)'(PDF). UEFI.org. April 2015. Retrieved 2015-05-29.
2. ^'UEFI Specification Version 2.5, Section 12.3 File System Format'(PDF). UEFI.org. April 2015. pp. 536, 537. Retrieved 2015-05-29. The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.
3. ^'Technical Note TN2166: Secrets of the GPT'. Developer.Apple.com. 2006-11-06. Retrieved 2015-05-06.
4. ^'EFI system partition'. ArchWiki. Retrieved 14 March 2020.
5. ^'UEFI system booting from MBR partition table and GRUB legacy'. ArchLinux.org. June 2012. Retrieved 2013-10-06.
6. ^'Linux kernel documentation: Documentation/efi-stub.txt'. Kernel.org. 2014-06-16. Retrieved 2014-11-26.
7. ^'Linux kernel 3.11.1 arch/x86/Kconfig: CONFIG_EFI_STUB (line #1575)'. Kernel.org. Retrieved 2013-10-06.
8. ^'Linux kernel 3.3: 1.10. EFI boot support'. KernelNewbies.org. 2012-03-18. Retrieved 2013-10-06.
9. ^'gummiboot: Simple UEFI Boot Manager'. FreeDesktop.org. Archived from the original on 2013-09-12. Retrieved 2016-01-22.
10. ^'UEFI - Community Ubuntu Documentation'. Ubuntu.com. 2013-12-21. Retrieved 2013-12-27.
11. ^'rEFIt: Myths and Facts About Intel Macs – Myth: Mac OS X Requires a Hidden EFI System Partition'. rEFIt.SourceForge.net.
12. ^'Firmware updates for Intel-based Macs require a GUID partition scheme'. Apple Knowledgebase.
13. ^'Ubuntu + Mac: Pure EFI Boot'. The Slightly Disgruntled Scientist. Retrieved 17 November 2019.
14. ^'bless(8) Man Page'. macOS - SS64.com. [this is an earlier version that had Mac OS 9-specific flags]

External links[edit]

• EFI System Partition Subdirectory Registry – A registry of the subdirectories that lie below the /EFI directory on an EFI system partition

Note

Some information in this section may apply only to Windows 10 Mobile and certain processor architectures.

A device running Windows 10 has several requirements for booting into the OS. After the device's firmware initializes all the hardware, the device needs to ensure that there is enough power to boot. Afterwards, the device needs to ensure that the device is booting into the appropriate OS depending on if the user wants to perform an update or a restore on the device, or if the user wants to boot the device into the main OS.

To accommodate each of these scenarios, the Windows 10 boot process uses the following components:

• Firmware boot loaders provided by the SoC vendor.

• UEFI (Unified Extensible Firmware Interface) environment provided by the SoC vendor.

• Windows Boot Manager provided by Microsoft.

This topic provides an overview of the boot process, and it describes the SoC firmware boot loaders, UEFI, and Windows Boot Manager in more detail.

Overview of the boot process

When a Windows 10 device is turned on, it goes through the following high-level process:

1. The device is powered on and runs the SoC-specific firmware boot loaders, which initialize the hardware on the device and provide emergency flashing functionality.

2. The firmware boot loaders boot the UEFI environment and hands over control to UEFI applications written by the SoC vendor, Microsoft, and OEMs. These applications can utilize UEFI drivers and services.

3. The UEFI environment launches the Windows Boot Manager, which determines whether to boot to FFU flashing or device reset mode, to the update OS, or to the main OS.

The following diagram illustrates this process at a high level.

Following are additional details about some of the components in this diagram:

• The update OS is a minimal OS environment provided by Microsoft. This OS is used specifically for installing updates.

• FFU flashing mode refers to a UEFI application that flashes an OS image to device storage. Microsoft provides a UEFI flashing application which can be used in non-manufacturing scenarios. OEMs can also implement their own UEFI flashing application.

SoC firmware boot loaders

The SoC firmware boot loaders initialize the minimal set of hardware required for the device to run. The SoC firmware boot loaders are designed to finish as fast as possible, and nothing is drawn to the screen while they are running. After the SoC firmware boot loaders finish, the device is booted into the UEFI environment.

The SoC firmware boot loaders also contain an emergency flashing capability that allows devices to be flashed when the boot environment is not stable and FFU-based flashing using the Microsoft-provided flashing tool is not possible. Emergency flashing requires tools specific to the SoC. For more information, contact the SoC vendor.

UEFI

Windows 10 utilizes the Unified Extensible Firmware Interface (UEFI) to support the handoff of system control from the SoC firmware boot loader to the OS. The UEFI environment is a minimal boot OS upon which devices are booted and the Windows 10 OS runs. For more information, see UEFI in Windows.

Understanding the Windows Boot Manager

The Windows Boot Manager is a Microsoft-provided UEFI application that sets up the boot environment. Inside the boot environment, individual boot applications started by the Boot Manager provide functionality for all customer-facing scenarios before the device boots.

Important

All components inside the boot environment are provided by Microsoft and cannot be modified, replaced, or omitted by OEMs.

Efi Boot Selection Windows 10

Boot applications implement functionality for the following scenarios:

• Charging the device battery before boot.

• Capturing and saving offline crash dumps (developer builds only).

• Flashing the device with a new image.

• Resetting the device.

• Updating the device.

• Booting the device to the main OS.

The following diagram illustrates some of the key portions of the process that the Boot Manager follows after it is launched by the UEFI environment.

The following steps describe this process in more detail:

Efi Boot Bootx64.efi

1. After the UEFI environment launches the Boot Manager, the Boot Manager initializes boot libraries, reads the boot configuration database to determine which boot applications to run and in which order to run them. The Boot Manager launches boot applications sequentially, and each application exits back to the Boot Manager after finishing.

   Boot libraries are libraries of functions that extend upon existing UEFI functionality, and are designed to be used within the boot environment. Only boot applications, which are launched by the Boot Manager, have access to the boot libraries.

2. The Boot Manager first captures any reserved hardware button combinations that are pressed by the user.

3. In non-retail OS images, the Boot Manager next runs an offline crash dump boot application which allows the device to capture a snapshot of physical memory from the previous OS session. When the device resets abnormally, the previous OS session's memory is preserved across the reset. When this happens, the offline crash dump application will save that memory and turn it into an offline crash dump file, which can be transferred off the device and analyzed. If the device did not reset abnormally in the previous OS session, the offline crash dump application exits immediately.

4. In all OS images, the Boot Manager next runs mobilestartup.efi. This application runs several boot libraries, some of which are only run on first boot (for example, to provision the secure boot policy) or only in non-retail images (for example, to enter USB mass storage mode). The following libraries are always run:

   1. First, mobilestartup.efi runs the library that implements UEFI battery charging. This library allows the user to charge their device while the device is in the boot environment (or is perceived as being turned off). This library is run first to ensure that the device has enough power to fully boot. For more information about scenarios involving the battery charging application, see Battery charging in the boot environment.

   2. Next, mobilestartup.efi runs the libraries that implement flashing, device reset, and updates. These libraries determine whether the device should boot to flashing or device reset mode, or if the device should continue to the Update OS or Main OS.

5. If mobilestartup.efi does not boot to flashing or device reset mode, the Boot Manager boots into the Main OS or the Update OS.

Efi Boot Devices

Related topics