[linux-lvm] inner VG inside chroot not visible inside chroot

[linux-lvm] inner VG inside chroot not visible inside chroot

[Xen]

So I had this script that would check the chain of PVs used for some LV 
if used in an embedded VG.

Meaning an outer PV contains a VG contains a LV that is the PV to 
another VG.

This script fails to work currently inside a chroot.

The reason is that not all VGs and LVs are visible inside the chroot. 
Most importantly currently the PV is not visible.

I have bind mounted /sys/, /proc/, /dev/, and /run/.

Outside of the chroot, this is visible:

   msata-pv coll2 -wi-ao----  28.91g
   raid-pv  coll2 -wi-ao---- 464.36g
   boot     msata rwi-aor-p- 240.00m
   root     msata rwi-aor-p-  14.67g

The chroot is to a mount of /dev/msata/root.

Inside the chroot, to the /mnt of /dev/msata/root,

everything is now visible as well but only because lvmetad works because 
I bind mounted /run.

vgdisplay -v   inside the chroot gives:

   --- Physical volumes ---
   PV Name               unknown device
   PV UUID               aCDiCd-EWYT-eKmE-gMST-KpXG-EJA5-0FWy8Z
   PV Status             allocatable
   Total PE / Free PE    7399 / 3582

vgdisplay -v   outside the chroot gives:

   PV Name               /dev/coll2/msata-pv
   PV UUID               aCDiCd-EWYT-eKmE-gMST-KpXG-EJA5-0FWy8Z
   PV Status             allocatable
   Total PE / Free PE    7399 / 3582

If I remove the bind mount for /run, I get

   msata-pv coll2 -wi-ao----  28.91g
   raid-pv  coll2 -wi-ao---- 464.36g

But not the 2 msata volumes, that are both mounted inside the chroot 
(/mnt and /mnt/boot).

The volumes are fully functional though. LVM just doesn't show me their 
devices. Is this to be expected?

I was using the standard LVM tools to obtain this PV. It would be 
possible to use only dmsetup etc. for it,
for example using dmsetup deps /dev/msata/root, to obtaining the name 
with dmsetup info to see whether it is
conforming to an LVM mapping, but rather hard/impossible to see if it is 
an actual regular LV this way?

Actually the split-name function... does not provide that much help for 
that :p.

Particularly in this way it is not possible to see if something is a 
"hidden" LV (such as a meta or image) or actually a regular LV that's 
being referred to. I really wanted to say PV, but from the perspective 
of the script you're really just looking for regular LVs.

The moment you encounter a non-major-252, I'm no longer interested :p.

But in any case:


Why does it not show the mounted LV in the "lvs" table and why does it 
not show the PV that IS visible in the "lvs" table in the output of 
"vgdisplay -v" ?

So, why is that PV set to "unknown device"? And with /run not 
bind-mounted, pvscan will not see the msata volume group at all!

   PV /dev/sdb4            VG coll2           lvm2 [493.26 GiB / 0    
free]
   PV /dev/coll2/raid-pv   VG raid            lvm2 [464.35 GiB / 8.00 GiB 
free]

---> should also show /dev/coll2/msata-pv.

Maybe this gets a little too complicated,

but the msata volume group that is mounted into the chroot, is not 
actually visible inside the chroot, while everything else is.

Regards, Xen.

Re: [linux-lvm] inner VG inside chroot not visible inside chroot

[Xen]

Xen schreef op 07-01-2017 1:48:

> Why does it not show the mounted LV in the "lvs" table and why does it
> not show the PV that IS visible in the "lvs" table in the output of
> "vgdisplay -v" ?

I am sorry.

I had followed Zdenek's advice at some point and had edited some config 
file to set filters.

It was no help at the time for whatever reason but I had forgotten I had 
set it and it had made it to the new system. At which point it caused 
the behaviour described above.

Being new to filters I could not imagine what was causing it ;-).

So much time lost again... and my filesystem is now messed up because of 
the way the old LVM (133) was constantly "exchanging" physical volumes.

The filesystem would enter read-only state but not before causing 
gigantic corruption.

Only to files opened or in use at the time (so mostly cache files etc) 
but still.

lost+found now contains 505 files/dirs on this disk.

And now I am left with the task of returning this filesystem to a proper 
state... it doesn't really get better, this life.

Sorry. Another problem to fix and no time for any of it.