Waking Up the Machine
The very first software that runs on any x86 computer is not Linux — it is firmware embedded on a chip on the motherboard. This firmware has one job: perform a basic sanity check on the hardware and then find something bootable to hand control to.
The Old Way: BIOS (Basic Input/Output System)
For decades, every PC used BIOS firmware. When powered on, the BIOS runs a Power-On Self-Test (POST) — it checks that RAM is present and functional, that the CPU is operating correctly, and that essential hardware is responding. If POST fails, you get a series of beep codes (literally beeps from a speaker) indicating what went wrong, because the system can't even display an error message yet.
After POST, the BIOS uses a brutally simple boot strategy: it reads the very first 512-byte sector of the configured boot disk. This sector is called the Master Boot Record (MBR). The last two bytes of a valid MBR are a magic number (0x55AA) that tells the BIOS "yes, this is bootable." The BIOS loads those 512 bytes into RAM at a fixed address (0x7C00) and jumps to it. That tiny 512-byte program is the first stage of the bootloader.
The MBR scheme has severe limitations. 512 bytes is barely enough to hold a "stage 1" bootloader that knows how to find and load a larger "stage 2" bootloader. MBR also only supports disks up to 2 TB and a maximum of 4 primary partitions.
The Modern Way: UEFI (Unified Extensible Firmware Interface)
UEFI replaces BIOS with a far more capable firmware environment. It is essentially a small operating system in its own right — it has its own drivers, can read FAT32 filesystems, supports a graphical interface, and can even run network applications before the OS boots.
UEFI uses the GUID Partition Table (GPT) instead of MBR, supporting disks up to 9.4 ZB and up to 128 partitions by default. Rather than blindly executing the first sector of a disk, UEFI looks for a dedicated EFI System Partition (ESP) — a FAT32-formatted partition containing .efi executable files. UEFI maintains a prioritized list of these boot entries in non-volatile RAM (NVRAM), which you can inspect and modify with the efibootmgr command — it reports which entry was used for the current boot, the priority order UEFI will try them in, and the label and .efi file path for each registered entry, such as a Windows Boot Manager entry alongside a Linux distro's shimx64.efi.
Secure Boot is a critical UEFI feature. Before executing any .efi file, UEFI checks its cryptographic signature against a database of trusted keys stored in firmware. If the signature is invalid or absent, UEFI refuses to run it. This prevents bootkits — malware that installs itself in the bootloader to persist across OS reinstalls and evade antivirus software. On Linux, the chain is: UEFI trusts Microsoft's key → Microsoft's key signs shim.efi → shim.efi trusts Canonical/Red Hat's key → that key signs GRUB → GRUB is allowed to run.
Interviewers frequently ask: "What is Secure Boot and why does it matter?" A weak answer describes it as "a security feature that checks signatures." A strong answer explains the chain of trust: UEFI firmware holds a root key, each link in the chain (shim → GRUB → kernel) is signed by the previous link's key, and breaking any link prevents boot. Follow up by mentioning that Secure Boot protects against bootkits specifically — malware that survives OS reinstallation by living in the bootloader layer.