Comment 5 for bug 1066342

This is not fixed in Ubuntu-Gnome 14.04.2 LTS.

I recently installed Ubuntu-Gnome 14.04.2 LTS on a few machines and invented a workaround. The script that sets up encrypted swap (/usr/bin/ecryptfs-setup-swap) should first do a mkswap on the partition (if it isn't already set up), then use the "offset=" parameter in crypttab to avoid clobbering the first bytes of the swap partition. I set it to 2048 (512-byte blocks, totaling 1MB) because megabyte alignment of partitions is now the default for avoiding performance issues in disk drives with various physical block sizes, yet losing only 1 megabyte from a swap partition is a tiny fraction of a modern swap partition, and thus easily tolerable.

My crypttab currently reads:
cryptswap1 UUID=b742ddee-4f75-4826-9c43-2a08778560d4 /dev/urandom swap,cipher=aes-xts-plain64:sha256,size=512,offset=2048

The relevant change is "offset=2048" on the end.

This does not allow the installer to automatically detect swap from a PREVIOUSLY encrypted swap partition that starts at offset=0. But if the installer starts doing this now, FUTURE installers will be able to see the swap partition as a swap partition,
and can use it either encrypted or not.

Also, this allows the swap partition to be detected via its UUID. When encrypted with the offset defaulting to zero, it encrypts
the UUID, puts the UUID into crypttab, and then subsequent reboots cannot find the swap partition.

One additional change is in this crypttab for your consideration: I changed from the default cipher to aes-xts-plain64 (and the key size from 256 to 512) because the dm-crypt documentation says it's a better choice than the default.

I also recommend that the installer provide a checkbox to allow users to encrypt their swap partition even if they don't encrypt their file systems or drives. This is because active keys and other valuable data needing protection often exist in process address spaces that get written to the swap partition.