6

after upgrading to 20.04, my encrypted disk doesn't get decrypted on boot. I'm not asked for any password, so it obviously can't find any partition and boots into initrd prompt.

What might be the reason: /cryptroot/crypttab in the initrd image is completely empty.

I can open luks manually and chroot into the system. This is the content of my /etc/crypttab in the real root directory:

nvme0n1p3_crypt UUID=<some uuid> none luks

(The UUIDs are all correct, everywhere)

When I run update-initramfs -c -k all, the output is:

cryptsetup: WARNING: target 'nvme0n1p3_crypt' not found in /etc/crypttab

Which is a bit weird, because it's exactly the target name of the only single entry in that file. It's also listed in /dev/mapper as a link to ../dm-0 which also seems to be correct.

I tried renaming the device to crypt only using dmsetup rename ... but that didn't help of course.

I assume that this is the root cause of my problem.

Michael Kuhlmann
  • 151

2 Answers2

9

Fyi, I got it fixed. It was so weird, I would've never find out if someone didn't have told me.

The problem is with the file /etc/crypttab: It needs an extra blank line (i.e., two \ns) at the end!

Whoah! How can this be? This is the first time in the last 25 years that some linux expects an extra blank line in a text file. Gosh!

Anyway, now it's fixed, after more than one week testing.

Paul Fisher
  • 509
Michael Kuhlmann
  • 151
8

Here is the generation routine: https://salsa.debian.org/gpiccoli/cryptsetup/-/blob/master/debian/functions#L526

Another gotcha (others may say it's intended) is that your /etc/crypttab TARGET (= name) must be the one currently used for the root you intend to generate the initramfs for.

Eg: If you:

luks open foo
mount /dev/mapper/foo
chroot
update-initramfs

Then foo's etc/crypttab's TARGET must be foo too otherwise you'd see:

cryptsetup: WARNING: target 'foo' not found in /etc/crypttab

Although it's barely visible with update-initramfs -v.

drzraf
  • 191