Turn a disk size, memory budget, and boot requirements into a practical GPT layout—then inspect what every region does.
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.
Every byte in the protective MBR
Select any offset in the 512-byte sector. Values marked -- depend on the disk or legacy boot code; structural roles remain fixed.
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.
Inspect the structure
Primary GPT header, field by field
This matrix maps the primary GPT header sector at LBA 1. The header points to the partition-entry array that follows it.
Signature0x000-0x007, EFI PART
ASCII bytes that identify this sector as a GPT header.
Revision0x008-0x00B
GPT revision, commonly 00 00 01 00 for revision 1.0.
Header size0x00C-0x00F
Size of the valid header region, usually 92 bytes.
Header CRC320x010-0x013
CRC32 of the header with this field zeroed while calculating.
Reserved0x014-0x017
Must be zero.
Current LBA0x018-0x01F
Location of this primary header, normally LBA 1.
Backup LBA0x020-0x027
Location of the backup GPT header at the end of the disk.
First usable LBA0x028-0x02F
First LBA that may be used by real partitions.
Last usable LBA0x030-0x037
Last LBA that may be used by real partitions.
Disk GUID0x038-0x047
Unique identifier for the whole disk, not for any one partition.
Entry array LBA0x048-0x04F
Starting LBA of the partition-entry array, commonly LBA 2.
Entry count0x050-0x053
Number of partition entries reserved in the array.
Entry size0x054-0x057
Size of each partition entry, usually 128 bytes.
Entry array CRC320x058-0x05B
CRC32 covering the whole partition-entry array.
Header padding0x05C-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.
Inspect the structure
What firmware reads inside the FAT32 boot record
This matrix maps the FAT32 volume boot record at the start of the EFI System Partition. Firmware uses this filesystem metadata to find /EFI bootloader files.
Jump instruction0x000-0x002
CPU jump bytes for legacy boot compatibility. UEFI usually reads the filesystem rather than executing this code.
OEM name0x003-0x00A
Eight-byte formatter label. It is informational, not a reliable filesystem type check.
Bytes per sector0x00B-0x00C
Logical sector size recorded by the FAT32 BIOS parameter block, commonly 512 bytes.
Sectors per cluster0x00D
Allocation unit size. FAT maps clusters, not individual bytes.
Reserved sectors0x00E-0x00F
Sectors before the first FAT. This includes the boot sector, FSInfo sector, and backup boot sector.
FAT count0x010
Usually 2 copies of the FAT allocation table for compatibility and repair.
Root entry count0x011-0x012
Must be 0 for FAT32 because the root directory is a normal cluster chain.
Small sector count0x013-0x014
Older 16-bit sector count. FAT32 ESPs normally use the 32-bit total-sector field instead.
Media descriptor0x015
Legacy media marker, commonly 0xF8 for a fixed disk.
FAT16 size0x016-0x017
Must be 0 for FAT32; the FAT32 table size lives later in the BPB.
Geometry hint0x018-0x01B
Legacy sectors-per-track and head-count values. Modern firmware should not depend on them.
Hidden sectors0x01C-0x01F
Number of sectors before this FAT volume. On a GPT disk this corresponds to the ESP partition start offset.
Total sectors0x020-0x023
32-bit count of sectors in the EFI System Partition volume.
FAT size0x024-0x027
Size in sectors of each FAT copy. This determines where the data region begins.
FAT flags0x028-0x029
Controls active FAT selection and whether FAT copies are mirrored.
FAT version0x02A-0x02B
Filesystem version, normally 0:0.
Root cluster0x02C-0x02F
First cluster of the root directory. The /EFI directory is found by walking directory entries from here.
FSInfo sector0x030-0x031
Sector number of the FAT32 FSInfo structure, commonly 1.
Backup boot sector0x032-0x033
Sector number of the backup boot record, commonly 6.
BPB reserved0x034-0x03F
Reserved FAT32 BIOS parameter block bytes.
Drive number0x040
Legacy BIOS drive number. UEFI does not use this as a device path.
Reserved byte0x041
Reserved byte in the extended boot record.
Extended signature0x042
0x29 indicates that volume ID, label, and filesystem type fields follow.
Volume ID0x043-0x046
Serial number generated when the FAT32 volume was formatted.
Volume label0x047-0x051
Eleven-byte label for the FAT volume. Linux often also exposes the partition label separately.
Filesystem type0x052-0x059, FAT32
Informational string. Robust code identifies FAT32 from the BPB layout, not only this text.
Boot code area0x05A-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 signature0x1FE-0x1FF
Final bytes 0x55 and 0xAA, matching the standard boot-sector signature.
The handoff from power-on to mounted root
01UEFI reads GPT
Firmware finds the EFI System Partition through the primary partition table.
02The ESP starts a loader
An EFI executable selects the kernel, initramfs, and kernel command line.
03Initramfs prepares storage
Early userspace unlocks LUKS, activates LVM, assembles RAID, and locates root.
04Linux 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.
GPT disk layout
Metadata
Protective MBR
sector 0
Legacy BIOS tools see this protective master boot record. It marks the disk as occupied so older partition tools do not overwrite the GPT disk.
Filesystem
Metadata
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
Inspect its structure
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 area0x000-0x1B7, 440 bytes
Usually unused on a UEFI GPT disk, but still reserved by the legacy MBR layout.
Disk signature0x1B8-0x1BB, 4 bytes
Optional legacy identifier used by some operating systems and tools.
Reserved0x1BC-0x1BD, 2 bytes
Two bytes between the disk signature and partition-entry table.
Partition entries0x1BE-0x1FD, 64 bytes
Four 16-byte entries. A GPT disk normally exposes one protective 0xEE entry.
Boot signature0x1FE-0x1FF, 2 bytes
The final bytes are 0x55 and 0xAA, marking the sector as a boot record.
GPT metadata
Primary GPT
front metadata
The primary GUID partition table stores the partition entries used by modern firmware and operating systems.
Filesystem
GPT metadata
Mount point
not mounted
Planning rule
Managed by partition tools
Why it exists
Stores the primary header and partition-entry array.
sudo sgdisk --verify /dev/nvme0n1
Inspect its structure
This matrix maps the primary GPT header sector at LBA 1. The header points to the partition-entry array that follows it.
Signature0x000-0x007, EFI PART
ASCII bytes that identify this sector as a GPT header.
Revision0x008-0x00B
GPT revision, commonly 00 00 01 00 for revision 1.0.
Header size0x00C-0x00F
Size of the valid header region, usually 92 bytes.
Header CRC320x010-0x013
CRC32 of the header with this field zeroed while calculating.
Reserved0x014-0x017
Must be zero.
Current LBA0x018-0x01F
Location of this primary header, normally LBA 1.
Backup LBA0x020-0x027
Location of the backup GPT header at the end of the disk.
First usable LBA0x028-0x02F
First LBA that may be used by real partitions.
Last usable LBA0x030-0x037
Last LBA that may be used by real partitions.
Disk GUID0x038-0x047
Unique identifier for the whole disk, not for any one partition.
Entry array LBA0x048-0x04F
Starting LBA of the partition-entry array, commonly LBA 2.
Entry count0x050-0x053
Number of partition entries reserved in the array.
Entry size0x054-0x057
Size of each partition entry, usually 128 bytes.
Entry array CRC320x058-0x05B
CRC32 covering the whole partition-entry array.
Header padding0x05C-0x1FF
Unused bytes in the 512-byte sector. They must be zero.
FAT32
EFI System
firmware-readable FAT
UEFI firmware reads this FAT32 partition to find bootloaders such as GRUB or systemd-boot.
Filesystem
FAT32
Mount point
/boot/efi
Planning rule
512 MiB–1 GiB
Why it exists
Firmware reads EFI executables here before Linux starts.
sudo mkfs.fat -F 32 /dev/nvme0n1p1
Inspect its structure
This matrix maps the FAT32 volume boot record at the start of the EFI System Partition. Firmware uses this filesystem metadata to find /EFI bootloader files.
Jump instruction0x000-0x002
CPU jump bytes for legacy boot compatibility. UEFI usually reads the filesystem rather than executing this code.
OEM name0x003-0x00A
Eight-byte formatter label. It is informational, not a reliable filesystem type check.
Bytes per sector0x00B-0x00C
Logical sector size recorded by the FAT32 BIOS parameter block, commonly 512 bytes.
Sectors per cluster0x00D
Allocation unit size. FAT maps clusters, not individual bytes.
Reserved sectors0x00E-0x00F
Sectors before the first FAT. This includes the boot sector, FSInfo sector, and backup boot sector.
FAT count0x010
Usually 2 copies of the FAT allocation table for compatibility and repair.
Root entry count0x011-0x012
Must be 0 for FAT32 because the root directory is a normal cluster chain.
Small sector count0x013-0x014
Older 16-bit sector count. FAT32 ESPs normally use the 32-bit total-sector field instead.
Media descriptor0x015
Legacy media marker, commonly 0xF8 for a fixed disk.
FAT16 size0x016-0x017
Must be 0 for FAT32; the FAT32 table size lives later in the BPB.
Geometry hint0x018-0x01B
Legacy sectors-per-track and head-count values. Modern firmware should not depend on them.
Hidden sectors0x01C-0x01F
Number of sectors before this FAT volume. On a GPT disk this corresponds to the ESP partition start offset.
Total sectors0x020-0x023
32-bit count of sectors in the EFI System Partition volume.
FAT size0x024-0x027
Size in sectors of each FAT copy. This determines where the data region begins.
FAT flags0x028-0x029
Controls active FAT selection and whether FAT copies are mirrored.
FAT version0x02A-0x02B
Filesystem version, normally 0:0.
Root cluster0x02C-0x02F
First cluster of the root directory. The /EFI directory is found by walking directory entries from here.
FSInfo sector0x030-0x031
Sector number of the FAT32 FSInfo structure, commonly 1.
Backup boot sector0x032-0x033
Sector number of the backup boot record, commonly 6.
BPB reserved0x034-0x03F
Reserved FAT32 BIOS parameter block bytes.
Drive number0x040
Legacy BIOS drive number. UEFI does not use this as a device path.
Reserved byte0x041
Reserved byte in the extended boot record.
Extended signature0x042
0x29 indicates that volume ID, label, and filesystem type fields follow.
Volume ID0x043-0x046
Serial number generated when the FAT32 volume was formatted.
Volume label0x047-0x051
Eleven-byte label for the FAT volume. Linux often also exposes the partition label separately.
Filesystem type0x052-0x059, FAT32
Informational string. Robust code identifies FAT32 from the BPB layout, not only this text.
Boot code area0x05A-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 signature0x1FE-0x1FF
Final bytes 0x55 and 0xAA, matching the standard boot-sector signature.
ext4
/boot
kernel handoff
A small Linux boot partition can hold kernels, initramfs images, and bootloader files when the root filesystem is encrypted or layered.
Filesystem
ext4
Mount point
/boot
Planning rule
1–2 GiB
Why it exists
Keeps kernels and initramfs readable before encrypted root is unlocked.
sudo mkfs.ext4 /dev/nvme0n1p2
Inspect its structure
A separate boot partition keeps kernel assets readable before encrypted or layered root storage is available.
Filesystem superblockext4 metadata
Describes block size, inode counts, and filesystem state.
Kernelsvmlinuz-*
Compressed Linux kernel images selected by the bootloader.
Initramfsinitrd or initramfs
Early userspace used to discover storage, unlock disks, and mount root.
Loader configentries or grub
Boot menu records, kernel command line, and fallback entries.
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.
sudo mkfs.ext4 /dev/nvme0n1p3
Inspect its structure
The root partition is the installed operating system. It may be plain ext4 or an outer container for LUKS, LVM, or Btrfs.
/etcconfiguration
Machine identity, service config, network config, package sources.
/usrprograms
Most installed binaries, libraries, and shared resources.
/varmutable state
Logs, caches, databases, package state, and service data.
Storage layeroptional
LUKS encryption, LVM logical volumes, or Btrfs subvolumes can sit inside this GPT partition.
Linux swap
swap
memory backing
Swap gives the kernel overflow memory and can support hibernation when sized for the machine. Some installs use a swap file instead.
Filesystem
Linux swap
Mount point
not mounted
Planning rule
RAM-dependent
Why it exists
Provides memory pressure relief and, when large enough, hibernation storage.
sudo mkswap /dev/nvme0n1p4
Inspect its structure
Swap is not a normal filesystem. It is page-oriented backing storage managed directly by the kernel.
Swap headerfirst page
Contains swap version, usable page count, bad page list, UUID, and label.
Page slotsfixed-size pages
Memory pages are written here when RAM pressure requires it.
Resume targetoptional
Hibernation can resume from swap when the boot config points to the correct UUID and offset.
ext4 or Btrfs
/home
user data
User files, project checkouts, browser profiles, and personal configuration live here when /home is split from the operating system.
Filesystem
ext4 or Btrfs
Mount point
/home
Planning rule
remaining space
Why it exists
Separates user data from operating-system replacement and recovery.
sudo mkfs.ext4 /dev/nvme0n1p5
Inspect its structure
A separate home partition makes user data easier to preserve while reinstalling or changing the operating system.
User directories/home/name
Documents, projects, media, downloads, and application files.
Dotfileshidden config
Shell, editor, desktop, browser, and app settings.
Cache and state.cache, .local
Per-user caches and state that can grow large.
Filesystem metadataextents and inodes
The filesystem tracks names, permissions, block extents, and timestamps.
GPT metadata
Backup GPT
last sectors
GPT keeps a backup header and partition-entry array at the end of the disk so the table can be repaired if the front metadata is damaged.
Filesystem
GPT metadata
Mount point
not mounted
Planning rule
Managed by partition tools
Why it exists
Mirrors critical GPT information at the physical end of the disk.
sudo sgdisk --backup=gpt.bin /dev/nvme0n1
Inspect its structure
This matrix maps the backup GPT header sector at the final LBA. It mirrors the primary header but swaps current and alternate locations.
Signature0x000-0x007, EFI PART
ASCII bytes that identify this sector as a GPT header.
Revision0x008-0x00B
GPT revision, commonly 00 00 01 00 for revision 1.0.
Header size0x00C-0x00F
Size of the valid header region, usually 92 bytes.
Header CRC320x010-0x013
CRC32 of the backup header with this field zeroed while calculating.
Reserved0x014-0x017
Must be zero.
Current LBA0x018-0x01F
Location of this backup header: the final LBA on the disk.
Primary LBA0x020-0x027
Location of the primary GPT header, normally LBA 1.
First usable LBA0x028-0x02F
First LBA that may be used by real partitions.
Last usable LBA0x030-0x037
Last LBA that may be used by real partitions.
Disk GUID0x038-0x047
Same disk GUID recorded in the primary GPT header.
Backup entry array LBA0x048-0x04F
Starting LBA of the backup partition-entry array near the disk end.
Entry count0x050-0x053
Number of partition entries reserved in the array.
Entry size0x054-0x057
Size of each partition entry, usually 128 bytes.
Entry array CRC320x058-0x05B
CRC32 covering the backup partition-entry array.
Header padding0x05C-0x1FF
Unused bytes in the 512-byte sector. They must be zero.
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.
Inspect the structure
Backup GPT header and recovery fields
This matrix maps the backup GPT header sector at the final LBA. It mirrors the primary header but swaps current and alternate locations.
Signature0x000-0x007, EFI PART
ASCII bytes that identify this sector as a GPT header.
Revision0x008-0x00B
GPT revision, commonly 00 00 01 00 for revision 1.0.
Header size0x00C-0x00F
Size of the valid header region, usually 92 bytes.
Header CRC320x010-0x013
CRC32 of the backup header with this field zeroed while calculating.
Reserved0x014-0x017
Must be zero.
Current LBA0x018-0x01F
Location of this backup header: the final LBA on the disk.
Primary LBA0x020-0x027
Location of the primary GPT header, normally LBA 1.
First usable LBA0x028-0x02F
First LBA that may be used by real partitions.
Last usable LBA0x030-0x037
Last LBA that may be used by real partitions.
Disk GUID0x038-0x047
Same disk GUID recorded in the primary GPT header.
Backup entry array LBA0x048-0x04F
Starting LBA of the backup partition-entry array near the disk end.
Entry count0x050-0x053
Number of partition entries reserved in the array.
Entry size0x054-0x057
Size of each partition entry, usually 128 bytes.
Entry array CRC320x058-0x05B
CRC32 covering the backup partition-entry array.
Header padding0x05C-0x1FF
Unused bytes in the 512-byte sector. They must be zero.