I had problem with my system (faulty internal power cable). When I got the system back up and running, arrays rebuilding, etc, I seem to have a situation where the pvs command (and vgs and lvs) reports No device found for PV <UUID> but the logical volume which is on the supposedly missing physical volume can be successfully mounted as their DM devices exist and are mapped in /dev/mapper.The PV device is an md-raid RAID10 array, which seems fine, except for the confusion that it's not appearing in the pvs output.I assume this is a problem with some internal tables being out of sync. How do I get things mapped correctly (wthout a reboot, which, I assume would fix it)?Update:A reboot did NOT fix the problem. I believe the issue is due to the configuration of the 'missing' PV (/dev/md99) as a RAID10 far-2 array built from a 750b disk (/dev/sdk) and a RAID0 array (/dev/md90) build from a 250GB disk (/dev/sdh) and a 500Gb disk (/dev/sdl). It seems from the output of pvscan -vvv that the lvm2 signature is found on /dev/sdh, but not on /dev/md99.    Asking lvmetad for VG f1bpcw-oavs-1SlJ-0Gxf-4YZI-AiMD-WGAErL (name unknown)  Setting response to OK  Setting response to OK  Setting name to b  Setting metadata/format to lvm2    Metadata cache has no info for vgname: b  Setting id to AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN  Setting format to lvm2  Setting device to 2160  Setting dev_size to 1464383488  Setting label_sector to 1    Opened /dev/sdh RO O_DIRECT  /dev/sdh: size is 488397168 sectors    /dev/sdh: block size is 4096 bytes    /dev/sdh: physical block size is 512 bytes    Closed /dev/sdh  /dev/sdh: size is 488397168 sectors    Opened /dev/sdh RO O_DIRECT    /dev/sdh: block size is 4096 bytes    /dev/sdh: physical block size is 512 bytes    Closed /dev/sdh    /dev/sdh: Skipping md component device  No device found for PV AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN.    Allocated VG b at 0x7fdeb00419f0.  Couldn't find device with uuid AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN.    Freeing VG b at 0x7fdeb00419f0.The only reference to /dev/md99, which should be the PV, is when it's added to the device cache.Update 2:Stopping lvm2-lvmetad and repeating the pvscan confirms than the issue is that the system is confused about which PVs to use as it's finding 2 with the same UUID    Using /dev/sdh    Opened /dev/sdh RO O_DIRECT    /dev/sdh: block size is 4096 bytes    /dev/sdh: physical block size is 512 bytes  /dev/sdh: lvm2 label detected at sector 1  Found duplicate PV AzKyTe5Ut4dxgqtxEc7V9vBkm5mOeMBN: using /dev/sdh not /dev/md99    /dev/sdh: PV header extension version 1 found  Incorrect metadata area header checksum on /dev/sdh at offset 4096    Closed /dev/sdh    Opened /dev/sdh RO O_DIRECT    /dev/sdh: block size is 4096 bytes    /dev/sdh: physical block size is 512 bytes  Incorrect metadata area header checksum on /dev/sdh at offset 4096    Closed /dev/sdh    Opened /dev/sdh RO O_DIRECT    /dev/sdh: block size is 4096 bytes    /dev/sdh: physical block size is 512 bytes    Closed /dev/sdh  Incorrect metadata area header checksum on /dev/sdh at offset 4096    Telling lvmetad to store PV /dev/sdh (AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN)  Setting response to OKsince this configuration was only meant to be temporary, I think I'd do better to rearrange my disk usage.Unless anyone can tell me how to explicitly override the order in which pvscan views devices?
Command 'pvs' says PV device not found, but LVs are mapped and mounted
lvm;md
The problem appears to be pvscan getting confused over seeing the same UUID on both a component device of the RAID array and the RAID array itself. I assume this is avoided normally by recognising that the device is a direct component. In my case, I had created a situation where the device was not directly a component of the RAID device which should be the PV.My solution was to backup the LVs, force the array to be degraded and then reconfigure the disks so as not to use the multilevel RAID. Note that after another reboot the device lettering had changed. 500Gb = /dev/sdi, 250Gb = /dev/sdj, 750Gb = /dev/sdk# mdadm /dev/md99 --fail --force /dev/md90# mdadm /dev/md99 --remove failed# mdadm --stop /dev/md90# wipefs -a /dev/sdi /dev/sdj               # wipe components# systemctl stop lvm2-lvmetad# pvscan -vvv# pvs..... /dev/md99 is now correctly reported as the PV for VG b# fdisk /dev/sdi...... Create 2 partitions of equal size, i.e. 250Gb# fdisk /dev/sdj...... Create a single 250Gb patitiion# mdadm /dev/md91 --create -lraid5 -n3 /dev/sdi1 /dev/sdj1 missing# mdadm /dev/md92 --create -lraid1 -n2 /dev/sdi2 missing# pvcreate /dev/md91 /dev/md92# vgextend b /dev/md91 /dev/md92# pvmove /dev/md99# vgreduce b /dev/md99# pvremove /dev/md99# mdadm --stop /dev/md99# wipefs -a /dev/sdk# fdisk /dev/sdk..... Create 3 250Gb partitions# mdadm /dev/md91 --add /dev/sdk1# mdadm /dev/md92 --add /dev/sdk2Moral of the story:Do not introduce too many levels of indirection into the filesystem!