Firmware and disk: BIOS/UEFI, MBR/GPT

Why this matters

A server won't boot, and the screen shows No bootable device. Or you're installing a system on a new disk and the installer asks which partition table to create. In both cases you need to understand two things: which firmware the machine runs and how the disk is partitioned. This pair decides where the bootloader lives and who finds it.

Where power-on starts

The moment power reaches the board, firmware takes over: code burned into a chip on the motherboard. First it runs POST (power-on self-test), a hardware self-check: memory, CPU, basic controllers. If something critical is broken, boot stops right there, and you hear a series of beeps or see an error code.

After a successful POST, firmware looks for where to boot from and hands control to the bootloader. From there the chain looks like this:

firmware -> bootloader -> kernel -> initramfs

initramfs is a temporary filesystem root unpacked into memory (into rootfs; if the kernel has CONFIG_TMPFS enabled, that's tmpfs, otherwise ramfs). It carries the drivers needed to mount the real root from disk.

BIOS vs UEFI

Firmware comes in two generations. The old mode is BIOS (basic input/output system). It doesn't understand filesystems: it just reads the boot code from the disk's first sector and runs it. You can look at that sector yourself (needs root):

sudo dd if=/dev/sda bs=512 count=1 2>/dev/null | od -A d -t x1 | tail -n 4

The new mode is UEFI (unified extensible firmware interface). It can read a filesystem on a dedicated partition called the EFI System Partition (ESP, usually FAT32). Bootloaders sit there as plain .efi files. On Ubuntu the ESP is mounted at /boot/efi, example contents:

ls /boot/efi/EFI/

BOOT  ubuntu

UEFI has one more trick. You can build the Linux kernel with an EFI stub: then the kernel file looks to firmware like a regular EFI application, and UEFI runs it directly, with no separate bootloader.

UEFI keeps its boot entries itself, in firmware memory. efibootmgr shows them (example line):

efibootmgr -v

Boot0001* Linux	HD(1,GPT,...)/File(\EFI\Linux\vmlinuz.efi)

MBR: the old layout

How a disk is partitioned is tied to the firmware mode. The classic one is MBR (master boot record). It's the disk's very first sector (sector 0), 512 bytes:

Bytes	What's there
0-445	primary bootloader code (446 bytes)
446-509	partition table: 4 entries of 16 bytes
510-511	signature 55 aa

Without the 55 aa signature, neither BIOS nor the Linux kernel treats the sector as an MBR table. In each table entry the fifth byte (offset 4 within the entry) is the partition type. A few common types:

Type	What it means
83	Linux partition
82	Linux swap
ef	EFI System Partition
ee	protective MBR in front of GPT (see below)
00	empty entry

MBR has hard limits. The sector number is stored in 32 bits, so with a 512-byte sector it can address no more than 2 TiB (about 2.2 TB). There are four entries in the table, so there can't be more than four primary partitions. You can work around this with an extended partition holding logical partitions inside it.

The fdisk utility from util-linux calls MBR dos:

sudo fdisk -l /dev/sda

Disklabel type: dos

GPT: the modern layout

GPT (GUID partition table) removes MBR's limits. Sector numbers are 64-bit, so the 2 TiB ceiling disappears. By default there's room in the table for 128 partitions, and extended partitions are no longer needed.

A GPT disk is laid out like this:

• sector 0: a protective MBR, one entry with type ee covering the whole disk. An old utility that only understands MBR sees "disk occupied by an unknown partition" and won't try to repartition it;
• sector 1: the GPT header, starting with the string EFI PART;
• from sector 2 on: the array of partition entries;
• at the end of the disk: a copy of the entry array, and in the very last sector a copy of the header.

The header and entries are protected by CRC32 checksums. If the primary table at the start gets corrupted, tools find the copy at the end and offer to restore the primary one. That's what the Linux kernel, fdisk, and gdisk all do.

gdisk -l prints what it found on the disk before listing partitions:

sudo gdisk -l /dev/sda

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

MBR: protective means there's a protective MBR in sector 0, and GPT: present means a GPT table was found.

In practice, disks under UEFI are laid out as GPT: that's where the ESP lives, and firmware reads the bootloader or kernel from it. There's no hard rule: an ESP can also sit on an MBR disk (type ef), and such systems do exist. It buys you nothing, though, and some UEFI implementations won't boot from MBR, so "UEFI plus GPT" is considered the normal pairing. The reverse combination also happens: GRUB boots a system from a GPT disk on a BIOS machine, if the disk has a small BIOS boot partition where GRUB puts its main code.

The difference in short:

Property	MBR	GPT
Where the table lives	sector 0	sector 1 onward, copy at the end of the disk
Disk size limit	2 TiB with a 512-byte sector	practically none
Partitions	4 primary	128 by default
Usual pairing	BIOS	UEFI (with an ESP)

What the system does next

Once the kernel has unpacked initramfs and mounted the real root, the first process takes over. On most distributions that's systemd, the system manager that starts the remaining services from unit files. It brings up independent services in parallel.

systemctl get-default

graphical.target

The boot goal is described through targets, which depend on each other:

graphical.target -> multi-user.target -> basic.target -> sysinit.target

The arrows show dependency, not a strict step-by-step order. Targets are covered in detail in the systemd lesson.

Common mistakes

• "UEFI is just BIOS with a new name." No. UEFI understands partitions and files, keeps its own list of boot entries, and can launch the kernel with no intermediate bootloader.
• "GPT is only for big disks." Size is just one reason for it. People use GPT for the partition count and the table copy even on disks under 2 TiB.
• "There's an ESP, so the disk is GPT." An ESP can sit on MBR too, as an entry with type ef. The table decides the layout, not the set of partitions.
• "No EFI PART in sector 1, so there's no GPT." The primary header may have been corrupted. Check the entry type in sector 0 (ee) and the disk's last sector: that's where the header copy lives.
• Looking at raw bytes with od without -A d. By default od prints offsets in octal, and it's easy to mistake 0000776 for the 776th byte (it's actually the 510th).

What to remember

POST is the hardware self-check at power-on, before any bootloader.

BIOS reads raw code from sector 0, UEFI reads files from the EFI System Partition and can boot the kernel directly through an EFI stub.

MBR is sector 0: 446 bytes of code, 4 table entries, signature 55 aa. Up to 2 TiB and 4 primary partitions.

GPT is a protective MBR with type ee, an EFI PART header in sector 1, and its copy in the last sector. In practice GPT is used under UEFI, though an ESP can also sit on an MBR disk.

In the next lesson we'll look at how the bootloader passes parameters to the kernel and what ends up on the kernel command line.

What you'll need for the tasks

• The layout of sector 0: where the partition table is, where the entry type is, where the signature is.
• Entry types 83, 82, ef, ee, and the empty entry.
• Where to look for the GPT header and its copy.
• The commands od -A d -t x1 -j <offset> -N <count> <file>, od -c, and tail -c 512 <file>. Docker isn't needed.