MBR vs. GPT and BIOS vs. UEFI

grub1-1 previewed this distinction just enough to make sense of everything since. This is the chapter every dual-boot scenario in this course actually depends on — the full structural difference between MBR and GPT, and between BIOS and UEFI, in enough depth to explain the real failures those combinations produce.

MBR — The Legacy Partition Table

The Master Boot Record lives in the disk's first 512-byte sector: 446 bytes for boot code (grub1-2's own boot.img), 64 bytes for the partition table itself — four 16-byte entries, no more — and 2 bytes for a boot signature. Exactly four primary partitions is a hard limit baked directly into that 64-byte structure, not a soft recommendation. The historical workaround — converting one primary slot into an "extended" partition that holds further logical partitions — exists purely to route around this. 32-bit sector addressing caps a usable disk at roughly 2TiB, a genuine ceiling MBR cannot exceed.

GPT — The Modern Partition Table

GPT stores partition information in a proper table structure rather than squeezing it into 64 bytes, using 64-bit addressing — no meaningful size limit for the foreseeable future — and supports up to 128 partitions by default, with no extended/logical workaround needed. Genuinely more resilient, too: GPT keeps a full backup copy of its own partition table at the end of the disk, plus checksums, rather than MBR's single, unprotected copy sitting at the very start. And every GPT disk carries a protective MBR at sector 0 — a deliberate dummy MBR entry, present specifically so older tools that only understand MBR don't mistake a GPT disk for empty space and overwrite it.

BIOS vs. UEFI — Revisited in Full

UEFI is, in real terms, its own small, standardized pre-OS operating environment. It can run programs — drivers, bootloaders — directly from a real FAT filesystem, and it maintains its own persistent, NVRAM-stored list of boot entries (viewable and editable with efibootmgr), independent of any disk's own partition table. BIOS has none of this: no persistent boot-entry storage of its own, no native filesystem reading — exactly why GRUB needs the staged bootstrap grub1-2 described, and exactly why that bootstrap only exists on BIOS systems in the first place.

Which Combinations Actually Work

This is the precise, technical version of grub1-1's own warn-box: those off-diagonal combinations are where mismatched-boot-mode confusion genuinely originates.

Secure Boot — Briefly

A UEFI-specific feature: firmware refuses to execute any bootloader that isn't cryptographically signed by a trusted key. Some Linux distributions ship a GRUB build signed via a small intermediary ("shim") layer specifically to work with Secure Boot out of the box; others require disabling Secure Boot, or manually enrolling a key, before their own bootloader will run at all. A genuinely practical concern for grub1-6/grub1-7's own dual-boot scenarios — named here deliberately briefly, not covered exhaustively.

Revisiting pc_build_11's Own Material

pc_build_11 covered BIOS/UEFI at the hardware level — how to enter your firmware's own settings screen while building a PC. This chapter goes deeper on a genuinely different question that chapter never addressed: not "how do I access these settings," but "what is the actual structural difference in how each firmware model finds and executes a bootloader in the first place."

Hands-On Exercises