Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Boot

BIOS

The BIOS in modern PCs initializes and tests the system hardware components (Power-on self-test), and loads a boot loader from a mass storage device which then initializes a kernel. In the era of DOS, the BIOS provided BIOS interrupt calls for the keyboard, display, storage, and other input/output (I/O) devices that standardized an interface to application programs and the operating system. More recent operating systems do not use the BIOS interrupt calls after startup.[6]

Boot Sequence

  • System switched on, the power-on self-test (POST) is executed.
  • After POST, BIOS initializes the hardware required for booting (disk, keyboard controllers etc.).
  • BIOS launches the first 440 bytes (the Master Boot Record bootstrap code area) of the first disk in the BIOS disk order.
  • The boot loader's first stage in the MBR boot code then launches its second stage code (if any) from either:
    • Next disk sectors after the MBR, i.e. the so called post-MBR gap (only on a MBR partition table),
    • A partition's or a partitionless disk's volume boot record (VBR),
    • For GRUB on a GPT partitioned disk—a GRUB-specific BIOS boot partition (it is used in place of the post-MBR gap that does not exist in GPT).
  • The actual boot loader is launched.
  • The boot loader then loads an operating system by either chain-loading or directly loading the operating system kernel.

UEFI

UEFI launches EFI applications, e.g. boot loaders, boot managers, UEFI shell, etc. These applications are usually stored as files in the EFI system partition. Each vendor can store its files in the EFI system partition under the /EFI/vendor_name directory. The applications can be launched by adding a boot entry to the NVRAM or from the UEFI shell.

Boot Sequence

  • System switched on, the power-on self-test (POST) is executed.
  • After POST, UEFI initializes the hardware required for booting (disk, keyboard controllers etc.).
  • Firmware reads the boot entries in the NVRAM to determine which EFI application to launch and from where (e.g. from which disk and partition).
  • A boot entry could simply be a disk. In this case the firmware looks for an EFI system partition on that disk and tries to find an EFI application in the fallback boot path EFIBOOTBOOTx64.EFI (BOOTIA32.EFI on systems with a IA32 (32-bit) UEFI). This is how UEFI bootable removable media work.
  • Firmware launches the EFI application.
    • This could be a boot loader or the Arch kernel itself using EFISTUB.
    • It could be some other EFI application such as the UEFI shell or a boot manager like systemd-boot or rEFInd.
  • If Secure Boot is enabled, the boot process will verify authenticity of the EFI binary by signature.