boot hangs with more than 1 luks device in crypttab

Bug #1525724 reported by Lukas Tribus
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

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"

Revision history for this message
Lukas Tribus (luky-37) wrote :
Revision history for this message
Lukas Tribus (luky-37) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Revision history for this message
James Johnston (mail-codenest) wrote :

I also ran into this problem. In my case, I created the second encrypted partition after installing Ubuntu: (1) used fdisk to make partition, (2) run cryptsetup to create LUKS header, (3) edit crypttab to map the partition, (4) reboot.

In my particular case, I was able to work around the issue by specifying "initramfs" on all partitions as an option in crypttab. However this is an annoyance for partitions that are not critical for booting.

Revision history for this message
Kevin (kevin-010) wrote :

Are there any other workarounds for this? adding 'initramfs' doesn't work for me as the initramfs detects it can proceed with a partially-assembled lvm volume group, only starts encryption for one pv, never asks for the other password, and the system scripts later hang the system because they cannot ask for a password

Revision history for this message
James Johnston (mail-codenest) wrote :

Hi Kevin,

I was doing some more reading and I think this bug actually duplicates this other bug, and a fix is supposedly in place for Xenial. I haven't tried it yet. https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1432265/comments/11

Revision history for this message
Lukas Tribus (luky-37) wrote :

I tried Xenial. Yes it does fix the simplified test case in this bug (when booting doesn't require the second encrypted volume to be open), but it doesn't fix my real issue, which is encrypting multiple devices and putting btrfs on top of it. Adding initramfs doesn't help.

So whenever you try booting from multiple encrypted devices it will fail.

Revision history for this message
Karl Kastner (kastner-karl) wrote :

I've only one encrypted device, but since upgrade to Ubuntu 16.04 Xenial my machine fails to mount it and stops booting. After entering the password for the device, the system just displays: "After login in, type "journalctl -xb" to view system logs". Booting can be resumed by hitting enter and then manually mounting the encrypted device. I do not use Luks but a simple combination of /etc/crypttab and /etc/fstab.

Revision history for this message
Karl Kastner (kastner-karl) wrote :

By the way, just did apt-get dist-upgrade and the following warning appeared:

cryptsetup: WARNING: failed to detect canonical device of /dev/sda2
cryptsetup: WARNING: could not determine root device from /etc/fstab

/dev/sda2 is my unencrypted root device.

Revision history for this message
Arbiel Perlacremaz (arbiel-perlacremaz) wrote :

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.

Revision history for this message
Thomas Mayer (thomas303) wrote :

In 18.04.1 Server, I was able to freshly install with two luks encrypted devices which I already added during the partitioning step.

Later on, I changed the generated /dev/mapper/... names in /etc/crypttab and /etc/fstab and continued with a

dmsetup rename OLD_NAME1 NEW_NAME1 #avoids errors in later commands
dmsetup rename OLD_NAME2 NEW_NAME2 #avoids errors in later commands
update-initramfs -c -t -k all
update-grub
reboot

Both update-* commands ran without issues.

The result was that I get asked for one of the two passwords and then it gets into some lvm loop and fails booting.

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.