VMware ESXi and vSphere Cluster Management

GPT Partitions: GUID Partition Table, Protective MBR, and Linux Compatibility

Learn how GPT partitions work, why GPT replaces MBR for large disks, how protective MBR and backup metadata work, and how Linux tools support GPT.

GPT means GUID Partition Table. It is a partition-table format that records how partitions are arranged on a storage device. GPT is the modern alternative to the older MBR, or Master Boot Record, format.

A partition table is metadata describing where partitions begin and end, what each partition is intended to contain, and how software should identify it. GPT stores this information using globally unique identifiers, or GUIDs, and keeps redundant copies of important metadata.

This lesson covers GPT layout, partition numbering, protective MBR behavior, Linux administration tools, and booting with UEFI or legacy BIOS.

Prerequisites: You should know the difference between a disk, a partition, a filesystem, and a mount point. Linux device names such as /dev/sda and /dev/nvme0n1 are also useful background.

Why GPT is preferred over MBR

Traditional MBR partitioning uses a limited address field. Under common 512-byte logical-sector assumptions, an MBR-partitioned disk can address approximately 2 TiB. A larger disk may appear truncated, or the space beyond that boundary may be unusable.

GPT uses much larger addressing fields. Its theoretical addressing model is commonly described as supporting roughly 8 ZiB, where a ZiB, or zebibyte, is a binary storage-capacity unit. Practical limits can also come from the operating system, firmware, storage controller, partitioning software, and filesystem.

GPT is therefore the normal choice for disks larger than 2 TB. It is also commonly used on modern systems even when the disk is smaller, because it provides more partition entries, identifiers, and metadata redundancy.

Feature	GPT	MBR
Typical maximum disk size	Vastly larger; the GPT addressing model is often described as supporting roughly 8 ZiB	Approximately 2 TiB under traditional sector assumptions
Default partition-entry capacity	Typically 128 entries, although the entry count can be changed when the table is created	Four primary entries, with an extended/logical workaround
Partition identifiers	GUIDs identify the disk, individual partitions, and partition types	Uses older partition type codes and less extensive identification metadata
Metadata redundancy	Primary and backup headers and partition-entry arrays	No equivalent complete backup partition table in the standard layout
UEFI compatibility	Designed to work well with UEFI, usually with an EFI System Partition	May be supported by some UEFI implementations, but is not the usual modern UEFI layout
Legacy BIOS considerations	Legacy BIOS booting can require a small BIOS boot partition for GRUB	Commonly supported by legacy BIOS without a BIOS boot partition
Protective compatibility mechanism	Includes a protective MBR containing a partition type commonly shown as `0xEE`	The MBR itself is authoritative

GPT partition-entry capacity and numbering

A typical GPT layout reserves space for 128 partition entries by default. This is not an unchangeable rule: the partition-entry count is implementation-dependent and can be selected or changed by partitioning software when a table is created.

MBR provides four primary partition entries. To represent more partitions, one primary entry can identify an extended partition containing logical partitions. GPT does not need this extended/logical partition workaround; its partition-entry array directly contains entries for the partitions.

Why GPT partition numbers can have gaps

GPT partition numbers are associated with positions in the partition-entry array. If earlier entries were deleted or remain unused, later entries can retain their positions. As a result, partition numbers do not have to be consecutive.

For example, a disk might show:

/dev/sdb3
/dev/sdb12
/dev/sdb99

This can simply mean that entries between 3 and 12, or between 12 and 99, are unused. Numbering gaps do not necessarily indicate a damaged disk and should not be “fixed” merely for appearance. Check the actual partition boundaries, filesystems, labels, and mount usage instead.

GPT disk layout

GPT places metadata at both ends of the disk. The beginning contains a compatibility record, a primary GPT header, and the primary partition-entry array. The end contains a backup partition-entry array and a backup GPT header.

Disk region	Purpose	Redundancy or compatibility role
Protective MBR	MBR-compatible record in the first logical sector	Discourages old MBR-only tools from treating the disk as empty
Primary GPT header	Describes the GPT layout, disk GUID, entry-array location, and integrity information	Main metadata copy near the start of the disk
Primary partition-entry array	Lists the GPT partition definitions	Primary copy of partition entries
Usable partition area	Space in which partition contents are stored	Usually lies between the metadata regions, subject to alignment and reserved space
Backup partition-entry array	Second copy of the partition definitions	Can help recover from damage to the primary array
Backup GPT header	Second GPT header near the end of the disk	Can help recovery tools detect or repair damaged primary metadata

The GPT headers contain checksums and references to the partition-entry arrays. If the primary copy is damaged but the backup is valid, a GPT-aware recovery tool may be able to reconstruct the primary metadata. Recovery should be treated as an administrative repair, not as an automatic operation: inspect the disk, confirm which copy represents the intended layout, and protect important data first.

The protective MBR

The protective MBR is an MBR-compatible record placed in the first logical sector of a GPT disk. It normally contains a protective partition type commonly displayed as 0xEE.

Its purpose is compatibility protection. Older MBR-only programs may not understand GPT. Without a protective record, such a program could conclude that the disk is empty and offer to initialize or repartition it. The protective MBR signals that the disk is already in use.

To an MBR-only utility, the simplified view is usually one partition that appears to span most or all of the disk. That is not the authoritative partition map. The GPT header and partition-entry array are authoritative for a GPT disk, and a GPT-aware utility is required to view the individual GPT partitions correctly.

Identifiers used by GPT

A GUID, or globally unique identifier, is a large identifier intended to be unique across systems. GPT uses several kinds of GUID:

Disk GUID: identifies the GPT disk as a whole.
Partition unique GUID: identifies one particular partition. Cloning or copying disks can require attention to duplicate identifiers.
Partition type GUID: identifies the intended role of a partition, such as an EFI System Partition, Linux filesystem partition, or Linux swap partition.
Partition name: a human-readable label stored as GPT metadata. It can describe a role such as root, home, or backup.

The partition type GUID is not the same as the partition unique GUID. The type answers “what is this partition intended for?” while the unique GUID answers “which individual partition is this?”

GPT, UEFI, and booting

UEFI is a modern firmware interface. A common UEFI Linux installation uses GPT and an EFI System Partition, or ESP. The ESP is a firmware-readable partition, normally formatted with a FAT filesystem, that stores bootloader files.

GPT alone does not guarantee that a disk will boot. Boot success depends on several pieces:

The firmware must be operating in the expected mode.
The operating system must support GPT.
The bootloader must support the selected firmware and partition-table combination.
The platform architecture and firmware implementation must be compatible.
The required boot-related partition and boot files must be present and correctly configured.

Firmware mode	Partition table	Boot-related partition	Notes
UEFI	GPT	EFI System Partition	Install boot files in the ESP and ensure the firmware has an appropriate boot entry
Legacy BIOS with GPT and GRUB	GPT	Small BIOS boot partition	GRUB may need a small unformatted BIOS boot partition for embedded bootloader data
Legacy BIOS	MBR	Usually no separate BIOS boot partition	The traditional arrangement uses boot code and partition metadata in the MBR

UEFI/GPT and legacy-BIOS/GPT are different boot scenarios. A system installed in UEFI mode may fail to boot if the firmware is later forced into legacy mode, and the reverse can also happen. When troubleshooting, first determine which firmware mode is actually being used.

Linux support and GPT-aware utilities

Older operating systems, firmware environments, and partitioning programs may not fully support GPT. Never assume that a utility understands GPT just because it can display some disk information. An unsupported utility may misinterpret the protective MBR or damage the GPT metadata if it writes a new partition table.

Modern Linux systems commonly provide these tools:

Utility	Typical use	Safety note
`fdisk`	Inspect and interactively edit partition tables	Contemporary versions support GPT; verify capabilities in older or unusual environments
`parted`	Create, inspect, and modify GPT and other partition tables	Its commands can write changes immediately; check the target device and boundaries carefully
`gdisk`	GPT-focused interactive inspection and editing	Useful for GPT diagnostics, but write operations still require careful confirmation
`sgdisk`	GPT inspection, scripting, backup, and non-interactive operations	Convenient for automation; a wrong device argument can cause destructive changes
`lsblk`	Display block devices, partitions, labels, and partition-table types	Normally an inspection tool, but verify output against the physical device
`blkid`	Display filesystem and partition identifiers	Use it to verify identity, but do not confuse filesystem identifiers with the GPT disk layout

Safe GPT inspection

Start with read-only inspection. Replace /dev/sdX below with the actual whole-disk device, not a partition such as /dev/sdX1. NVMe disks use names such as /dev/nvme0n1.

lsblk -o NAME,SIZE,TYPE,PTTYPE,PARTTYPE,PARTLABEL
sudo parted -l
sudo gdisk -l /dev/sdX
sudo sgdisk -p /dev/sdX
sudo fdisk -l /dev/sdX

These commands can show the partition-table type, partition boundaries, type GUIDs or codes, labels, and GPT consistency information. Compare the reported device size with the physical disk you intend to inspect. Similar names are easy to confuse, especially on systems with several disks.

Identify the physical disk by size, model, serial information, and current mount usage.
Run read-only inspection commands before writing anything.
Confirm that the selected device is the whole disk.
Back up important data and, where appropriate, back up the partition table itself.
Unmount affected filesystems before changing their partition boundaries.
After a change, allow the kernel to reread the partition table. This may require partprobe, removing busy mounts, or rebooting.

Creating a GPT table and partition

Creating a new GPT label overwrites existing partition-table metadata. The following is an example for a disk that is intentionally being prepared as new storage:

sudo parted /dev/sdX --script mklabel gpt
sudo parted /dev/sdX --script mkpart primary ext4 1MiB 100%
sudo partprobe /dev/sdX

The ext4 value supplied to parted describes the intended partition type or filesystem. It does not create the filesystem. Filesystem creation is a separate operation, and the start and end boundaries must be chosen for the actual layout rather than copied blindly.

An interactive GPT-focused alternative is:

sudo gdisk /dev/sdX

Use interactive partitioning tools only after confirming the target and backups. A command that writes a partition table can make existing filesystems inaccessible even if the data sectors have not immediately been overwritten.

Verifying UEFI-related partitions

Use several views to confirm a boot-related layout:

sudo lsblk -f
sudo blkid
sudo parted /dev/sdX print

Look for the ESP's partition type, filesystem, label, and mount arrangement. For a legacy BIOS GRUB installation on GPT, look for the small BIOS boot partition instead. The exact partition sizes and mount paths depend on the Linux distribution and installation design.

MBR-to-GPT migration considerations

Changing a disk from MBR to GPT can be destructive if performed by deleting and recreating the partition table. A conversion tool may preserve existing partitions in some layouts, but conversion is not a universal one-command procedure.

Before migration, assess:

Whether the machine will boot in UEFI mode or remain in legacy BIOS mode.
Whether the operating system supports GPT and the intended boot mode.
Whether the bootloader needs an ESP or a BIOS boot partition.
Whether existing partitions fit the conversion tool's requirements.
Whether the disk has enough suitable space for any required boot partition or metadata relocation.
Whether current backups have been tested and can restore the system.

After conversion, the bootloader may need to be installed again and firmware boot entries may need to be created. Treat the conversion as a change-management task: document the current layout, verify recovery media, and plan for an outage.

Troubleshooting GPT problems

A disk larger than 2 TB appears truncated

First inspect the partition-table type. If the disk uses MBR, the traditional address limit may explain the missing capacity. Also check whether the operating system, firmware, storage controller, and partitioning tools support the disk size. Plan any MBR-to-GPT migration only after reviewing backups and boot compatibility.

A utility reports an unknown partition table

The utility may be MBR-only or too old to support GPT. Check the disk with a second GPT-aware tool such as gdisk or parted. Do not accept an offer to initialize or repartition the disk until you understand its contents. If multiple GPT-aware tools report damage, compare the primary and backup metadata.

A GPT disk does not boot

Determine whether the machine booted in UEFI or legacy BIOS mode.
For UEFI, verify that an EFI System Partition exists, uses a firmware-readable filesystem, and contains boot files.
For legacy BIOS with GRUB on GPT, verify that the required BIOS boot partition exists.
Verify the bootloader installation and firmware boot entries.

Primary and backup GPT tables differ

This can follow a disk resize, an interrupted operation, or damage to one metadata copy. Back up important data first. Inspect both copies with a GPT-aware utility and repair only after determining which copy accurately represents the intended partition layout.

Partition numbers contain unexpected gaps

Deleted or previously used GPT entries can leave gaps. Review the actual partition list, boundaries, filesystems, and mount usage. Gaps alone are normal and do not require correction.

Exam-relevant summary

GPT stands for GUID Partition Table and is the modern alternative to MBR.
Traditional MBR addressing is limited to approximately 2 TiB, while GPT supports vastly larger disks; its theoretical scale is often described as roughly 8 ZiB.
A typical GPT table provides 128 partition entries by default, though the entry count can be implementation-dependent.
GPT partition numbers refer to entries in the partition-entry array and can contain gaps.
The protective MBR is a compatibility safeguard, not the authoritative GPT partition map.
GPT stores a primary header and partition-entry array near the beginning and backup copies near the end.
GPT uses a disk GUID, a unique GUID for each partition, a partition type GUID, and optional human-readable names.
UEFI systems commonly boot from an EFI System Partition.
Legacy BIOS GRUB installations on GPT may require a small BIOS boot partition.
Use GPT-aware Linux tools and identify the correct whole-disk device before making changes.

For the related topic, see GPT partitions.