Linux Disk Layout

Plan and understand a Linux disk

This is a static reference to the regions of a GPT-partitioned Linux disk. The examples below describe fields and planning choices; this page does not calculate a layout or inspect a connected disk.

Read the disk from front metadata to recovery metadata

1. Protective MBRSector zero
2. Primary GPT headerNormally LBA 1
3. Partition entriesCommonly begin at LBA 2
4. Usable partition spaceESP, root and other planned partitions
5. Backup entriesNear the end
6. Backup GPT headerFinal LBA

Conceptual regions, not to scale. Backup GPT repeats partition metadata; it does not back up file contents.

Then follow the firmware handoff

1. UEFIReads GPT to find the ESP
2. ESP loaderSelects kernel and initramfs
3. InitramfsPrepares storage and locates root
4. LinuxMounts the installed system

01 · sector zero The protective MBR speaks to older tools

A GPT disk still begins with a 512-byte Master Boot Record. Its job is compatibility, not modern partition discovery: one partition entry normally uses type 0xEE to claim the disk and discourage MBR-only software from overwriting it.

The last two bytes must be 0x55 and 0xAA. Between the optional boot-code area and that signature sit a disk identifier, two reserved bytes, and four legacy 16-byte partition entries.

A fixed byte-offset example

Byte 510 (0x1FE) contains 0x55, the first byte of the boot signature. This is a documented field, not a selected value read from a disk.

Offset 0x1FE / 510

Value 0x55

Function Boot signature · first byte Must be 0x55 as the first half of the 0x55AA boot-record signature.

02 · primary metadata GPT describes the real partition map

The primary GPT header normally lives at logical block address 1. It identifies the disk, records the usable LBA range, points to the partition-entry array, and stores CRC32 checksums so damage can be detected.

Each GPT partition entry carries a type GUID, a unique partition GUID, starting and ending LBAs, attributes, and a UTF-16 name. Linux tools use this table—not the protective MBR—to locate the ESP, root filesystem, swap, and other partitions.

Reference fields Primary GPT header, field by field

This field list describes the primary GPT header sector at LBA 1. The header points to the partition-entry array that follows it.

Signature 0x000-0x007, EFI PART
ASCII bytes that identify this sector as a GPT header. Revision 0x008-0x00B
GPT revision, commonly 00 00 01 00 for revision 1.0. Header size 0x00C-0x00F
Size of the valid header region, usually 92 bytes. Header CRC32 0x010-0x013
CRC32 of the header with this field zeroed while calculating. Reserved 0x014-0x017
Must be zero. Current LBA 0x018-0x01F
Location of this primary header, normally LBA 1. Backup LBA 0x020-0x027
Location of the backup GPT header at the end of the disk. First usable LBA 0x028-0x02F
First LBA that may be used by real partitions. Last usable LBA 0x030-0x037
Last LBA that may be used by real partitions. Disk GUID 0x038-0x047
Unique identifier for the whole disk, not for any one partition. Entry array LBA 0x048-0x04F
Starting LBA of the partition-entry array, commonly LBA 2. Entry count 0x050-0x053
Number of partition entries reserved in the array. Entry size 0x054-0x057
Size of each partition entry, usually 128 bytes. Entry array CRC32 0x058-0x05B
CRC32 covering the whole partition-entry array. Header padding 0x05C-0x1FF
Unused bytes in the 512-byte sector. They must be zero.

03 · firmware handoff UEFI enters through the EFI System Partition

UEFI firmware follows GPT to a small FAT32 EFI System Partition. It can read files such as /EFI/BOOT/BOOTX64.EFI without understanding ext4, Btrfs, LUKS, or the Linux root filesystem.

The selected EFI program—often GRUB or systemd-boot—loads a kernel and initramfs. A separate /boot is useful when those files must remain outside encrypted or otherwise complex root storage, but many straightforward systems do not require it.

Reference fields What firmware reads inside the FAT32 boot record

This field list describes the FAT32 volume boot record at the start of the EFI System Partition. Firmware uses this filesystem metadata to find /EFI bootloader files.

Jump instruction 0x000-0x002
CPU jump bytes for legacy boot compatibility. UEFI usually reads the filesystem rather than executing this code. OEM name 0x003-0x00A
Eight-byte formatter label. It is informational, not a reliable filesystem type check. Bytes per sector 0x00B-0x00C
Logical sector size recorded by the FAT32 BIOS parameter block, commonly 512 bytes. Sectors per cluster 0x00D
Allocation unit size. FAT maps clusters, not individual bytes. Reserved sectors 0x00E-0x00F
Sectors before the first FAT. This includes the boot sector, FSInfo sector, and backup boot sector. FAT count 0x010
Usually 2 copies of the FAT allocation table for compatibility and repair. Root entry count 0x011-0x012
Must be 0 for FAT32 because the root directory is a normal cluster chain. Small sector count 0x013-0x014
Older 16-bit sector count. FAT32 ESPs normally use the 32-bit total-sector field instead. Media descriptor 0x015
Legacy media marker, commonly 0xF8 for a fixed disk. FAT16 size 0x016-0x017
Must be 0 for FAT32; the FAT32 table size lives later in the BPB. Geometry hint 0x018-0x01B
Legacy sectors-per-track and head-count values. Modern firmware should not depend on them. Hidden sectors 0x01C-0x01F
Number of sectors before this FAT volume. On a GPT disk this corresponds to the ESP partition start offset. Total sectors 0x020-0x023
32-bit count of sectors in the EFI System Partition volume. FAT size 0x024-0x027
Size in sectors of each FAT copy. This determines where the data region begins. FAT flags 0x028-0x029
Controls active FAT selection and whether FAT copies are mirrored. FAT version 0x02A-0x02B
Filesystem version, normally 0:0. Root cluster 0x02C-0x02F
First cluster of the root directory. The /EFI directory is found by walking directory entries from here. FSInfo sector 0x030-0x031
Sector number of the FAT32 FSInfo structure, commonly 1. Backup boot sector 0x032-0x033
Sector number of the backup boot record, commonly 6. BPB reserved 0x034-0x03F
Reserved FAT32 BIOS parameter block bytes. Drive number 0x040
Legacy BIOS drive number. UEFI does not use this as a device path. Reserved byte 0x041
Reserved byte in the extended boot record. Extended signature 0x042
0x29 indicates that volume ID, label, and filesystem type fields follow. Volume ID 0x043-0x046
Serial number generated when the FAT32 volume was formatted. Volume label 0x047-0x051
Eleven-byte label for the FAT volume. Linux often also exposes the partition label separately. Filesystem type 0x052-0x059, FAT32
Informational string. Robust code identifies FAT32 from the BPB layout, not only this text. Boot code area 0x05A-0x1FD
Reserved executable area for legacy boot. On an ESP, the useful bootloaders are files such as /EFI/BOOT/BOOTX64.EFI in the data region. Boot signature 0x1FE-0x1FF
Final bytes 0x55 and 0xAA, matching the standard boot-sector signature.

The handoff from power-on to mounted root

01 UEFI reads GPT
Firmware finds the EFI System Partition through the primary partition table. 02 The ESP starts a loader
An EFI executable selects the kernel, initramfs, and kernel command line. 03 Initramfs prepares storage
Early userspace unlocks LUKS, activates LVM, assembles RAID, and locates root. 04 Linux mounts the system
Root becomes live; /boot, /home, and other filesystems follow from /etc/fstab.

04 · the running system Linux partitions are policy boundaries

The root filesystem holds /etc, /usr, /var, applications, and system state. Swap is page-oriented kernel storage rather than a mounted filesystem. A separate /home can isolate user data from operating-system replacement, but it also creates a fixed capacity boundary.

Use fewer partitions when flexibility matters. Use separate filesystems when independent recovery, quotas, encryption, snapshots, or failure containment justify the operational cost.

Illustrative planning context

The earlier layout example used a 512 GiB disk and 16 GiB RAM. These values describe an example, not detected hardware.

Mount point

not mounted

Planning rule

Do not format

Why it exists

Protects a GPT disk from legacy MBR-only tools.

sudo fdisk -l /dev/nvme0n1

Reference fields

The whole MBR fits in the first sector. Its fixed layout can be inspected from named regions down to byte offsets and individual bits.

Boot code area 0x000-0x1B7, 440 bytes
Usually unused on a UEFI GPT disk, but still reserved by the legacy MBR layout. Disk signature 0x1B8-0x1BB, 4 bytes
Optional legacy identifier used by some operating systems and tools. Reserved 0x1BC-0x1BD, 2 bytes
Two bytes between the disk signature and partition-entry table. Partition entries 0x1BE-0x1FD, 64 bytes
Four 16-byte entries. A GPT disk normally exposes one protective 0xEE entry. Boot signature 0x1FE-0x1FF, 2 bytes
The final bytes are 0x55 and 0xAA, marking the sector as a boot record.

ext4 or Btrfs /

operating system
The root filesystem contains the installed operating system: /etc, /usr, /var, system services, packages, and the base runtime.

Filesystem

ext4 or Btrfs

Mount point

/

Planning rule

40–120 GiB

Why it exists

Contains the operating system, applications, logs, and service state.

Destructive example, not an inspection command: the historical example below creates a new filesystem and can destroy existing data on the named partition. Do not run it on an existing system or copy its device name as a target. The mke2fs manual explains that mkfs.ext4 creates an ext4 filesystem. This page is a layout explanation, not an installation procedure.

Historical example — do not execute:
sudo mkfs.ext4 /dev/nvme0n1p3

Reference fields

The root partition is the installed operating system. It may be plain ext4 or an outer container for LUKS, LVM, or Btrfs.

/etc configuration
Machine identity, service config, network config, package sources. /usr programs
Most installed binaries, libraries, and shared resources. /var mutable state
Logs, caches, databases, package state, and service data. Storage layer optional
LUKS encryption, LVM logical volumes, or Btrfs subvolumes can sit inside this GPT partition.

05 · recovery copy Backup GPT closes the disk

GPT repeats its partition-entry array and header at the physical end of the device. The backup header swaps the current and alternate LBA pointers but preserves the same disk identity and usable range.

This redundancy can repair damaged front metadata, but it is not a backup of files or filesystem structures. Always capture real data separately, and verify the target device before writing partition tables.

Reference fields Backup GPT header and recovery fields

This field list describes the backup GPT header sector at the final LBA. It mirrors the primary header but swaps current and alternate locations.

Signature 0x000-0x007, EFI PART
ASCII bytes that identify this sector as a GPT header. Revision 0x008-0x00B
GPT revision, commonly 00 00 01 00 for revision 1.0. Header size 0x00C-0x00F
Size of the valid header region, usually 92 bytes. Header CRC32 0x010-0x013
CRC32 of the backup header with this field zeroed while calculating. Reserved 0x014-0x017
Must be zero. Current LBA 0x018-0x01F
Location of this backup header: the final LBA on the disk. Primary LBA 0x020-0x027
Location of the primary GPT header, normally LBA 1. First usable LBA 0x028-0x02F
First LBA that may be used by real partitions. Last usable LBA 0x030-0x037
Last LBA that may be used by real partitions. Disk GUID 0x038-0x047
Same disk GUID recorded in the primary GPT header. Backup entry array LBA 0x048-0x04F
Starting LBA of the backup partition-entry array near the disk end. Entry count 0x050-0x053
Number of partition entries reserved in the array. Entry size 0x054-0x057
Size of each partition entry, usually 128 bytes. Entry array CRC32 0x058-0x05B
CRC32 covering the backup partition-entry array. Header padding 0x05C-0x1FF
Unused bytes in the 512-byte sector. They must be zero.