[Bug 1525724] Re: boot hangs with more than 1 luks device in crypttab

[Arbiel Perlacremaz]

I am using 14.04 with / and /home (both logical volumes) crypted and USB sticks holding my key files. In this configuration, the system boots.
I intend to move to Xenial and installed it on other lv's with the same type of configuration. Boot hangs, and gets to the situation Karl Kastner wrote about. It turns out that the journal lists timeout for both lv's
root :
Timed out waiting for device dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-lkf-victor-odos:1.device.
and home :
Timed out waiting for device dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-lkf-victor-oikia:1.device.
The listed device is my usb stick.

No way moving to Xenial if no solution to this problem.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/1525724

Title:
  boot hangs with more than 1 luks device in crypttab

Status in cryptsetup package in Ubuntu:
  Confirmed

Bug description:
  When /etc/crypttab has more than one luks device, the boot process
  locks up (hangs) after the decryption of the first luks device. A
  password prompt for the second luks device never appears.

  Affected:
  Ubuntu 15.04 (vivid)
  Ubuntu 15.10 (wily)

  Works fine in:
  Ubuntu 14.10 (utopic)

  When upgrading utopic to vivid in the affected configuration, the bug
  is triggered as well (first boot into vivid).

  
  Testcase:
  - install (text mode) from ubuntu-15.10-server-amd64.iso
  - manually partition the disk (see attached installer-partitions.png):
    -> sda1: 512mb ext2 for /boot/ (unencrypted)
    -> sda2: 4GB encrypted (luks) -> sda2_crypt
    -> sda3: 2GB encrypted (luks) -> sda3_crypt
    -> sda2_crypt: ext4 for /
    -> sda3_crypt: ext4 for /tmp

  boot will hang (boot-hang.png) after decrypting sda2.

  My real use-case is to encrypt multiple physical hard drivers, which
  fails exactly the same way (the test config doesn't make much sense,
  but its simple to reproduce).

  
  Commenting sda3_crypt in /etc/fstab and adding a the option nofail to sda3_crypt in /etc/crypttab makes the OS boot.

  
  # cat /etc/crypttab
  sda2_crypt UUID=b41558ee-eb5b-463a-a1a5-34e1cc6b05e9 none luks,discard
  sda3_crypt UUID=c1c660d3-2e70-4761-85a2-6f635719f8cd none luks,discard

  # cat /etc/fstab
  # <file system> <mount point>   <type>  <options>       <dump>  <pass>
  /dev/mapper/sda2_crypt /               ext4    errors=remount-ro 0       1
  # /boot was on /dev/sda1 during installation
  UUID=56e38284-0cef-4e8a-b933-c82f70ef4588 /boot           ext2    defaults        0       2
  #/dev/mapper/sda3_crypt /tmp            ext4    defaults        0       2

  # blkid
  /dev/mapper/sda2_crypt: UUID="8413bc48-13e7-4b19-aabc-42b6b19101a5" TYPE="ext4"
  /dev/sda1: UUID="56e38284-0cef-4e8a-b933-c82f70ef4588" TYPE="ext2" PARTUUID="ec85536d-0bb5-44c8-a3ba-93ae539e4ef1"
  /dev/sda2: UUID="b41558ee-eb5b-463a-a1a5-34e1cc6b05e9" TYPE="crypto_LUKS" PARTUUID="4f76f8cb-b170-4a07-a412-832ba2964377"
  /dev/sda3: UUID="c1c660d3-2e70-4761-85a2-6f635719f8cd" TYPE="crypto_LUKS" PARTUUID="ef6c816c-71d3-4d36-88e7-eb2ddae2a06a"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1525724/+subscriptions