[Bug 1767527] Re: [18.04] Installation boot failure. WARNING: invalid line in /etc/crypttab
Mathieu Trudel-Lapierre
mathieu.tl at gmail.com
Mon Nov 19 15:53:15 UTC 2018
How was the system installed? Did this use d-i (the alternate installer
image), or ubiquity?
--
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/1767527
Title:
[18.04] Installation boot failure. WARNING: invalid line in
/etc/crypttab
Status in cryptsetup:
In Progress
Status in cryptsetup package in Ubuntu:
In Progress
Bug description:
I worked with "TJ-" on Ubuntu IRC (#ubuntu) on April 27th in order to
debug this. On a new Ubuntu 18.04 installation, it is not possible to
decrypt the volume when it's installed on an NVMe device with the
encryption selected. Changing the device-mapper name to the luks-$UUID
format apparently did something to correct it, but there's still
something else going on.
--- update from Tj ---
Dylan repeatedly installed 18.04 Desktop setting up F.D.E. with
(originally) a complex passphrase but later also a simple (all ASCII)
phrase.
At boot-time the installed system fails to unlock the device during
initial ramdisk processing, getting stuck in a loop and seemingly
never dropping to the shell for user diagnosis and correction.
Original messages (copied from the attached photo):
Please unlock disk nvme0n1p3_crypt: <--- types passphrase
Volume group "ubuntu-vg" not found
Cannot process volume group ubuntu-vg
device-mapper: reload ioctl on failed: invalid argument <--- note multiple space gap
Failed to setup dm-crypt key mapping for device /dev/disk/by-uuid/4bdade98-fdbe-4a9e-b287-283b4c52c1a0.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
The volume is accessible from the Try Ubuntu session (unlocks
correctly).
My [Tj] suspicion was a keyboard mapping issue or initrd.img missing
required kernel modules for cryptographic functions.
We used a chroot environment to investigate and added "set -x" to the
start of /usr/share/initamfs-tools/hooks/cryptroot to capture the
initrd.img build using
update-initramfs -uv |& tee /tmp/uir.log
The resulting log (see attached 'broken' log) shows the warning in the
title of this bug twice and the root device ignored as far as
configuring the initrd.img goes:
WARNING: invalid line in /etc/crypttab
Analysing the log of the shell commands shows an awk command failing
to recognise the sole crypttab entry because it is expecting the
device-mapper name format to be "luks-${UUID}" not "nvme0n1p3_crypt".
Dylan made a back-up then changed the entry to use the seemingly
correct name format and rebuilt the initrfd.img (see attached
'working' log). There is no warning now and the cryptroot hook goes
ahead and adds kernel modules and tooling to the initrd.img.
The system still fails to boot but with different messages:
Please unlock device luks-98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58 <--- types passphrase
[ timestamp ] device-mapper: table: 253:0: crypt: unknown target type
device-mapper: reload ioctol on failed: Invalid argument
Failed to setup dm-crypt key mapping for device /dev/disk/by-uuid/98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
cryptsetup (luks-98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58): cryptsetup failed, bad password or options?
To manage notifications about this bug go to:
https://bugs.launchpad.net/cryptsetup/+bug/1767527/+subscriptions
More information about the foundations-bugs
mailing list