What is the practical difference between booting an x86-64 machine in legacy BIOS mode and booting it via UEFI, and what does the firmware load in each case?

## Two entirely different contracts BIOS and UEFI are not two versions of the same thing; they are different agreements about *what the firmware will look for on a disk*. ## Legacy BIOS After power-on self-test, BIOS firmware picks a disk from its configured boot order, reads sector zero — the **Master Boot Record** — into memory, and jumps to the start of it. That sector is 512 bytes: 440 bytes of boot code, a disk signature, the four-entry partition table, and a signature. The firmware does not parse the partition table and has no filesystem drivers; it just executes code. 440 bytes is nowhere near enough to read ext4 or XFS, so GRUB2 splits itself. The MBR code loads `core.img`, which lives either in the unused gap between the MBR and the first partition (on MBR-partitioned disks) or, on GPT disks booted via BIOS, in a small dedicated **BIOS boot partition**. `core.img` contains the filesystem driver needed to reach `/boot/grub/` and continue. The whole arrangement is fragile: the bootstrap code lives outside any filesystem, so nothing protects it, and two operating systems installed on one disk simply overwrite each other's 440 bytes. ## UEFI UEFI firmware is a small operating system in its own right. It understands GPT partitioning and can read FAT, so instead of raw sector code the contract is: put a **normal file** on a **normal filesystem**. That filesystem is the **EFI System Partition** (ESP) — a FAT-formatted partition, on Linux conventionally mounted at `/boot/efi` — and it holds vendor directories such as `/boot/efi/EFI/<distro>/` containing `.efi` applications. Which one gets loaded is decided by boot entries stored in the firmware's own NVRAM, each pointing at a device and a file path, ordered by a boot order variable. On Linux `efibootmgr` reads and manipulates them: ```bash [ -d /sys/firmware/efi ] && echo "booted via UEFI" || echo "booted via legacy BIOS" sudo efibootmgr -v ``` Because each OS gets its own entry and its own directory, installing a second distribution does not clobber the first. There is also a fixed **removable-media fallback path** — `\EFI\BOOT\BOOTX64.EFI` on the ESP — used when no NVRAM entry matches, which is how installation media boots on a machine that has never seen it. UEFI can also load a kernel directly when the kernel is built with an EFI stub, skipping GRUB2 entirely; the kernel image is then itself a valid `.efi` application. ## What actually changes for you **Partitioning.** MBR's partition table has four primary entries and 32-bit sector addresses, capping usable disks at 2 TiB. GPT, which UEFI expects, has neither limit. You *can* boot GPT under BIOS, but only via the BIOS boot partition hack above. **Verification.** Secure Boot exists only under UEFI: the firmware checks the signature of the `.efi` it is about to load against keys it holds. There is no equivalent for MBR boot code, which is precisely why bootkits targeted it. **Recoverability.** A UEFI boot problem is usually a file or an NVRAM entry — both inspectable and fixable from a rescue shell. A BIOS boot problem may be damaged code in a sector with no filesystem around it. **Mode mismatch.** This is the failure people actually meet. Installing while the firmware is in UEFI mode writes an ESP and an NVRAM entry, and nothing useful into the MBR; switching the firmware to legacy afterwards produces "no bootable device". The reverse holds too. Some firmware exposes a Compatibility Support Module that emulates BIOS, and mixing the two during installation and later boots is a common self-inflicted outage. The check is one line: `/sys/firmware/efi` exists only on a UEFI boot. ## What stays identical Everything after the handoff. Once GRUB2 (or the EFI stub) has control, the kernel, the initramfs, the root pivot and PID 1 behave exactly the same. The firmware distinction is entirely about the first few hundred milliseconds and where the boot artefacts live.