Ubuntu – How to setup an encrypted swap file

Known Bug

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.

Easy Fix

The easy fix is to reference the swap partition by device in your /etc/crypttab, e.g.:

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.

Proper Fix

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

Note the offset=36.

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.

Update 2014-10-27

I also stumbled upon this. Not verified by me. It looks like offset trick with more verbosity and comments about rebuilding a broken swap.

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22

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.d/cryptdisks-early and /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 16.

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 /dev/sda6.

Now use 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 /dev/dm-0 where dm indicates that it is indeed using the device mapper layer, which provides the encryption.