Source: https://mayphus.org/linux-disk/ Title: Linux Disk Layout --- type: project --- 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. 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](https://man7.org/linux/man-pages/man8/mke2fs.8.html) explains that `mkfs.ext4` creates an ext4 filesystem. This page is a layout explanation, not an installation procedure. ```text 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.