cryptswap overwrites existing LUKS partition
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| cryptsetup (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
This bug is related to: https:/
In spite of the implementation of cryptswap checking for existing filesystems, I think I have encountered a bug. cryptswap still creates the swap partition if the target partition does not contain a filesystem, but a LUKS partition.
I have been able to reproduce this issue without meaning to. After adding a drive my /dev/sdX assignments shifted, and I lost a partition full of data. However, in spite of attempts to recreate the data partition, the LUKS header kept being overwritten by random data.
That's when I saw this: https:/
cryptswap has been overwriting the partitions. The partitions contained LUKS Encrypted ext4 filesystems created using gnome-disks.
I have a specific hardware device that I use for SWAP, so in a way it was my own mistake for not updating /etc/crypttab when connecting the new drive, but in my opinion cryptswap should not destroy a LUKS partition to a point where even with header it is difficult to recover any data simply because a drive has been changed. As far as I have been able to find, cryptswap with UUID is still not possible after all.
