Comment 3 for bug 474258

As a reminder - your bug report does NOT relate to the "cryptmount" package given details in your original post.

The problem with running "swapon" with an encrypted partition is simply that both the /etc/crypttab mechanisms, and those of other encryption tools, perfectly reasonably regenerate the swap partition every time the system is rebooted. This is because one usually doesn't need to preserve the contents of an encrypted swap partition, and usually doesn't want to have to enter a password before being able to use the swap partition. So it is quite appropriate for encrypted swap partitions to use a new encryption key every time the system is rebooted, and to run "mkswap" on each reboot. The changing of the encryption key means that it wouldn't be feasible to "swapon" the pre-reboot state of the partition. Furthermore, the post-reboot state of the partition will actually only be accessed indirectly by either a loopback device or a device-mapper target. Neither of those indirect devices is likely to have a well-defined partition type analogous to a real disk partition.

As before, I agree that it is frustrating that there wasn't a safety net in the encryption tool you chose to use, but I don't think that's any different from "mkswap" or many other system-administration tools which can easily cause catastrophic damage with a single unlucky keystroke.

I'd recommend that this if this issue is treated as a bug, it is re-parented to a more appropriate package.