There is a bug (see below) that overwrites the
UUID for the partition as soon as data is written to it. Therefore, you cannot use the
UUID to reference the partition to use for encrypted swap.
These days, swap space is hardly ever used. On my machine, swap is only used when I open my 40th tab. When I have no swap, suddenly my computer starts lagging and the browser closes itself. Or in the case of the
Chromium browser, a lot of tabs will suddenly 'die'.
For this reason, referencing
/dev/disk/by-uuid/ in your
/etc/crypttab might seem to be working for a while, but as soon as your swap space is actually used, it will overwrite the
UUID because the entire partition is used for encrypted data storage.
The easy fix is to reference the swap partition by device in your
cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
Warning: this is probably safe on a laptop (I use it like this), but if you are on a desktop with swappable drives or have other reasons for changing the drive/partition layout, you don't want to do this, as a normal storage partition might suddenly be used for swap.
Note: You need to reboot for this change to take effect, because only when booting will
/dev/mapper/cryptswap1 be created.
The proper way to fix this is to make sure the part of the raw partition that stores the
UUID is not overwritten by encrypted swap data, so it will still be there on reboot. However, I'm not sure where the
UUID is written and how much bytes it takes up. You could, at your own risk, test it like so:
cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,offset=36,cipher=aes-cbc-essiv:sha256
Please if you have an Ubuntu One account log in and go to Bug #1310058 on Launchpad and choose (or click here): "This bug affects me too" so the bug will gain 'popularity' and is more prone to get fixed.
I also stumbled upon this. Not verified by me. It looks like
offset trick with more verbosity and comments about rebuilding a broken swap.
There are two separate problems which must be resolved in order to get
cryptswap1 working correctly in Ubuntu 14.04.
Problem 1: Overwritten swap header
The partition has originally been formatted with an unencrypted swap header, which is used to find the correct partition to use during boot. Because the encryption key changes at each boot, the encrypted swap header will be rewritten at each boot. Due to a bug in generation of
/etc/crypttab, the encrypted swap header overwrites the unencrypted swap header. This will prevent the swap partition from being found at all future boots.
Problem 2: Race condition during boot
There is a race condition during boot between
/etc/init/cryptdisks.conf. Both will simultaneously try to activate all devices listed in
crypttab. In the case of encrypted swap, the outcome of the race condition most of the time will be, that it doesn't work at all. Some sanity check fails causing writing of the encrytped swap header to be skipped in order to prevent potential data loss.
Fixing and working around the problems
The first problem can easily be fixed. The second can be worked around. In
/etc/crypttab identify the swap line. It should look like this (except that the UUID will be different):
cryptswap1 UUID=f9a0f20c-fac4-408c-a8b9-47300216f727 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
In my case this was the only line in
/etc/crypttab. To fix the overwriting of the swap header, an offset must be added. Sources disagree on what exactly the correct value to use is, but using a too large value doesn't hurt. I got it working using an offset of
Additionally I added
noearly which causes
/etc/init.d/cryptdisks-early to ignore this line and that way works around the race condition.
The resulting line looks like:
cryptswap1 UUID=f9a0f20c-fac4-408c-a8b9-47300216f727 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,offset=16,noearly
This will prevent the unencrypted swap header from being overwritten again, but we still need to recreate it on the partition. At this step it is crucial to use the correct partition because using the wrong partition will cause data loss. I used
fdisk -l to find the correct partition, which in my case is
mkswap to rewrite the unencrypted swap header.
mkswap /dev/sda6 -U f9a0f20c-fac4-408c-a8b9-47300216f727
The UUID is the one the swap partition had before it was overwritten (which you can still see in
/etc/crypttab). Once this is done a reboot is needed, and it should all work.
Verifying correct operation
I recommend rebooting three times to verify that it keeps working.
The error message
the disk drive for /dev/mapper/cryptswap1 is not ready yet or not present remains visible briefly during boot. This appears not to be a problem though, as it does become ready before the boot process completes.
Log in and type
cat /proc/swaps to see that swap is active. You should see a swap partition with the name
dm indicates that it is indeed using the device mapper layer, which provides the encryption.
Thanks to this guide I set up an encrypted swap file (can't be used for hibernation). On Debian based distributions, you will need the
cryptsetuppackage for these instructions.
Firstly create an appropriately sized file (here 4 gigabytes) to store the swap data:
Add the following to
Activate the newly created encrypted drive:
Add the following to
Activate the new swap file: