[Bug 1767527] Re: [18.04] Installation boot failure. WARNING: invalid line in /etc/crypttab

[TJ]

Dylan: I've updated the bug description to describe the situation as we
left it.

There is a test I'd like you to do which involves forcing a break in
initrd processing and dropping to the shell before the cryptsetup
prompt.

Once there I'd like you to verify the NVME device is visible along with
the UUIDs. I'm wondering if the scripts are so dumb that they don't
check for the presence of the underlying block device (with UUID
98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58 a.k.a. partition #3) before
prompting you for the passphrase.

At boot-time interrupt GRUB by tapping the Esc key to get the GRUB boot
menu. There, highlight the default (top) entry and press 'e' to edit it.
Navigate down to the line beginning "linux ..." (the kernel command-
line) and add to it "break=premount" then press Ctrl+X (or F10) to boot
with that change.

That should lead to an initramfs busybox shell command-line.

Note: other possible break=XXX values are:

$ grep maybe_break /usr/share/initramfs-tools/init 
maybe_break top
maybe_break modules
maybe_break premount
maybe_break mount
maybe_break mountroot
maybe_break bottom
maybe_break init

Once in the shell check the device is known with some or all of these
commands and any others you can think of (busybox is limited and
additional tools you'd expect in the full install won't be available):

blkid
ls -l /dev/disk/by-*/
ls -l /dev/mapper/

You can also attempt to manually unlock using:

cryptsetup open --type=luks /dev/nvme0n1p3 luks-
98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58

(set the /dev/nvme0n1p3 underlying device path to whatever your
exploration has found, including possibly "/dev/disk/by-
uuid/98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58" )

If that works (or fails) the resulting messages might be important so be
prepared to photograph them.

If it works, then you will see the new node ("luks-
98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58") with

ls -l /dev/mapper/

And now, if this hasn't already happened automatically via udev, you
should be able to force LVM discovery of ubuntu-vg with

vgchange -ay

At this point if "ls -l /dev/mapper/" now does show a luks-
98c2ce02-6cb1-4a2d-a086-1e8cf78a3c58 node you can try to continue the
boot by pressing Ctrl+D or typing "exit". If those don't help then re-
running the entire script might be possible instead using

exec /init

-- 
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