Created attachment 1559468 [details]
journalctl --unit=lvm2-lvmetad # all output from a reboot of the system with the misbehaving version
Description of problem:
Bug identified in CENTOS.
Systems I have affected have two volume groups, both on MD RAID devices. The one providing the logical volume for root etc is unaffected (RAID1), the second one (RAID5) is affected.
I have one system that demonstrates the bug reliably, and a second which is intermittent.
System boots up fine; all volumes mount, but no components of the second volume group (PV, VG, or LVs) are returned by most of the LVM userspace commands - pvs, pvdisplay and so on.
$ df -h | grep mapper
/dev/mapper/yeagervg-lv00sys00 32G 7.1G 25G 23% /
/dev/mapper/datavg-lv01bkp00 400G 337G 64G 85% /srv/data/backup
/dev/mapper/yeagervg-lv00hom00 10G 1.5G 8.6G 15% /home
VG #PV #LV #SN Attr VSize VFree
yeagervg 1 3 0 wz--n- <230.76g <156.76g
# vgdisplay datavg
Volume group "datavg" not found
Cannot process volume group datavg
lvmdiskscan does work.
# pvdisplay /dev/md10
Failed to find physical volume "/dev/md10".
/dev/md2 [ <230.76 GiB] LVM physical volume
/dev/md10 [ <1.82 TiB] LVM physical volume
2 LVM physical volumes
PV VG Fmt Attr PSize PFree
/dev/md2 yeagervg lvm2 a-- <230.76g <156.76g
- systemctl restart lvm2-lvmetad
- pvscan --cache /dev/mdXX
- yum downgrade lvm2-libs-2.02.180-10.el7_6.2 \
I initially identified the issue because I have puppet enforcing the creating of the volume group and volumes; the userspace commands state that these do not exist, so puppet tries, and fails, to recreate them.
Version-Release number of selected component (if applicable):
Reboot the computer running the specified version of the LVM2 packages. Run LVM user space commands to query LVM.
Steps to Reproduce:
3. pvdisplay /dev/mdxx
All filesystems mounted ok.
pvs doesn't show all the physical volumes
vgs doesn't show all the volume groups
lvs doesn't show all the volumes, including ones with mounted filesystems.
All filesystems mounted ok.
pvs, vgs, lvs show everything as expected
I have verbose lvmetad output which I'll attach; I've reconfigured it to run:
/usr/sbin/lvmetad -f -l all
There'll be three attachments comprising output from lvmetad
- booting with the misbehaving version
- a subsequent manual restart of lvmetad
- booting with the previous version
Created attachment 1559469 [details]
journalctl --unit=lvm2-lvmetad # all output from a reboot of the system with the previous version
Created attachment 1559470 [details]
journalctl --unit=lvm2-lvmetad # output when lvmetad is restarted - misbehaving version
'show other bugs' off this ticket did a much better job searching bugzilla than I did.
This looks like a dupe of:
tested with the 7.6 build with the patch included http://people.redhat.com/mcsontos/repos/bz1672336/
half a dozen reboots were successful.