Today I rebooted an Ubuntu 14.10 that was set up with LVM and encryption.

It was unable to use the encrypted swapspace cryptswap1, which ultimately halted the boot procedure with a prompt (S for skip and M for manual resolution, i.e. single-user-mode prompt).

The problem appears to be that the UUID (blkid) of the designated swap device is lost (destroyed by overwriting). This may not become apparent after the first reboot, because data actually has to be written to the device in order for the problem to appear. At last that is my working hypothesis on why this did not bite me earlier.

When manually skipping swap setup (i.e. choosing „S“ at the boot prompt) and later, when logged on trying to activate the swap using swapon -a or similar, this error will be the result:

/dev/mapper/cryptswap1: stat failed: No such file or directory

What happens is that cryptdisks_start cryptswap1 fails because it does not find the UUID that was given for the filesystem target cryptswap1 in /etc/crypttab.

What I did to resolve the problem: Use the logical volume path instead of the UUID for cryptswap1 in /etc/crypttab. The exact path for the logical volume was found using the command lvdisplay.

The entry cryptswap1 in /etc/crypttab now looks like this (the change is emphasized):

cryptswap1 /dev/mycomputer-vg/swap_1 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

I was then able to reactivate swap with the following two commands:

 ~# cryptdisks_start cryptswap1
 ~# swapon -a

Observe how the swap device’s UUID changes every time cryptdisks_start activates this device:

 ~# blkid /dev/mapper/cryptswap1
... shows a UUID ...
 ~# swapoff -a
 ~# cryptdisks_stop cryptswap1
 ~# cryptdisks_start cryptswap1
 ~# swapon -a
 ~# blkid /dev/mapper/cryptswap1
... shows a different UUID ...

Well … it’s assuring to know that Ubuntu swapspace encryption is so secure that even the UUID is a one-time-token. 😀