Comment 12 for bug 1447282

So it is as I suspected:

 * ecryptfs-setup-swap creates cryptswap1 at 512KiB offset of the former real swap partition (vda3), and adds that to /etc/crypttab; as we need/want the UUID, we keep the original swap header
 * During boot, systemd-gpt-generator sees the apparent unencrypted swap partition on vda3 and creates a .swap unit for this. This doesn't happen on classic MBR partitions, as there are no partition type UUIDs and no auto-discovery
 * The "real" encrypted swap partition (cryptswap1) gets enabled later, and that fails with "busy" as the unencrypted partition is already active.