Bug 1703644 - physical volume and volume group not entered into lvmetad cache at boot time
Summary: physical volume and volume group not entered into lvmetad cache at boot time
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-27 07:16 UTC by Ben Prescott
Modified: 2019-09-24 17:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
journalctl --unit=lvm2-lvmetad # all output from a reboot of the system with the misbehaving version (240.88 KB, text/plain)
2019-04-27 07:16 UTC, Ben Prescott
no flags Details
journalctl --unit=lvm2-lvmetad # all output from a reboot of the system with the previous version (121.59 KB, text/plain)
2019-04-27 07:18 UTC, Ben Prescott
no flags Details
journalctl --unit=lvm2-lvmetad # output when lvmetad is restarted - misbehaving version (45.27 KB, text/plain)
2019-04-27 07:19 UTC, Ben Prescott
no flags Details


Links
System ID Priority Status Summary Last Updated
CentOS 15863 None None None 2019-04-27 07:16:21 UTC

Description Ben Prescott 2019-04-27 07:16:22 UTC
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

Comment 2 Ben Prescott 2019-04-27 07:18:01 UTC
Created attachment 1559469 [details]
journalctl --unit=lvm2-lvmetad # all output from a reboot of the system with the previous version

Comment 3 Ben Prescott 2019-04-27 07:19:19 UTC
Created attachment 1559470 [details]
journalctl --unit=lvm2-lvmetad # output when lvmetad is restarted - misbehaving version

Comment 4 Ben Prescott 2019-04-27 07:29:52 UTC
'show other bugs' off this ticket did a much  better job searching bugzilla than I did.

This looks like a dupe of:

https://bugzilla.redhat.com/show_bug.cgi?id=1672336

Comment 5 Ben Prescott 2019-04-27 08:06:17 UTC
tested with the 7.6 build with the patch included http://people.redhat.com/mcsontos/repos/bz1672336/
half a dozen reboots were successful.


Note You need to log in before you can comment on or make changes to this bug.