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

Bug #282189 reported by Tony Lewis
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
initramfs-tools
Invalid
Undecided
Unassigned
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned
devmapper (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Scenario:

My root fs is on LVM which has some LVs (including root) over a single VG over a single PV which is a physical partition.

I create an encrypted PV, and extend the VG with it. I do not, however, migrate any part of the root fs to the new PV.

"dmsetup deps" shows that the root fs depends only on the physical partition, not on the encrypted partition. However, the VG cannot start without that encrypted PV being available. "dmsetup deps" does not accurately detect that the root fs now depends on the encrypted PV being available.

This has bad consequences for booting. If I run "update-initramfs -u" it uses "dmsetup deps", and fails to note that there is now a "cryptroot" element involved. System will not boot (Recovery is possible using a live CD to then remove the encrypted partition from the VG)

This is probably a bug with dmsetup. Alternately you could consider it a bug with initramfs-tools, which needs a better way to detect this scenario.

....
UPDATE by hugojosefson: This bug has now been moved to project "cryptsetup (Ubuntu)", so that the problem can be solved in the method get_lvm_deps() in /usr/share/initramfs-tools/hooks/cryptroot. That method could use some other way of determining a LV's dependencies, instead of the current "dmsetup deps".

Revision history for this message
Hugo Josefson (hugojosefson) 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.

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

Revision history for this message
Hugo Josefson (hugojosefson) wrote :

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.

Changed in devmapper:
status: New → Confirmed
Revision history for this message
Alasdair G. Kergon (agk2) wrote : Re: [Bug 282189] Re: "dmsetup deps" does not accurately report LVM dependencies, can cause boot failure

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>

Revision history for this message
Tony Lewis (tonylewis) 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. 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

Revision history for this message
Alasdair G. Kergon (agk2) wrote :

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>

Revision history for this message
Hugo Josefson (hugojosefson) wrote :

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.

Revision history for this message
Hugo Josefson (hugojosefson) wrote :

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

Changed in devmapper:
status: Confirmed → Invalid
Revision history for this message
Hugo Josefson (hugojosefson) wrote :

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.

Changed in initramfs-tools:
status: New → Confirmed
description: updated
Revision history for this message
Christian Tschabuschnig (tschaboo) wrote :

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...

Revision history for this message
Tony Lewis (tonylewis) wrote :

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

Revision history for this message
Christian Tschabuschnig (tschaboo) wrote :

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.

Changed in cryptsetup:
status: New → Confirmed
Changed in initramfs-tools:
status: Confirmed → Invalid
description: updated
Revision history for this message
Gavin Brown (f-launchpad-greycubes-net) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.