When expanding storage on a Linux VPS, many administrators encounter the frustrating error fdisk: failed to write disklabel: Invalid argument during partition resizing. This typically occurs when trying to extend a GPT partition after a virtual disk expansion, particularly when there's a mismatch between the protective MBR and actual disk size.

The warning GPT PMBR size mismatch (104857599 != 629145599) indicates that the protective Master Boot Record (PMBR) still reflects the old disk size (50GB) while the actual disk now shows 300GB. While fdisk suggests writing the partition table could fix this, the operation fails due to underlying partition alignment issues.

For GPT partitions, gdisk is more reliable than fdisk. Here's the step-by-step process:

# Install gdisk if not available
sudo apt install gdisk   # Debian/Ubuntu
sudo yum install gdisk   # CentOS/RHEL

# Launch gdisk on the target disk
sudo gdisk /dev/vda

# In gdisk interactive mode:
Command: x       # Enter expert mode
Command: e       # Relocate backup data structures
Command: w       # Write table to disk
Command: y       # Confirm write operation

After correcting the GPT header, verify the changes:

sudo gdisk -l /dev/vda
sudo parted /dev/vda print

Once the partition table is corrected, you can resize your partition and filesystem:

# For ext4 filesystems:
sudo growpart /dev/vda 3
sudo resize2fs /dev/vda3

# For xfs filesystems:
sudo growpart /dev/vda 3
sudo xfs_growfs /mountpoint

If gdisk isn't available, you can use sfdisk to dump and reload the partition table:

# Backup current partition table
sudo sfdisk -d /dev/vda > vda_partition_backup.txt

# Edit the backup file to update sector counts
nano vda_partition_backup.txt

# Restore the modified partition table
sudo sfdisk /dev/vda < vda_partition_backup.txt

Always ensure you have complete backups before modifying partition tables. The exact sector values in the partition table must match your specific disk geometry. For cloud instances, some providers require additional steps like detaching/re-attaching volumes or using their specific resize tools.

When attempting to resize partitions after a VPS storage upgrade, I encountered this frustrating error during fdisk operations. The system correctly recognized the new 300GB disk capacity (629145600 sectors) but failed to update the partition table due to a protective MBR (PMBR) size mismatch.

GPT PMBR size mismatch (104857599 != 629145599) will be corrected by w(rite).
fdisk: failed to write disklabel: Invalid argument

The protective MBR in GPT disks contains legacy information about partition sizes. When the underlying storage expands but the GPT headers aren't properly updated, fdisk detects this inconsistency but fails to automatically correct it due to safety constraints.

Traditional fdisk tools struggle with GPT partitions. The proper solution involves using gdisk (GPT fdisk):

# Install gdisk if needed
sudo apt-get install gdisk

# Launch gdisk on the target disk
sudo gdisk /dev/vda

# Inside gdisk interactive prompt:
Command: w   # Write changes
Command: q   # Quit

This automatically fixes the PMBR inconsistency without manual sector calculations.

After running gdisk, verify the partition table:

sudo parted -l
sudo gdisk -l /dev/vda

With the corrected GPT headers, you can now resize your filesystem partition. Here's the complete workflow:

# Delete and recreate the partition (keeping same start sector)
sudo gdisk /dev/vda
Command: d   # Delete partition 3
Command: n   # New partition
Partition number: 3
First sector: 16809984 (must match original)
Last sector: (press Enter for maximum available space)
Hex code: 8300 (Linux filesystem)
Command: w   # Write changes

# Resize the filesystem (for ext4)
sudo resize2fs /dev/vda3

For scripted environments, sfdisk offers another solution:

# Backup partition table
sudo sfdisk -d /dev/vda > vda.bak

# Edit backup file to update disk size
# Then restore the partition table
sudo sfdisk /dev/vda < vda.bak --force