.IMG File Format – GUID partition table

Layout

UEFI 2.10 section 5.3.1: the primary header must be in LBA 1 and the backup header in the last LBA; the primary entry array lies after the primary header and ends before the first usable LBA, the backup array after the last usable LBA and before the backup header. At least 16,384 bytes must be reserved for the entry array, so the first usable LBA is at least 34 with 512-byte blocks and at least 6 with 4,096-byte blocks. Only the partitioning structures may lie outside the usable range. EDK2’s recovery code puts the primary entries at LBA 2 and the backup entries at the last usable LBA + 1, and util-linux lays out a new table the same way: with E sectors of entries, the first usable LBA is E + 2 and the last usable LBA is the sector count − E − 2.

The specification recommends aligning partitions to the larger of the physical block size and the optimal transfer granularity, and notes that software may simply use multiples of 2,048 (1 MiB with 512-byte blocks).

Protective MBR

Sector 0 has the layout of an MBR, so tools that know only MBR see the disk as full. UEFI 2.10 Tables 5.3 and 5.4: boot code unused; disk signature and the two unknown bytes set to zero; one partition record with boot indicator 00, starting CHS 0x000200, type EE, ending CHS the last block’s CHS address or 0xFFFFFF if it cannot be represented, starting LBA 1, and size the disk size minus one or 0xFFFFFFFF if too large; the other three records zero. EDK2 recognises it by a type EE entry starting at LBA 1, and util-linux writes it as the table says.

GPT header

UEFI 2.10 section 5.3.2: to validate a GPT, check the signature, the header CRC, that My LBA is the block it was read from, and the entry array CRC; for the primary, check the alternate too. If the primary is corrupt, software checks the last LBA and should restore the primary from a valid backup (if platform policy allows, and must report it); a valid primary with a bad backup means the backup must be restored. Updates go to the backup first, then the primary. A disk reformatted to MBR by legacy software may keep a stale backup GPT in its last block; a legacy MBR with valid partitions, rather than a protective MBR, tells such a disk apart. EDK2’s checks follow the same list, adding the header size, entry count and entry size.

Partition entry

An entry whose fields are all zero is unused. Copying software must give copied disks and partitions new Disk GUIDs and Unique Partition GUIDs (UEFI 5.3.3).

EDK2 treats an entry as invalid when its starting LBA is above its ending LBA or when it lies outside the first and last usable LBAs, and it also flags entries that overlap.

GUIDs are stored as in the EFI specification: util-linux notes that a UUID is traditionally a 16-byte big-endian array, but EFI stores it as a structure of little-endian fields (a 32-bit, two 16-bit, then eight single bytes). So the first three groups of the written form appear byte-reversed in the file.

Attributes

Microsoft defines these type-specific bits for basic data partitions:

Partition type GUIDs

UEFI 2.10 Table 5.7 defines only the unused entry, the EFI system partition and the partition holding a legacy MBR, and says OS vendors make their own; Microsoft documents its own types. The rest are chosen by the makers of each system, with no central register. The tables give every type util-linux’s fdisk knows, under its names.

Linux per-architecture types

util-linux takes these from systemd’s Discoverable Partitions Specification: one GUID per architecture for each of the root and /usr file systems, their dm-verity hash data, and the signatures of that data.