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.
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.
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.
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!
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.