Description of problem:
LVM2 has added a new check in pvscan:
pvscan PV /dev/sda ignore for size 204800 not matching device 2097152.
This breaks virt-resize which resizes the underlying disk
before calling pvresize to resize the device.
Please remove this check, it's wrong.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
There is a reproducer here:
Upstream commit was:
Author: David Teigland <firstname.lastname@example.org>
Date: Fri Apr 5 16:44:00 2019 -0500
pvscan: ignore device with incorrect size
If a device looks like a PV, but its size does not
match the PV size in the metadata, then skip it for
purposes of autoactivation. It's probably not wrong
device for the PV.
I understand that we allow the device to be larger than the PV (for the obvious case of pvresize), but I did not believe that autoactivation needed to worry about this case. I guess you have found a case where autoactivation does need to worry about it. The check was another attempt to exclude md component devices with superblocks at the end of the devices, but I'll have to rework that check.
Incidentally, even with this fixed, cases like this are probably better off using direct activation instead of event based activation (set event_activation=0 in lvm.conf).
PV size may not match size of device at any time - it's not related to autoactivation.
User can set explicitly the size of used portion of device with 'pvcreate --setphysicalvolumesize'.
So if we have put any filtering rule based on PV matching device size - this limitation needs to be restored back.
i.e. user can resize up/down partition table anytime later on - lvm2 only uses the size specified in PV header.
My workstation fails to boot since filesystems from fstab can not be found due to not activated volumes,
which used to work before (so restriction in current form causing regression).
It drops into maintenance mode and can be booted only after explicit 'vgchange -a y'.
(users probably wouldn't be very happy after update)
These two commits fix the problem:
md component detection for differing PV and device sizes
This check was mistakenly removed when shifting code in commit
"separate code for setting devices from metadata parsing".
Put it back with some new conditions.
pvscan: fix PV online when device has a different size
Fix commit 7836e7aa1c17216ed368fda89cfc805a07efda81
"pvscan: ignore device with incorrect size"
which caused pvscan to not consider a PV online (for purposes
of event based activation) if the PV and device sizes differed.
This helped to avoid mistaking MD components for PVs, and is
replaced by triggering an md component check when PV and device
sizes differ (which happens in set_pv_device).
How to reproduce this? QE will need a better reproducer than using virt-resize IMO.
I have a VM with PVs which do not match the size of underlying device and it boots fine and the LV is activated. I tried both PV on /dev/sda and with a partitioned device.
What am I missing?
There is a reproducer in:
which does not involve running virt-resize.
Along with the fixes I pushed a test that fails without the fixes:
Thank you for simplified reproducer (Comment 8). Adding QA ack for 8.1
Verified with latest rpms.
# guestfish --ro -a test1.img run : debug ll /dev/mapper
drwxr-xr-x 2 root root 120 Aug 14 12:36 .
drwxr-xr-x 17 root root 2640 Aug 14 12:36 ..
lrwxrwxrwx 1 root root 7 Aug 14 12:36 VG-boot -> ../dm-0
lrwxrwxrwx 1 root root 7 Aug 14 12:36 VG-root -> ../dm-2
lrwxrwxrwx 1 root root 7 Aug 14 12:36 VG-swap -> ../dm-1
crw------- 1 root root 10, 236 Aug 14 12:36 control
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.