"dmsetup deps" does not accurately report LVM dependencies, can cause boot failure

I can confirm that this bug affects me too in Ubuntu 8.10.

For me, the scenario is a little different (newly installed system where the VG has many PV:s, of which only one's extents are in use). dmsetup deps still only reports the PV whose extents are in use, and not all PV:s that are required for the VG to start.

dmsetup version 2:1.02.27-3ubuntu2
initramfs-tools version 0.92bubuntu16

Found a workaround that helps in my specific case.

I use only one LV in the VG, so the way I can make sure "dmsetup deps" will report that the LV depends on all PV:s, is by making the LV large enough that it spreads out across the entire VG. Note! I do not need to resize the file system, just extend the LV.

Before:
$ sudo dmsetup deps /dev/mapper/VGsafe-LVroot
1 dependencies : (254, 0)

Workaround:
$ sudo lvextend -L +1000G /dev/mapper/VGsafe-LVroot
  Extending logical volume LVroot to 1.66 TB

After:
$ sudo dmsetup deps /dev/mapper/VGsafe-LVroot
6 dependencies : (254, 5) (254, 4) (254, 3) (254, 2) (254, 1) (254, 0)

If "dmsetup deps" is supposed to work the way it does, I agree with Tony Lewis that initramfs-tools should have a better way of detecting required devices for a LV.

On Tue, Dec 16, 2008 at 10:13:33PM -0000, Hugo Josefson wrote:
> I can confirm that this bug affects me too in Ubuntu 8.10.
> For me, the scenario is a little different (newly installed system where
> the VG has many PV:s, of which only one's extents are in use). dmsetup
> deps still only reports the PV whose extents are in use, and not all
> PV:s that are required for the VG to start.

Surely that's it working as designed?
dmsetup tells you about mapped devices available in the running kernel.

Alasdair
--
<email address hidden>

Alasdair G. Kergon wrote:
> Surely that's it working as designed?
> dmsetup tells you about mapped devices available in the running kernel.
>
I don't think so. "dmsetup deps" indicates the devices that your mapped
device depends on. If a PV is part of a VG, that VG can't start up
until that PV is present. So any LV on that VG is dependent on the PV,
even if the LV doesn't have any extents on the PV. Phew.

But "dmsetup deps" doesn't reflect this - it only shows the PVs that
your LV is extended onto.

So if "dmsetup deps" is intended to show all the devices required to
access your device, then "dmsetup deps" is wrong. However, if it's
meant to only show the PVs the LV is actually residing on, then the
initramfs-toos package is wrong to use this tool to determine what
drivers need to go into the initramfs.

To me it seems that dmsetup is in the wrong.

Tony

On Wed, Dec 17, 2008 at 03:27:39PM -0000, Tony Lewis wrote:
> Alasdair G. Kergon wrote:
> > Surely that's it working as designed?
> > dmsetup tells you about mapped devices available in the running kernel.

> I don't think so. "dmsetup deps" indicates the devices that your mapped
> device depends on.

dmsetup has no access to the userspace LVM metadata where the information you
appear to be seeking is stored. It is simply a convenient command-line
interface to the libdevmapper library that is a wrapper around the
device-mapper ioctls.

Use a query tool like 'pvs' to find out what PVs belong to the VG containing a
particular LV.

Alasdair
--
<email address hidden>

Thanks Alasdair for the clarifications. Your explanation is compatible with the dmsetup(8) manpage:

       deps [device_name]
              Outputs a list of (major, minor) pairs for devices referenced by the live table for the specified device.

I'm moving this bug now to initramfs-tools, because that's clearly where this can be fixed.

This bug is not the fault of the dmsetup tool. It belongs with initramfs-tools.

This bug is not the fault of the dmsetup tool. It belongs with initramfs-tools, which should find a better way of determining all PV:s required to start the VG where a particular LV resides.

I can confirm this bug in Ubuntu 8.04.2 LTS

This bug is nasty, because you wont find this bug report before you figured out the root of the problem yourself. That should be another reason to fix this bug. Since i'm not able to fix it, i will use the following workaround:
* use pvdisplay to determine the number of free logical extents in the first physical volume
* create a logical volume with this size (lvcreate ... -l num_of_extents)
Now the first physical volume should be full, the second one still empty.
* extend the root LV by one extent
Now the root LV uses one extent on the second partition and dmsetup deps returns both major/minor-pairs.
* delete the logical volume created in step 2.

That works but it's awkward.

I hope someone competent will soon recognize how significant this bug is. And it's just 10 lines of code...

Christian, an alternative to your workaround is to use pvmove to move one or more extents onto the new LV.

Tony, i tried that, but it is not possible to specify how many extents to move. I tried pvmove, Ctrl+C, pvmove --abort but this reverts the move unless there was already a lot of data moved.

Fixed here: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/490917