On Sun, Dec 16, 2012 at 07:11:22PM +0100, Philipp Durrer wrote: > dmsetup table --showkeys > truecrypt1_1: 0 204288 crypt serpent-xts-plain64 > 6194df1a929675daf3792880da3f36f79b819e7f4e42267e6f25deedd172a231a7bcfc84c0853c5413666fbadf93ea096f98cdf1944080859d3a88b6cd99c209 > 256 7:0 256 > truecrypt2: 0 10485248 crypt twofish-xts-plain64 > 36fee68d56029b9dfbe969a76f10c7f9db17ab4305e974e6affd128f1a57b58ccaa0e12bf13ee5e27f67e991222dd0c6ad8bfea9ab9b3ea053d90f8d50d81879 > 256 253:3 0 > truecrypt1_0: 0 204288 crypt twofish-xts-plain64 > e3200b4f4e95e99222cdcbcd70c75bf8ed14ae7993c4f00446437ba96939feb8ea9fa9d2724fb865bc05740253604e9024e82e8a392e2274150488f69cff23d6 > 256 253:0 0 > truecrypt1: 0 204288 crypt aes-xts-plain64 > db606af9d8f18fa7d78750765272d79c86eb1958aef7c835c6b6927aaef8f2bf1d5e964c6b0d6e0e32d812fac0d952245be1630b108a7d90310190509d78660b > 256 253:1 0 > truecrypt2_0: 0 10485248 crypt aes-xts-plain64 > e574ef4dc7c75fbf56bb2f3520414c371fda1f4df8b54ceab2adf0409518df81537b6e7d7edbd46db493f00bd5cd2657d42f12e7f36f4addf9e83de0a9bd7f72 > 256 7:1 256 > stuff: 0 11664377856 crypt aes-xts-essiv:sha256 > 4c8bab80fd627b8f5bbff24d3f458d5555b19c340352c5f14f980227b157089b8d466ba555873ce8edb8dc101c96c8c0f96a1f79c2124076589c11a4f7453a7b > 0 9:126 4096 Woah, stop! Or rather too late. Everybody in the internet now has your master keys and can decrypt your devices! > > So IMHO the problem is in MD layer, ext4, or in some unexpected device > > rewrite during update or so. > > > > that's what I think aswell It has to be. LUKS does nto decrypt is anything at all with it is broken. Unlike plain dm-crypt that will happily decrypt with everything wrong and produce just random-looking stuff. Now, if you look into the FAQ, item 6.12, you will see that the satart of the md device has to be intact for decyption to happen. Also, what superblock format did you use? "mdadm --examine <some raid component>" should tell you. The idea is that if it is 1.1 or 1.2 then the md superblock are also at the beginning. Overwrites typicallyt happen at the beginning, not somewhere in there, Just to be sure: Does maybe the new kernel not support the filesystem you are using? Maybe this is a module-loading problem? What you also can try is to specify an alternate superblock for mount. The option for that is e.g. "sb=131072" (from the man-page) [...] > > I did check the keyslot with the keyslot_checker in misc, did report that > everything looks fine. > Did aswell check the disk with hd tool and looks fine aswell all random > data up to 0x20000 where data begins. > > If no other ideas come to mind until tomorrow I will reformat the disks I > think. Well, it would be nice to find out what caused this, but I can understand that you do not want to invest too much more time. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
