On 12/16/2012 10:24 AM, Javier Juan Martínez Cabezón wrote: > > I think I answer too fast before, sorry. > > Did strings answer something known in the device? > > Are you sure that this is true? aes-xts-essiv:sha256 > Which cipher did you use with cryptsetup 1.1? Please do not confuse it even more, this is LUKS, not plain device where default cipher changed. So it is LUKS and if there was no header rewrite, parameters are correct, (there was no reformat and cipher parameter is in LUKS header). If it is properly unlocked, master key is correct as well. So I guess there were no LUKS format and dmcrypt had no obvious problems in this kernel, I would say, the problem is not in this layer. cryptsetup userspace should not be problem, to verify it run dmsetup table --showkeys and compare output with old/new version - if it is same there is definitely no problem in userspace / LUKS So IMHO the problem is in MD layer, ext4, or in some unexpected device rewrite during update or so. - check syslog, mainly time before/after upgrade. Maybe it was broken already there. - check blkid -p on the device - does it detect some known signature? - boot to old kernel, does it work? Or it is broken? (And read the FAQ, there is a lot of other hints.) >>> md126 : active raid0 sda5[0] sdb5[1] >>> 5832190976 blocks super 1.2 512k chunks ... >>> cryptsetup luksDump /dev/md126 So this is your device, RAID0. Read first kb and check what's there now with blkid etc. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
