RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (
issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the
Red Hat customer portal. If you're not, please head to the "
RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "
NEW", "
ASSIGNED", and "
POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "
kernel", "
kernel-rt", and "
kpatch" are only migrated if still in "
NEW" or "
ASSIGNED". If you cannot log in to RH Jira, please consult
article #7032570. That failing, please send an e-mail to the RH Jira admins at
rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "
CLOSED", resolution "
MIGRATED", and set with "
MigratedToJIRA" in "
Keywords". The link to the successor Jira issue will be found under "
Links", have a little "two-footprint" icon next to it, and direct you to the "
RHEL project" in Red Hat Jira (issue links are of type "
https://issues.redhat.com/browse/RHEL-XXXX", where "
X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 # vgs 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". # lvmdiskscan [..] /dev/md2 [ <230.76 GiB] LVM physical volume [..] /dev/md10 [ <1.82 TiB] LVM physical volume [..] 2 LVM physical volumes # pvs PV VG Fmt Attr PSize PFree /dev/md2 yeagervg lvm2 a-- <230.76g <156.76g Workarounds - systemctl restart lvm2-lvmetad - pvscan --cache /dev/mdXX - yum downgrade lvm2-libs-2.02.180-10.el7_6.2 \ lvm2-2.02.180-10.el7_6.2 \ device-mapper-event-1.02.149-10.el7_6.2 \ device-mapper-event-libs-1.02.149-10.el7_6.2 \ device-mapper-1.02.149-10.el7_6.2 \ device-mapper-libs-1.02.149-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): lvm2-2.02.180-10.el7_6.3.x86_64 How reproducible: Reboot the computer running the specified version of the LVM2 packages. Run LVM user space commands to query LVM. Steps to Reproduce: 1. Reboot 2. pvs 3. pvdisplay /dev/mdxx Actual results: 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. Expected results: All filesystems mounted ok. pvs, vgs, lvs show everything as expected Additional info: 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