Live resize of a GPT partition on Linux

On Linux I used to resize MBR partitions using fdisk, even on live filesystems, and then issue a resize2fs/pvresize/... (depending on fs type) to get the new space allocated.

Lately I've been using Xen and GPT partitions, and I've noticed that unfortunately parted doesn't seem to allow on-the-fly resizing of a mounted partition, in fact it will complain:

Error: Partition XXX is being used. You must unmount it before you modify it with Parted.

I've tried both the resize command and even rm + mkpart combination, but they will both complain about the partition being mounted.

How can I do that?

The safest way to do this is to boot using an emergency medium (a live CD or the like) and use GParted, which will resize both the partition and the filesystem it contains. This will work only if the partition is not currently being used, though.

If you can't afford any downtime, though, you could try using gdisk instead of parted. You'll need to delete the partition you want to resize and create a new one in its place with the same start point, much as you'd have done with fdisk. gdisk is willing to work on an in-use disk, although the kernel might not register any changes. In that case, you may need to use partprobe or kpartx to get the kernel to accept the new partition table, or even reboot the computer if that doesn't work. (This should all be pretty similar to using fdisk.)

This usually only works with more recent Linux distributions. Tools needed:

• partprobe (usually part of parted)
• gdisk / sgdisk

A GPT partition stores a backup header at the end of the disk. If you have resized the underlying device, the backup header will be somewhere in the middle. The first step is to move the partition header to the end of the disk.

Assuming the disk is /dev/sda and the partition is /dev/sda3 (must also be the last partition):

sgdisk -e /dev/sda

Then delete, the last partition and re-create it:

sgdisk -d 3 /dev/sda
sgdisk -N 3 /dev/sda

You'll usually see a message indicating that the kernel is unable to re-load the partition table. You have to run partprobe so the partition is registered with the new size:

partprobe /dev/sda

If this is unsuccessful, you'll have to reboot the virtual machine. After that you can grow your filesystem with the appropriate tool, for ext4 etc.:

resize2fs /dev/sda3

Caution: running sgdisk can be destructive. Make sure you have proper backup procedures in place.

Here's an example that an automated tool uses to resize a partition online, in one run:

sgdisk -d 1 -n 1:2048:0 -c 1: -u 1:E485F29F-A1F4-4953-9DD8-799EAEA0119B -t 1:0700 /dev/xvda

Here's list of options to sgdisk command:

• -d 1 delete's first partition
• -n 1:2048:0 says create new partition "number 1", with starting sector 2048. End sector = "0" which means "use all available space for this partition
• -u sets unique guid for that partition (this is specific for GPT partitions); you could use 'R' for GUID to be set to a random value. You could also get current partitions's id through gdisk /dev/xvda; p output to reuse the same uid
• -t 1:0700 basically means first partition is of typecode '0700'.

/dev/xvda was the disk which we repartitioned.

So it deletes and creates a new partition on its place right away.

PS. A few notes on typecode '0700'. From man SGDISK(8)

   -t, --typecode=partnum:{hexcode|GUID}
          Change a single partition's type  code.  You  enter  the  type  code  using  either  a  two-byte  hexadecimal  number,  as 

described earlier, or a fully-specified GUID value, such as EBD0A0A2-B9E5-4433-87C0-68B6B72699C7.

Found best explanation for what '0700' means here - http://www.rodsbooks.com/gdisk/walkthrough.html

"But wait," you say, "I thought the disk had a FAT partition!" Indeed it does. Windows uses a single GUID code for all its data partitions, be they FAT or NTFS. In the past, the same code has been used in Linux for its data partitions. (More on this shortly....) Thus, in this case several different MBR codes are all translated into a single GPT GUID code. GPT fdisk uses, somewhat arbitrarily, the 0x0700 code (or more precisely, EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) for all of these.

In my case I believe that was a Linux ext4 partition, but partition's typecode doesn't mean filesystem type, so '0700' looks more like a catchall type for sgdisk. At least in cases I've seen.

PPS. You may need to run partprobe for kernel to become aware of the partitioning change without rebooting system.