growpart does not work for lvm

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1799953

Launchpad details

affected_projects = ['cloud-utils']
assignee = None
assignee_name = None
date_closed = None
date_created = 2018-10-25T13:34:42.149828+00:00
date_fix_committed = None
date_fix_released = None
id = 1799953
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1799953
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = triaged
submitter = smoser
submitter_name = Scott Moser
tags = []
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2018-10-25T13:34:42.149828+00:00

Similar to bug 1491148, growpart does not support growing a lvm device. It would be good if growpart in conjunction with cloud-init could recognize that the filesystem was on a volume and grow the underlying partition or volume group.

Related bugs: bug 1491148: growpart doesn't work with mdraid devices

[ubuntu-server-builder]

Launchpad user Gregory Young(gregoryyoungswi) wrote on 2020-01-15T01:48:25.988017+00:00

If this is accurate, I suspect the bug is in the cloud-init call to growpart, as I am using 0.31 successfully on CentOS 7 appliances with a LVM. There obviously are further steps needed to extend the LVM PV and LVs, along with the filesystem, but 0.31 seems to work well at growing the raw disk partition (we had to use the project release of 0.31 because the EL7 bundled package includes a much older release that mangles 2TB > GPT disks due to Bug #1259703).

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-07-10T14:25:48.385973+00:00

It seems all we have to actually do is call 'pvresize' to make this all work.

That would mean after resize, we'd just have to do something like:

part_path here assumed to be full path to partition

if command -v pvs && pvs -o pvname | grep -q "${part_path}$" debug "$part_path was a lvm physical volume, using pvresize" pvresize $part_path fi

For reference, see below. I just did a quick test with loop device (as root):

$ truncate --size 2G /tmp/my.img $ losetup --find --show /tmp/my.img /dev/loop5

add partition 1 to be 1G of the 2G available .. manually

$ fdisk /dev/loop5

this is necessary because fdisk doesn't do the addpart.

$ partprobe /dev/loop5

$ grep loop5 /proc/partitions 7 5 2097152 loop5 259 6 1048576 loop5p1

$ pvcreate /dev/loop5p1 Physical volume "/dev/loop5p1" successfully created. $ vgcreate testvg0 /dev/loop5p1 Volume group "testvg0" successfully created $ pvdisplay /dev/loop5p1 --- Physical volume --- PV Name /dev/loop5p1 VG Name testvg0 PV Size 1.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 255 Free PE 255 Allocated PE 0 PV UUID o3d9dK-x7iA-8jws-Sl99-YFio-NQUs-CMCPuS

$ vgdisplay testvg0 --- Volume group --- VG Name testvg0 System ID
Format lvm2 ... Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 1020.00 MiB PE Size 4.00 MiB Total PE 255 Alloc PE / Size 0 / 0
Free PE / Size 255 / 1020.00 MiB VG UUID N7I14w-i0Tr-7Sqs-8wOQ-7fDZ-l2oL-LdnoS2

$ growpart /dev/loop5 1 CHANGED: partition=1 start=2048 old: size=2097152 end=2099200 new: size=4192223 end=4194271

$ grep loop5 /proc/partitions 7 5 2097152 loop5 259 7 2096111 loop5p1

it didn't grow by itself.

$ pvdisplay /dev/loop5p1 | grep PV.Size --- Physical volume --- PV Size 1.00 GiB / not usable 4.00 MiB

$ pvresize /dev/loop5p1 /dev/sda: open failed: No medium found Physical volume "/dev/loop5p1" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized

grow it

$ pvresize /dev/loop5p1 Physical volume "/dev/loop5p1" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized

$ pvdisplay /dev/loop5p1 --- Physical volume --- PV Name /dev/loop5p1 VG Name testvg0 PV Size <2.00 GiB / not usable 1.98 MiB Allocatable yes PE Size 4.00 MiB Total PE 511 Free PE 511 Allocated PE 0 PV UUID o3d9dK-x7iA-8jws-Sl99-YFio-NQUs-CMCPuS

and it seems to have taken on the vg

$ sudo vgdisplay testvg0 --- Volume group --- VG Name testvg0 System ID
Format lvm2 Metadata Areas 1 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size <2.00 GiB PE Size 4.00 MiB Total PE 511 Alloc PE / Size 0 / 0
Free PE / Size 511 / <2.00 GiB VG UUID N7I14w-i0Tr-7Sqs-8wOQ-7fDZ-l2oL-LdnoS2

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-07-10T14:30:26.047606+00:00

As a note... it seems like there is almost no fallout of doing this. a.) subsequent calls to pvresize (possibly added to users' scripts to finish this) will still exit 0 b.) there is no way other way that i'm aware of to use the space on that pv. (you can't add a second VG on that pv or anything like that). By growing the partition we're already stopping a user from using that space in any way other than to add it to the PV.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-07-10T15:38:23.689076+00:00

It seems like to determine if the partition we grew is a lvm pv, we should probably just use 'pvs' with explicit input rather than grep. and probably should use 'lvm' command rather than 'pvs'.

has_cmd() { command -v "$1" >/dev/null ; }

'lvm pvs ' seems to exit 0 when is a pv and 5 otherwise.

if has_cmd lvm && lvm pvs --readonly -o pv_name "$part_path" >/dev/null 2>&1; then debug "$part_path was a lvm pv, going to use pvresize" lvm pvresize "$part_path" || echo "bad news, lvm pvresize $part_path failed" fi

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-07-16T15:25:49.774955+00:00

https://github.com/canonical/cloud-utils/pull/9

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-12-01T13:47:36.552948+00:00

This is fix-released in 0.32.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-12-01T14:09:35.521597+00:00

Growpart grows a partition (/dev/sda2) on a block device (/dev/sda).

So right now there might be the following scenarios:  a.) [supported in cloud-init and growpart] root filesystem on partition (/dev/sda2)  b.) [supported in growpart] root filesystem on an LV (/dev/myvg0/mylv0 -> /dev/dm-1)       where the LV is part of VG that includes PV that is a partition (/dev/sda1)       this is partially supported because cloud-init won't do the right thing.  The right       thing would be to call growpart /dev/sda 1  c.) root filesystem on block device (/dev/sda) - odd, but could happen  d.) root filesystem on LV that is pat of a VG that includes a PV that is a full disk (/dev/sda)

'c' and 'd' should not need growpart... when the block device is discovered its size should be correctly identified by the kernel and a 'resizefs' should be needed but no need for growpart.

The code I added hoped to add support for 'b' in growpart, but should not have broken 'd'.

For cloud-init to add support for 'b', we would need to determine the situation and call growpart on /dev/sda1.

[ubuntu-server-builder]

Launchpad user James Falcon(falcojr) wrote on 2021-05-05T20:34:34.506989+00:00

This bug is believed to be fixed in cloud-init in version 21.2. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2021-05-05T20:46:40.402486+00:00

This is not fixed in cloud-init 21.2 as reported. It was fixed at https://github.com/canonical/cloud-init/pull/721 under commit 74fa008bfcd3263eb691cc0b3f7a055b17569f8b. but then reverted under https://github.com/canonical/cloud-init/pull/887 .

So... marking this Triaged.

[zhaohuijuan]

Launchpad user Scott Moser(smoser) wrote on 2021-05-05T20:46:40.402486+00:00

This is not fixed in cloud-init 21.2 as reported. It was fixed at #721 under commit 74fa008. but then reverted under #887 .

So... marking this Triaged.

We also had this issue(https://bugzilla.redhat.com/show_bug.cgi?id=1810878), looking forward to get fix in the near future. Thanks!

[gilou]

Hi, What's the way to go should we get some love to that issue, which … is annoying. At least being able to resize the partition holding the PV, then pvresize, then fs resize would be good on LVM backed root.

Should we get back on #721 base, fix what led to the revert @ #887 , and have the tests pass?