initrd on Karmic does not support multiple encrypted LVM physical volumes.

[Andreas Kostyrka]

Ubuntu offers to install the rootfs into an encrypted LVM physical volume (PV).

Adding a second encrypted PV to the volume group that contains the root filesystem makes the initrd drop into the busybox shell.

doing the cryptsetup, lvm pvscan and lvm vgchange -ay manually allows the system to continue to boot.

(Ideally the initrd should try to use the entered passphrase on all candidates, that would allow to extend the VG without having to enter multiple passphrases on each boot, but even entering the passphrases manually for each device is better then dropping into the sh and entering the commands manually.)

[Andreas Kostyrka (andreas-kostyrka)]

Btw, being able to extend the storage space easily is one of the purposes of LVM.

And having a volume group that is only partly encrypted would make the LUKS setup pointless.

[Andreas Kostyrka (andreas-kostyrka)]

Ok it seems like the runtime phase can handle it, but the creation phase of the init ramdisk does not detect all crypted PVs.

unpacking an initrd, editing conf/conf.d/cryptroot adding another line for your second PV, repacking the initrd and it works perfectly.

[Andreas Kostyrka (andreas-kostyrka)]

Ok, figured out the problem, and it should be fixed, as this can result in an unbootable system:

-) the cryptroot hook get_lvm_deps does use dmsetup deps to figure out which volumes are involved in your root fs.

-) the correct way would be something like pvdisplay and grepping for the volume group that contains the root fs.

Failure scenario:

-) add a new encrypted PV to the VG that contains your root fs. Do not extend your rootfs into that new PV.

-) now get_lvm_deps only sees PV1 as a dependency, but in truth the VG will not activate without all PVs of the VG being active.

One theoretical solution would be to use vgchange -ay -P $(VG) to activate the VG only partially, and rely on the cryptab processing after root is mounted.

Andreas

[Reinhard Tartler (siretart)]

nothing to fix upstream, this issue is about integration with the ubuntu initramfs generator.

[Andreas Kostyrka (andreas-kostyrka)]

vgchange -P is not the solution for this problem, because that causes a read-only volume group, which is really unhelpful. Personally I've found it easier to sort out the LVM situation in the initramfs busybox when needed when having this really readonly root filesystem.

[Jon Severinsson (jon-severinsson)]

Andreas> the correct way would be something like pvdisplay and grepping for the volume group that contains the root fs.

After being hit by this and finding this bugreport I decided to do something about it. Attached is a patch that uses lvdisplay, pvs and sed instead of dmsetup and sed to find lvm dependencies.

Only tested for lvm on luks. Will definitely not work for dm subsystems other than lvm (but as the function name is get_lvm_deps I don't think that was supposed to work anyway.) Also, it will happily ignore any regular devices (/dev/sdx) that lvm depends on, so if your lvm volume group is not encrypted, it will issue a warning, but will probably work anyway.

[Gavin Brown (f-launchpad-greycubes-net)]

I can confirm that the patch works in some/maybe most instances, however my setup requires a slight alteration to the sed line for the PVS part.

Jon's Patch Line:
        if ! pvs=$(pvs | sed -r -e "s| +/dev/mapper/([^ ]+) $vg .*|\1|;tx;d;:x") ; then

My Altered Line:
        if ! pvs=$(pvs | sed -r -e "s| +/dev/mapper/([^ ]+)\s+$vg .*|\1|;tx;d;:x") ; then

The reason being one space character between the PV column and the VG column can't be guaranteed, so the \s+ will match any number of spaces.

Here's the output of my pvs currently, note the 2 spaces on the latter two physical volumes:
  PV VG Fmt Attr PSize PFree
  /dev/mapper/sda5_crypt octopus lvm2 a- 232.64G 0
  /dev/mapper/sdb1_crypt octopus lvm2 a- 698.63G 0
  /dev/mapper/sdd_crypt octopus lvm2 a- 698.64G 0
  /dev/mapper/sde_crypt octopus lvm2 a- 931.51G 33.92G

[Chris Irwin (chrisirwin)]

This bug still exists in Maverick.

I'm curious why there needs to be mappings of what device contains the root volume, etc. Why can't it just use what is in crypttab? Is there a reason that it needs to figure out which mount contains your root filesystem and ignore other configured containers?

[Jean-Louis Dupond (dupondje)]

Thank you for reporting this bug to Ubuntu. Maverick reached EOL.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

I've tried recreating this bug with Maverick and was unable to, given the information you've provided. Please either a) upgrade and test or b) increase the verbosity of the steps to recreate it so we can try again.

Please feel free to report any other bugs you may find.

[Roger Binns (ubuntu-rogerbinns)]

This bug is still present and another scenario is btrfs. cryptroot is written under the assumption there is exactly one device that needs to be decrypted for root to be mounted, which can be very wrong for btrfs.