Shoot yourself in the foot: crypttab edition [en]

I’m running Ubuntu on my laptop, using the standard disk-encryption that the Ubuntu installer provides. (Well, the one it provided a couple of years back, when I last installed from scratch.) This setup uses cryptsetup with LUKS on the main partition. This in turn contains an LVM physical volume, which contains a volume group with two logical volumes: one for root, one for swap. So far so good.

Problem

Two days ago, I let my laptop run out of power. But when I restarted it, I wouldn’t get the usual prompt asking me for the disk-encryption passphrase. Instead the Ubuntu startup screen would just show a wait animation for several minutes and then drop me to the initramfs shell (BusyBox). One of the error messages complained that it couldn’t find the expected logical volume with the root filesystem. I had no idea why, so I suspected (wrongly) that some recent Ubuntu update broke something.

Workaround

I fired up my phone and my work laptop and started searching for solutions. At first, I couldn’t find any good advice. So I resorted to my work laptop for a couple of days and waited until the weekend would give me more time to deal with this.

And indeed, today I found a great solution to my problem. Unlike other suggestions elsewhere, it didn’t even need to run a live Linux distro. All I had to do was wait until the Ubuntu boot dropped me to the shell and then decrypt my main partition. In my case, this command did the trick:

$ cryptsetup open /dev/nvme0n1p3 crypt-disk

I entered my passphrase when prompted, then ran exit and the boot process continued normally.

Solution

But I still didn’t know what was going on. And I was pretty sure that the same thing would happen on the next boot. Suspecting broken packages, I first ran an apt upgrade, but I didn’t see anything suspicious. Then I went back to this other proposed solution, which recommended running update-initramfs. When I did, I got this:

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.15.0-78-generic
cryptsetup: WARNING: target 'crypt-disk' not found in /etc/crypttab

And indeed, the respective entry (which had always been there) was missing from my crypttab file. So I added the following:

# <target name>	<source device>		<key file>	<options>
crypt-disk UUID=e6d0b181-b36f-4833-b87d-c5c4946f88e7 none luks

When I ran update-initramfs again, I got no more warnings. So I took my chances an re-booted, and … it worked!

Root Cause

But how did the crypt-disk entry disappear from my crypttab in the first place? It dawned on me immediately:

I’m using Ansible to manage my boxes, including my laptop. I also use it to manage crypttab entries for some encrypted external USB disks. But I do not manage the crypt-disk entry in the crypttab file with Ansible — I just stick with whatever the Ubuntu installer has given me.

This isn’t a problem per-se. The Ansible crypttab module only manages individual entries, not the whole crypttab file. It leaves manual entries in peace. But a couple of weeks ago, I did some manual testing and deleted the crypttab file. Just wanted to verify that the next ansible-playbook run would fix everything. And yupp, it worked.

But I totally forgot that I had manual entries in the crypttab file. When checking the results of the playbook run, I didn’t realize that something important was missing. And the problem only manifested weeks later, when I booted my laptop.

So in the end it was all my fault. Nothing to blame on Ubuntu, as was my first instinct. Also: I should reboot more often.