I encrypted a bunch of hard drives with cryptsetup luks encryption on CentOS 5. Everything was fine, until I upgraded my system to CentOS 6. Now I cannot mount the disks anymore.
To mount with my keyphrase:
sudo cryptsetup luksOpen /dev/sdc1 d2
I get this error:
device-mapper: reload ioctl on failed: Invalid argument
Failed to setup dm-crypt key mapping for device /dev/sdc1.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
Failed to read from key storage.
In /var/log/messages:
Feb 3 23:43:23 data kernel: device-mapper: table: 253:0: crypt: Device lookup failed
Feb 3 23:43:23 data kernel: device-mapper: ioctl: error adding target to table
Any thoughts on how I can mount??
Solution found.
The problem was the drives were encrypted with an interactive keyphrase of about 512 characters long (copy/paste from a key file). For some reason, the new kernel module in CentOS 6 would not properly read encrypted keys of 512-characters when created by an older version. Only seems to affect differing versions of the kernel or cryptsetup, since a 512-character key will work when created and opened on the same system.
In summary...
kernel -> create luks key of 512 characters -> can open in same kernel
old kernel -> create luks key of 512 characters -> cannot open in new kernel
512-characters is just too long. Not sure what the threshold is, but I decided to change my keys to 50-characters, and it worked.
To resolve, I re-installed the old CentOS 5 operating system I was previously using, used cryptsetup luksAddKey, entered the original (long) 512-character key, and created a new key of 50 characters long.
Then I re-installed CentOS 6, and successfully mounted each disk with cryptsetup luksOpen using the 50-character key (not the original key).
So a note to someone who gets a similar error. If you encrypted your drives with a super-long key, change to a new kernel or cryptsetup, and you get a kernel module error when trying to luksOpen your encrypted volume, you may have to go back to the old kernel version to use luksAddKey and add shorter keys before using in the new kernel. This could be a bug, or some mismatch in the maximum allowed interactive keys in the kernel models used by LUKS.