Comment 7 for bug 1767527

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