First, separate the concepts
MBR (Master Boot Record) and GPT (GUID Partition Table) are disk-partitioning formats. They describe partitions and, in the legacy MBR layout, reserve a small area for bootstrap code.
BIOS and UEFI are firmware environments. They initialize enough hardware to begin loading software. A bootloader is the software that then loads an operating system kernel or another boot stage.
These terms are related, but they are not interchangeable: GPT is not a bootloader, and MBR is not the same thing as BIOS.
Legacy BIOS + MBR boot path
- After reset, platform firmware performs early initialization and selects a boot device according to its boot order.
- For a traditional BIOS boot from a hard disk, firmware reads the disk's first logical sector—commonly 512 bytes—into memory and transfers control to its bootstrap code if the sector is valid.
- The MBR layout contains bootstrap code, a four-entry partition table, and the signature
0x55AAat the end of the sector. With a conventional 512-byte sector, these occupy 446, 64, and 2 bytes respectively. - The initial code is very small. Depending on the bootloader, it may locate a later stage in a known disk area or find an active partition and chain-load its boot sector.
- Later bootloader stages load the operating-system kernel and, on Linux, usually an initramfs/initrd when configured. Control then passes to the kernel.
The exact stages vary by bootloader and operating system. Modern bootloaders often split their work across several stages because the MBR's initial code area is so limited.
UEFI + GPT boot path
- UEFI firmware initializes the platform and reads its boot configuration, commonly from NVRAM boot entries.
- A boot entry identifies an EFI executable on a supported filesystem, usually on the EFI System Partition (ESP).
- The ESP is commonly formatted as FAT32 and contains files such as a vendor boot manager, GRUB's EFI application, or a Windows Boot Manager executable.
- UEFI loads and launches the selected EFI application. That bootloader can load the kernel and any required supporting files.
- The bootloader transfers control to the operating system using the platform's supported hand-off procedure.
GPT commonly accompanies UEFI installations, but the key distinction is the firmware's boot mode and the bootloader format. UEFI does not execute legacy MBR bootstrap code as its normal disk-boot mechanism.
What is stored in GPT?
GPT stores a protective MBR at the beginning of the disk for compatibility with older disk tools, followed by a GPT header and partition-entry array. It also keeps backup GPT metadata near the end of the disk.
- Partition type GUIDs: identify the intended type of each partition, such as an EFI System Partition.
- Partition GUIDs: uniquely identify individual partitions.
- CRC checksums: help detect corruption in the GPT header and partition-entry array.
- Backup metadata: provides a secondary copy of the GPT structures, typically at the end of the disk.
The protective MBR is not the UEFI bootloader. It mainly helps prevent MBR-only tools from treating a GPT disk as empty and overwriting its partitions.
MBR vs. GPT at a glance
| Characteristic | MBR | GPT |
|---|---|---|
| Partition metadata | Partition table in the first sector | Header and partition-entry array, with backup metadata |
| Partition count | Four primary entries; extended partitions can provide logical partitions | Many partitions; the supported count depends on the implementation |
| Disk size | Commonly limited to about 2 TiB with 512-byte logical sectors | Supports much larger disks; practical limits depend on implementation |
| Integrity | No equivalent checksums for the partition table | CRC checksums for GPT metadata |
| Typical boot pairing | Legacy BIOS boot often uses MBR | UEFI boot commonly uses GPT and an ESP |
Where does the bootloader live?
With a classic BIOS/MBR installation, the first boot stage is often in the MBR and later stages may be stored elsewhere on disk. With UEFI, the firmware normally loads an EFI executable from the ESP; it does not need to execute a boot program from the MBR.
Linux distributions can use GRUB, systemd-boot, or another boot manager depending on the configuration. Windows uses Windows Boot Manager. The partition layout and firmware mode influence how the boot files are installed and discovered.
Debugging checklist
- Check whether the machine is booted in legacy BIOS/CSM mode or native UEFI mode.
- Inspect the partition table with a suitable tool such as
fdisk -lorparted -l. - For UEFI, confirm that the ESP exists, is readable, and contains the expected EFI executable.
- Check firmware boot entries with
efibootmgr -vwhen running Linux on a system booted through UEFI. - Verify that the installed bootloader matches the intended firmware mode; a valid kernel file alone does not guarantee a bootable system.
- Back up important data before changing partition tables or boot configuration.
Key takeaway
Think of the boot sequence as a chain: firmware → bootloader → kernel. MBR or GPT describes the disk's partition layout; BIOS or UEFI determines the firmware boot environment and how the first boot software is located and launched.
This guide describes common PC boot paths. Firmware implementations, bootloaders, storage devices, and operating-system installation choices can differ.