Activity log for bug #1767527

Date Who What changed Old value New value Message
2018-04-27 23:33:16 Dylan Taylor bug added bug
2018-04-27 23:34:44 TJ cryptsetup: status New In Progress
2018-04-27 23:34:48 TJ cryptsetup: assignee TJ (tj)
2018-04-27 23:36:07 TJ attachment added screenshot of the boot-time failure https://bugs.launchpad.net/cryptsetup/+bug/1767527/+attachment/5128951/+files/nRFgDZn.jpg
2018-04-27 23:45:02 TJ attachment added broken update-initramfs -uv with hooks/cryptroot set -x https://bugs.launchpad.net/cryptsetup/+bug/1767527/+attachment/5128952/+files/uir-broken.log
2018-04-27 23:45:36 TJ attachment added working update-initramfs -uv with hooks/cryptroot set -x https://bugs.launchpad.net/cryptsetup/+bug/1767527/+attachment/5128953/+files/uir-working.log
2018-04-28 08:27:55 TJ bug task added cryptsetup (Ubuntu)
2018-04-28 08:28:04 TJ cryptsetup (Ubuntu): status New In Progress
2018-04-28 08:28:08 TJ cryptsetup (Ubuntu): assignee TJ (tj)
2018-04-28 08:28:14 TJ cryptsetup (Ubuntu): importance Undecided Critical
2018-04-28 08:28:50 TJ summary WARNING: invalid line in /etc/crypttab [18.04] Installation boot failure. WARNING: invalid line in /etc/crypttab
2018-04-28 08:53:34 TJ 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. 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?
2018-04-28 08:54:43 TJ 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? 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?
2018-04-28 09:49:47 TJ attachment added blkid and lsblk https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1767527/+attachment/5129208/+files/blkid_lsblk.log
2018-04-28 09:52:33 TJ attachment added fstab https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1767527/+attachment/5129209/+files/fstab
2018-10-02 12:21:41 Francis Ginther tags id-5bb295aa6470a80a24501f0f