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.

2 Answers 2

8

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 EOF at the end!

Whoah! How can this be? This is the first time in the last 25 years that some linux needs ecpects an EOF in a text file. Gosh!

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

3
  • What do you mean by an EOF? That's not a character. A newline? A null byte? Jul 15, 2023 at 21:55
  • 1
    Assuming that you mean a newline character (\n), then yes, some things in linux are weird when you don't have a trailing "\n", specially lower level stuff. That's why most modern text editors will automatically add one for you even if you don't add it manually.
    – Doodad
    Jul 26, 2023 at 21:35
  • crontab needs newline to work as well, so… You just did not happen to stumble about it for the last 25y;)
    – karlsebal
    Oct 28, 2023 at 5:32
7

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.

1
  • 4
    I encountered this same problem after trying to repair a kernel install from a chroot using a recovery disk. To mount the root volume, I first ran cryptsetup open /dev/sda5 sda5_crypt. As you mentioned, the name you choose here is important. To match the Ubuntu default, you have to add _crypt to the device name in this way. If you name it incorrectly, update-initramfs from a recovery disk chroot will create a boot image that doesn't correctly decrypt and mount root at boot.
    – Brandon
    May 16, 2022 at 20:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .