Resize a LVM partition when not the last partition on linux disk of Azure

Question 1

We create Oracle linux VMs in Azure using Terraform. We have recently had to switch from Oracle Linux 8.9 to 9.x . As the image used in azure is smaller than the disk we assign, we need to resize it.

lsblk output in 8.9:

[root@QMI-ORACLELINUX-9f11a7 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 500G 0 disk
├─sda1 8:1 0 800M 0 part /boot
├─sda2 8:2 0 498.7G 0 part
│ ├─rootvg-rootlv 252:0 0 249G 0 lvm /
│ └─rootvg-crashlv 252:1 0 249.7G 0 lvm /var/crash
├─sda14 8:14 0 4M 0 part
└─sda15 8:15 0 495M 0 part /boot/efi
sdb 8:16 0 16G 0 disk
└─sdb1 8:17 0 16G 0 part /mnt
[root@QMI-ORACLELINUX-9f11a7 ~]#

Commands we used to use to do this in 8.9 are:

 rootdisk=$(df --type=xfs|grep \/dev\/sd | sed -e's/[0-9].*//')
 sudo gdisk -l $rootdisk
 sudo growpart $rootdisk 2
 sudo pvresize $rootdisk"2"
 sudo lvextend -l +49%FREE /dev/rootvg/rootlv
 sudo lvextend -l +100%FREE /dev/mapper/rootvg-crashlv
 sudo xfs_growfs /dev/rootvg/rootlv
 sudo xfs_growfs /dev/mapper/rootvg-crashlv

However this is failing in 9.x.

lsblk output:

[root@QMI-ORACLELINUX-6ba1eb ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 500G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 800M 0 part /boot
├─sda3 8:3 0 48.1G 0 part
│ ├─rootvg-rootlv 252:0 0 38.1G 0 lvm /
│ └─rootvg-crashlv 252:1 0 10G 0 lvm /var/crash
├─sda4 8:4 0 1K 0 part
└─sda5 8:5 0 99M 0 part /boot/efi
sdb 8:16 0 16G 0 disk
└─sdb1 8:17 0 16G 0 part /mnt

Output from gdisk in 8.9:

[root@QMI-ORACLELINUX-9f11a7 ~]# gdisk -l $rootdisk
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
 MBR: protective
 BSD: not present
 APM: not present
 GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1048576000 sectors, 500.0 GiB
Model: Virtual Disk
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): A150068F-0D71-4690-B5A3-F2238DFB880E
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1048575966
Partitions will be aligned on 2048-sector boundaries
Total free space is 4061 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
 1 1026048 2664447 800.0 MiB 8300
 2 2664448 1048575966 48.1 GiB 8E00
 14 2048 10239 4.0 MiB EF02
 15 10240 1024000 495.0 MiB EF00 EFI System Partition

Output from gdisk in 9.*:

[root@QMI-ORACLELINUX-6ba1eb ~]# gdisk -l $rootdisk
GPT fdisk (gdisk) version 1.0.7
Partition table scan:
 MBR: protective
 BSD: not present
 APM: not present
 GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1048576000 sectors, 500.0 GiB
Model: Virtual Disk
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): A91E9F93-83E1-4DCF-959B-5ECA8D76F7DC
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1048575966
Partitions will be aligned on 2048-sector boundaries
Total free space is 945817533 sectors (451.0 GiB)
Number Start (sector) End (sector) Size Code Name
 1 2048 4095 1024.0 KiB 8300 Linux filesystem
 2 4096 1642495 800.0 MiB 8300 Linux filesystem
 3 1642496 102557695 48.1 GiB 8E00 Linux LVM
 5 102557696 102760447 99.0 MiB 0700 Microsoft basic data

on 9.* I get an error with growpart , and I assume this is caused by the "Microsoft basic data" partition getting in the way.

However I can't find a way to move it. I know it can be done as there are GUI tools to move partitions, but I can't find the way to do it from the command line. This needs to be scripted so Really hoping someone else has faced this issue and can provide some suggestions.

Thanks.

UPDATE: Here is what worked. Thanks for all the help!

PARTED_OUTPUT=$(parted -s $rootdisk unit s print free| grep -i "Free space" | tail -1 )
START_SECTOR=$(echo "$PARTED_OUTPUT" | awk '{print 1ドル}' | sed 's/s$//')
# END_SECTOR=$(echo "$PARTED_OUTPUT" | awk '{print 2ドル}' | sed 's/s$//')
SIZE=$(echo "$PARTED_OUTPUT" | awk '{print 3ドル}' |sed -e 's/s//')
PSIZE=$(( $SIZE / 2 ))
echo "Free space detected: Start=$START_SECTOR, Total size=$SIZE, Partition Size=$PSIZE"
lastpart=$(fdisk -l $rootdisk -o Device|tail -1|sed -e "s|$rootdisk||")
nextpart=$(($lastpart + 1))
echo $nextpart
END_SECTOR=$(($START_SECTOR + $PSIZE ))
echo $nextpart:$START_SECTOR:$END_SECTOR
sgdisk --new=$nextpart:$START_SECTOR:$END_SECTOR $rootdisk
partprobe
pvcreate "$rootdisk"$nextpart
vgextend rootvg "$rootdisk"$nextpart
lvextend -r /dev/rootvg/rootlv "$rootdisk"$nextpart
nextpart=$(( $lastpart + 2 ))
START_SECTOR=$(( $END_SECTOR + 1 ))
END_SECTOR=$(( $END_SECTOR + $PSIZE -1 ))
echo $nextpart:$START_SECTOR:$END_SECTOR
sgdisk --new=$nextpart:$START_SECTOR:$END_SECTOR $rootdisk
partprobe
pvcreate "$rootdisk"$nextpart
vgextend rootvg "$rootdisk"$nextpart
lvextend -r /dev/rootvg/crashlv "$rootdisk"$nextpart

Question 2

The solution seems to be to create an additional partition instead of increasing an existing one and then add it with vgextend to the VG rootvg.

Question 3

I tried that and I got an error about too many primary partitions. I think I might have found a solution with sfdisk --move-data , but i'm still working though it. I have to reboot after that command before continuing so it's not optimal.

Question 4

The error "too many primary partitions" indicates the partitioning tool is trying to make MBR partitions. Your system has GPT partitioning, in which all partitions are equal: primary partitions do not exist in GPT. Make sure you're trying to make the new partition with a GPT-aware tool.

Question 5

A small "Microsoft" probably fat formatted partition /boot/efi is for boot, you need that.

Inconvenient differences

A couple assumptions about your partition table have changed from OL8 to OL9

1 MB partition 1 added. Maybe this is supposed to be reserved for a BIOS boot partition like partition 14 was on your EL8, but its type is currently generic Linux filesystem.
Assumption of the script that $rootdisk is partition 2 is broken, it is currently 3.
EFI system partition (ESP) is now after 48 something GB of data. Bootloader can handle this fine, however growpart will only extend into empty space after the partition in question.
ESP is now not type EF00 and smaller at 99 MB. Type is likely a problem, size might not be.

Partition numbers are not disk order

High numbered partitions early in the disk is a trick I have observed before in some generic EL8 kickstarts, takes some sgdisk commands in %pre to pull it off. Only necessary because some people make legacy assumptions about disk partitions, per that kickstart's comments:

# Pre-create the biosboot and EFI partitions
# - Ensure that efi and biosboot are created at the start of the disk to
# allow resizing of the OS disk.
# - Label biosboot and efi as sda14/sda15 for better compat - some tools
# may assume that sda1/sda2 are '/boot' and '/' respectively.

Doing changes

As always, prior to storage changes backup any important data, and test on an unimportant instance.

sgdisk can change types, if my assumptions about what they should be are correct:

sgdisk --typecode=1:EF02 /dev/sda
sgdisk --typecode=5:EF00 /dev/sda

As to moving ESP earlier, note the adjacent sector numbers, there is no space large enough before sector 102760447. I assume sda2 ( /boot ? ) cannot be reduced.

Fortunately, you are using LVM, so you can move around physical volumes, even rootvg while the system is being used. And fortunately there is unused space on the disk. You have another disk which could be used for LVM, however I don't know what space it has, and avoided making it also required for rootvg.

Start with a PV of the same size, at the end of what exists now plus some margin. Move the LVs, then remove the old PV, and delete its partition.

# sector 102760447 is 52.6 GB we need a bit more
sgdisk --new=6:55G:+48.1G /dev/sda
sgdisk --typecode=6:8e00 /dev/sda
vgextend rootvg /dev/sda6
pvmove /dev/sda3
vgreduce --all rootvg
sgdisk --backup --delete=3 /dev/sda

Now there is empty space where there was partition 3 before. ESP can be moved into there at that point, perhaps with a different tool sfdisk.

ESP is not really used by the instance other than applying updates and is also small, so can get by with unmount and copy. I considered recommending create a new partition and copy yourself like with dd, but that would be more steps.

umount /boot/efi
echo '1642496,' | sfdisk --backup --move-data=@default /dev/sda -N 5

Here would be the opportunity to extend ESP bigger if desired. Or start ESP a bit later and extend /boot, if desired.

LVM partition is now at the end of the disk. Although there is a 50 something GB hole before it starts.

Create another partition in the gap, and extend LVM with vgextend. LVM will operate with multiple PVs, it is based on the multi device subsystem after all.

I made the gap big enough to fit the former PV size of 48.1G plus the moved ESP. Can pvmove again to migrate LVM to the partition earlier in the disk. vgreduce again, delete the partition, resulting in one PV with no gap between partitions.

Avoiding doing many partition moves

Many steps to move things around, time consuming and error prone.

Now, during your major version upgrade, is an opportunity to do a storage migration in a way that makes sense to you.

Ideally, the partitions were created new such that the big data partition starts at the end. Not necessarily as fancy as the dual-mode kickstarts I linked, although they do manage to put all the boot nonsense first. Script creating new instances from empty disks, and consider using them.

Personally I have let LVM have PVs on entire disks without partitioning, such as all of /dev/sdc. Although not everyone prefers storage outside a parition table, or VMs with multiple disks.

Bonus script review

How you derive $rootdisk seems fragile, I don't see how xfs mounts are relevant to finding LVM PVs.

Also after my steps the data partition is not number 2, so scripting needs to deal with it, or the partition fixed to match the script.

On udev systems, links to LVM PVs by their UUID are maintained in /dev/disk/by-id/lvm-pv*

pvresize can figure it out given such a symlink
growpart however requires disk and parition number as seperate arguments. Could use realpath on the symlink, then split it into disk and number in shell.
If there are multiple PVs, you need to figure out which one somehow, rather than a * shell glob.

xfs_growfs commands can be moved to lvextend --resizefs options on the existing lvextend commands. Mostly so it also supports ext4 file system type. LVM does some additional sanity checks, although extend is safer than reduce.

Question 6

Thank you for such a comprehensive answer ! Given this is a throw-away demo environment, In the short term I'm only implementing the bare minimum to get past this. The following is what i've had to do. Note as we have grown the disk, we only care about using the free space at the end. Can't put everything in one comment so what I did in update to original post.

John Mahowald 9134 silver badges4 bronze badges · Accepted Answer · 2025-12-14 15:51:31Z

A small "Microsoft" probably fat formatted partition /boot/efi is for boot, you need that.

Inconvenient differences

A couple assumptions about your partition table have changed from OL8 to OL9

1 MB partition 1 added. Maybe this is supposed to be reserved for a BIOS boot partition like partition 14 was on your EL8, but its type is currently generic Linux filesystem.
Assumption of the script that $rootdisk is partition 2 is broken, it is currently 3.
EFI system partition (ESP) is now after 48 something GB of data. Bootloader can handle this fine, however growpart will only extend into empty space after the partition in question.
ESP is now not type EF00 and smaller at 99 MB. Type is likely a problem, size might not be.

Partition numbers are not disk order

High numbered partitions early in the disk is a trick I have observed before in some generic EL8 kickstarts, takes some sgdisk commands in %pre to pull it off. Only necessary because some people make legacy assumptions about disk partitions, per that kickstart's comments:

# Pre-create the biosboot and EFI partitions
# - Ensure that efi and biosboot are created at the start of the disk to
# allow resizing of the OS disk.
# - Label biosboot and efi as sda14/sda15 for better compat - some tools
# may assume that sda1/sda2 are '/boot' and '/' respectively.

Doing changes

As always, prior to storage changes backup any important data, and test on an unimportant instance.

sgdisk can change types, if my assumptions about what they should be are correct:

sgdisk --typecode=1:EF02 /dev/sda
sgdisk --typecode=5:EF00 /dev/sda

As to moving ESP earlier, note the adjacent sector numbers, there is no space large enough before sector 102760447. I assume sda2 ( /boot ? ) cannot be reduced.

Fortunately, you are using LVM, so you can move around physical volumes, even rootvg while the system is being used. And fortunately there is unused space on the disk. You have another disk which could be used for LVM, however I don't know what space it has, and avoided making it also required for rootvg.

Start with a PV of the same size, at the end of what exists now plus some margin. Move the LVs, then remove the old PV, and delete its partition.

# sector 102760447 is 52.6 GB we need a bit more
sgdisk --new=6:55G:+48.1G /dev/sda
sgdisk --typecode=6:8e00 /dev/sda
vgextend rootvg /dev/sda6
pvmove /dev/sda3
vgreduce --all rootvg
sgdisk --backup --delete=3 /dev/sda

Now there is empty space where there was partition 3 before. ESP can be moved into there at that point, perhaps with a different tool sfdisk.

ESP is not really used by the instance other than applying updates and is also small, so can get by with unmount and copy. I considered recommending create a new partition and copy yourself like with dd, but that would be more steps.

umount /boot/efi
echo '1642496,' | sfdisk --backup --move-data=@default /dev/sda -N 5

Here would be the opportunity to extend ESP bigger if desired. Or start ESP a bit later and extend /boot, if desired.

LVM partition is now at the end of the disk. Although there is a 50 something GB hole before it starts.

Create another partition in the gap, and extend LVM with vgextend. LVM will operate with multiple PVs, it is based on the multi device subsystem after all.

I made the gap big enough to fit the former PV size of 48.1G plus the moved ESP. Can pvmove again to migrate LVM to the partition earlier in the disk. vgreduce again, delete the partition, resulting in one PV with no gap between partitions.

Avoiding doing many partition moves

Many steps to move things around, time consuming and error prone.

Now, during your major version upgrade, is an opportunity to do a storage migration in a way that makes sense to you.

Ideally, the partitions were created new such that the big data partition starts at the end. Not necessarily as fancy as the dual-mode kickstarts I linked, although they do manage to put all the boot nonsense first. Script creating new instances from empty disks, and consider using them.

Personally I have let LVM have PVs on entire disks without partitioning, such as all of /dev/sdc. Although not everyone prefers storage outside a parition table, or VMs with multiple disks.

Bonus script review

How you derive $rootdisk seems fragile, I don't see how xfs mounts are relevant to finding LVM PVs.

Also after my steps the data partition is not number 2, so scripting needs to deal with it, or the partition fixed to match the script.

On udev systems, links to LVM PVs by their UUID are maintained in /dev/disk/by-id/lvm-pv*

pvresize can figure it out given such a symlink
growpart however requires disk and parition number as seperate arguments. Could use realpath on the symlink, then split it into disk and number in shell.
If there are multiple PVs, you need to figure out which one somehow, rather than a * shell glob.

xfs_growfs commands can be moved to lvextend --resizefs options on the existing lvextend commands. Mostly so it also supports ext4 file system type. LVM does some additional sanity checks, although extend is safer than reduce.

Thank you for such a comprehensive answer ! Given this is a throw-away demo environment, In the short term I'm only implementing the bare minimum to get past this. The following is what i've had to do. Note as we have grown the disk, we only care about using the free space at the end. Can't put everything in one comment so what I did in update to original post.

Stack Exchange Network

Resize a LVM partition when not the last partition on linux disk of Azure

1 Answer 1

Inconvenient differences

Partition numbers are not disk order

Doing changes

Avoiding doing many partition moves

Bonus script review

You must log in to answer this question.

Hot Network Questions

Resize a LVM partition when not the last partition on linux disk of Azure

1 Answer 1

Inconvenient differences

Partition numbers are not disk order

Doing changes

Avoiding doing many partition moves

Bonus script review

You must log in to answer this question.

Related

Hot Network Questions