Discussion:
[linux-lvm] inner VG inside chroot not visible inside chroot
Xen
2017-01-07 00:48:30 UTC
Permalink
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.
Xen
2017-01-07 06:51:27 UTC
Permalink
Post by Xen
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.

Loading...