lvm on cryptsetup with initramfs infinite loop

[John Lenz]

Binary package hint: lvm-common

Hey, I updated to edgy recently and there is a minor problem with the initramfs cryptroot and lvm scripts. First my setup... I have a luks encrypted partition on sda4, and inside that partition I have lvm, with lvm partitions for dapper root, edgy root, home, and some others.

/dev/sda4 ->
[cryptsetup luksOpen] /dev/mapper/cryptroot ->
[vgchange -ay] /dev/mapper/zeus-edgyroot

The problem is with both lvm and cryptsetup installed, the local-top/lvm script goes into an infinite loop. In my setup, the local-top/lvm script can be completly skipped, since the required lvm vgchange commands are carried out in local-top/cryptroot.

So what I did is add the following code into local-top/lvm directly before the loop.

# check that the device is actually a lvm device
if ! pvscan | grep 'VG ${vg}' > /dev/null 2>&1; then
  exit 0
fi

slumber=360
while [ ${slumber} -gt 0 -a ! -d "/dev/${vg}" ]; do
  pvscan > /dev/null 2>&1
  vgchange -ay ${vg} > /dev/null 2>&1
  /bin/sleep 0.5
  slumber=$(( ${slumber} - 1 ))
done
vgchange -ay ${vg}

This works prefectly for me, since it just exits out there and continues to the cryptroot script.

[Phillip Susi (psusi)]

I believe that this breaks the intended functionality of the loop. The purpose of the loop is to keep scanning devices until the ones containing the volume group appear, then enable the volume group. The line you added performs essentially the same scan only once, and if it is not found the first time, carries on.

In other words, you would accomplish the same thing by simply removing the while loop and letting the body execute only one time, which is how this script looked in edgy. It was changed in dapper because sometimes it takes some time for the disks to be detected and we don't want the script to decide it can't find the vg when it just needs to wait a while.

[John Lenz (lenz)]

Well ok. At the very least, you need to provide some option of disabling the lvm script... assuming a device is in /dev/mapper is not really all that good to go into an infinite loop!

So I see a few options:

1) At the very least, check /proc/cmdline for something like "norootlvm", to allow to disable the lvm script manually.

2) Provide a hook script that gets run when the initramfs is created, that detects if root is on a lvm or not, and then stores the detection. This is the way cryptsetup does it, the results are stored in /conf/conf.d/cryptroot, and then the cryptroot script that runs during boot loads that file.

3) Combination of 1 and 2... this is actually what cryptsetup does. If there is no command line option, then the stuff from the file is used.

I can try coding this up (mainly by copying stuff from the cryptroot script), except I don't have a root lvm to test it on.

[George Klein (gk-t-t-l-deactivatedaccount)]

I have also hit this bug (see also bug #21878).

I have /dev/hda3 as a LUKS partition which gets mounted on /dev/mapper/cdisk. This then uses lvm to give me /dev/mapper/ubuntu-root and /dev/mapper/ubuntu-home which are mounted at the obvious points.

As my root volume can't appear until cryptroot is run, my boot is stalled until slumber has counted down which takes a LONG time.

[Yves-Eric Martin (yem-launchpad-net)]

This long delay at every boot is most annoying on a laptop, where battery time is precious. Ironically, laptops are also where having an encrypted filesystem makes a lot of sense...

More than 3 months after this bug has been submitted, the status is still "Unconfirmed", with an importance "Undecided". How can we get this bumped up?

[Yves-Eric Martin (yem-launchpad-net)]

FWIW, it may not be the right thing to do, but John Lenz's modification works for me (^_^)

[Scott James Remnant (Canonical) (canonical-scott)]

This script has gone and it is now done from udev which should not loop