Live resize of a GPT partition on Linux
Solution 1
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
.)
Solution 2
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.
Solution 3
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.
Solution 4
I'm just summarising some answers and comments here:
parted
will simply refuse to change any mounted partition. gdisk
will do the job for you, but it is not in the standard RHEL or CentOS repository. It is in the EPEL repository, though.
Keep in mind that changing partitions on a disk that is in use might prevent the kernel from registering the changes. If that happens, use partprobe
, partx
or reboot.
Solution 5
fdisk
is typically still available and can do this, if the partition is the last partition and the start of the partition isn't moving.
However, this is a dangerous operation that should be done with great care. Make a backup!
ec2-user@ip-10-0-20-15 ~]$ sudo fdisk /dev/nvme0n1
Welcome to fdisk (util-linux 2.30.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/nvme0n1: 24 GiB, 25769803776 bytes, 50331648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 70E4A118-98BD-4BF4-8DF9-6926A964902A
Device Start End Sectors Size Type
/dev/nvme0n1p1 4096 16777182 16773087 8G Linux filesystem
/dev/nvme0n1p128 2048 4095 2048 1M BIOS boot
Partition table entries are not in disk order.
Command (m for help): d
Partition number (1,128, default 128): 1
Partition 1 has been deleted.
Command (m for help): n
Partition number (1-127, default 1): 1
First sector (34-50331614, default 4096):
Last sector, +sectors or +size{K,M,G,T,P} (4096-50331614, default 50331614):
Created a new partition 1 of type 'Linux filesystem' and of size 24 GiB.
Partition #1 contains a xfs signature.
Do you want to remove the signature? [Y]es/[N]o: n
Command (m for help): p
Disk /dev/nvme0n1: 24 GiB, 25769803776 bytes, 50331648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 70E4A118-98BD-4BF4-8DF9-6926A964902A
Device Start End Sectors Size Type
/dev/nvme0n1p1 4096 50331614 50327519 24G Linux filesystem
/dev/nvme0n1p128 2048 4095 2048 1M BIOS boot
Partition table entries are not in disk order.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
[ec2-user@ip-10-0-20-15 ~]$ sudo partprobe
[ec2-user@ip-10-0-20-15 ~]$ sudo fdisk -l
Disk /dev/nvme0n1: 24 GiB, 25769803776 bytes, 50331648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 70E4A118-98BD-4BF4-8DF9-6926A964902A
Device Start End Sectors Size Type
/dev/nvme0n1p1 4096 50331614 50327519 24G Linux filesystem
/dev/nvme0n1p128 2048 4095 2048 1M BIOS boot
Partition table entries are not in disk order.
[ec2-user@ip-10-0-20-15 ~]$ sudo xfs_growfs /
meta-data=/dev/nvme0n1p1 isize=512 agcount=4, agsize=524159 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1 spinodes=0
data = bsize=4096 blocks=2096635, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2096635 to 6290939
```
Related videos on Youtube
cyberz
Updated on September 18, 2022Comments
-
cyberz almost 2 years
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 evenrm
+mkpart
combination, but they will both complain about the partition being mounted.How can I do that?
-
cyberz over 10 yearsA way available out of the box on RHEL/CentOS would be highly appreciated
-
-
cyberz over 10 yearsLooks nice, but is not included by default on CentOS. Any more standard ways? I mean, a redhat-like system should be able to self resize without relying on external programs
-
Admin over 10 yearshe probably not using ext2/ext3/ext4, otherwise resize2fs should work on the fly ?
-
Rod Smith over 10 yearsThere is no tool that ships with CentOS that will do the job. You must go out of the CentOS repository to do what you want. Note that almost all other distributions (including Fedora) include
gdisk
in their repositories, and I've heard thatgdisk
will be included in the next version of RHEL (and therefore of CentOS). -
cyberz over 10 yearsThank you for the answer and the comment, it's exactly the information i was looking for
-
jornane almost 10 years
gdisk
is available in EPEL. -
jmtd over 9 years@Antony Lee: if you pass
-r
tolvextend
, then it invokesresize2fs
for you. -
Alexandre Bourlier over 7 yearsI tried both
partx
andpartprobe
but eventually had to reboot. Thank you anyway for those tips -
piit79 over 6 yearsAwesome! Thanks especially for the
partprobe
step - I always thought it is necessary to reboot when altering partition table with any mounted partitions. -
Teo Klestrup Röijezon over 5 yearsKeep in mind that destroying and recreating the partition will generate a new PARTUUID for the partition, which is otherwise the only reliable and filesystem-independent way for fstab/GRUB/etc to reliably identify partitions in multi-disk setups.
-
Keith over 5 years'p' will show you the UUID of the disk. 'i' will show you the UUID of a partition.
-
sgohl about 3 yearsdoes not work at all. always losing the filesystem, even keeping the uniq GUID. w writes a new partition overwriting the old fs signature
-
2072 over 2 yearsJust to update things for 2022. On Debian 10 after increasing a virtual disk from Virtualbox, I just launched parted, selected the device and then it detected that not all the space was used by the GPT partition and proposed me to fix it which I did, and then I just used gparted to extend the ext4 partition while it was still mounted. No problem.