* 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.
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 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
* During boot, systemd-
* The "real" encrypted swap partition (cryptswap1) gets enabled later, and that fails with "busy" as the unencrypted partition is already active.