not sure why you did encryption, perhaps you are designing secret weapons for the military. I am glad you are going to stop that now.
Seriously, not sure why you went with encryption as you can tell it causes more problems than it solves. Just because we can do a thing does not mean we should. In the future perhaps you will heed that advice.
I stole this from some notes...
Removing key-slots is like forgetting a password, it has nothing to do with moving the replacing the LUKS device by the filesytem inside of it.
You CAN non-destructively remove the LUKS encryption from a device, without having to backup, reformat and restore. cryptsetup has supported this since version 1.5.0, released in 2012.
After succesful decryption of a LUKS device, the filesystem inside becomes available to the OS, and you can mount it directly.
Warning: This is dangerous, backup all your data first.
For LUKS1:
- Boot from a USB key
- Usecryptsetup-reencrypt --decrypt <device_path>
For LUKS2:
- Boot from a USB key
- Convert all key-slots to use LUKS1 compatible parameters withcryptsetup luksChangeKey --pbkdf pbkdf2 <device_path>
- Convert the LUKS2 device to a LUKS1 device usingcryptsetup convert --type luks1 <device_path>
- Perform the decryption usingcryptsetup-reencrypt --decrypt <device_path>
I've tested both of these and they work.
Current versions of cryptsetup claim to support direct decryption of LUKS2devices. The command is
cryptsetup --reencrypt --decrypt --header HEADER_FILE <device_path>
The --header argument is required, because the commands assumes your device uses a detached header. If you do, it works, and can even do the decryption online. If you don't use a detached header (quite common), and you try to either provide a dump of the header, or passing the block device itself as the --header value, cryptsetup will quietly proceed and when it finishes, you'll end up with a LUKS2 device which has no key-slots and your data will be gone.
This is as of version 2.3.3 (2020), it may change in future versions.
My recommendation is to use the safer LUKS2->LUKS1->Decrypt path, which I can confirm does the job.