I've seen the same error today on a laptop running Ubuntu 15.10 which I always kept up-to-date but had not rebooted for a month until I wanted to test a current kernel (i.e., there might have been a recent change).
Anyways, I found that in my case the underlying cause was actually a "missing" swap partition due to a setup glitch when following the above tutorial. If this is the case and/or you're actually using lvm, you might be able to skip step 2 below.
Of course, you might also see the above error message in case your system (or a secondary data) partition has been damaged or cannot be found (see step 3).
Step 1: Mount your system, boot partitions following the aformentioned tutorial
Let's say your (ext2) boot partition is /dev/sdX1, your (encrypted) swap partition is /dev/sdX2, your (encrypted) data partition is /dev/sdX3 and you've successfully decrypted the latter using cryptsetup luksOpen /dev/sdX3 data, followed by mounting it: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.
Pay attention to the bind mounts in the tutorial and make sure to mount /dev/sdX1 so that you can access it from your system partition's /boot directory (this is crucial as we have to execute update-initramfs).
In the following, we're assuming you've sucessfully executed chroot /tmp/data/@ubuntu1510 (or whatever your mounted system partition is called)
Step 2: Get rid of the above error message
I'm using btrfs (as you might have guessed from the mentioned subvolume name), so lvmetad can easily be disabled as follows without loss of functionality:
- edit /etc/lvm/lvm.conf and change
use_lvmetad=1 to use_lvmetad=0
- execute
update-initramfs -k *KERNEL_VERSION* -u ; sync
Now, you could reboot and the error message should be gone. However, in my case, the next error message[1] pointed me to the underlying problem mentioned above, so while we're at it, ...
Step 3: Make sure that /etc/crypttab points to the correct, undamaged partitions
First, run sfdisk --list /dev/sdX and check that your encrypted swap partition (in my case, /dev/sdX2) actually does not show up as a (normal) swap partition. If it did (as in my case), this meant that booting, e.g., using a rescue disk will likely make use of that available swap partition, thereby overwriting your cryptsetup related metadata (keyphrase and UUID).
Next, have a look at /dev/disk/by-uuid and compare the respective UUIDs of your encrypted partitions with those contained in /etc/crypttab. My guess at this point: In your case, there's a mismatch.
If the dedicated encrypted swap partition is nowhere to be found below /dev/disk/by-uuid, that's because it's currently in use by your rescue system. In that case, do the following:
- make sure to stop using the partition:
swapoff -a
- reformat it:
mkfs.ext2 /dev/sdX2 (this is crucial, especially when using GPT partitions[2], as it undoes the glitch I mentioned earlier. The likely cause of the partition showing up as type "swap" in the sfdisk listing is that you/I mistakenly used mkswap /dev/sdX2 when setting up the partition in the beginning.)
- follow the tutorial to encrypt the partition and set a passphrase; afterwards, open it using cryptsetup and properly reformat the now-decrypted partition (using something like
mkswap /dev/mapper/swap)
- ensure that
sfdisk --list /dev/sdX will not identify the swap partition as such (in that case, repeat the last steps)
Now, recheck that the UUIDs listed in /etc/crypttab are in line which what you see below /dev/disk/by-uuid for your respective encrypted partitions.
Again, to make the changes permanent, you must execute update-initramfs as shown above.
If you're satisfied, make sure everything is written to disk and reboot the system (no need to unmount everything manually). Afterwards, your problem should be gone.
[1] maybe I did not pay attention the first time or the first error message "masked" the second one; i.e., only after rebooting (with use_lvmetad=0), I was presented with "Reading all physical volumes. This may take a while..." (repeated multiple times), followed by "ALERT! /dev/disk/by-uuid/... does not exist.". (It should be noted that update-initramfs also complained about a missing partition.)
[2] because their type is deducted from analysing their contents and not ultimately specified by a flag/byte (that's why there's no easy way to, e.g., change the GPT file system type using [g]parted.)
