On 12/29/2012 11:03 PM, wpc95 wrote: > i am running LUKS for the last years without any problems, but now have > encountered a strange behaviour of cryptsetup. A workstation has 4 > SATA-drives, 3 of them encrypted with LUKS. Running Ubuntu 10.04 (cryptsetup > 1.1.0-rc) all encrypted drives can be opened and accessed without any > hassle. Running Ubuntu 12.04 (cryptsetup 1.4.0) LUKS claims for 2 of the > encrypted drives, that 'LUKS keyslot 4 is invalid'. Due to the fact that the > option 'repair' was launched with cryptsetup 1.4.1, i have started the > computer with an actual live-linux. But the result with cryptsetup 1.5.0 is > the same as with 1.4.0: it claims, that 'LUKS keyslot 4 is invalid. Invalid > offset 1576471435 [first drive] 3746914134 [second drive] in keyslot 4.' The > repair option says that repair failed with code 22 and a manual repair is > required. How is a 'manual repair' done and why does the error does not > appear with cryptsetup 1.1.0-rc? I have - of course - backups of the > 4K-headers and the complete data of all drives. :-) Previous versions silently ignored error (so once you use that invalid keyslot, you risk something is overwritten). (But workaround is downgrade cryptsetup :) But it is strange that repair cannot fix this... If you send me (privately) header backup I can fix the header (and add check to code so repair can do that automatically). I do not need password, perhaps not even the keyslot data (so first 4kB should be enough) Please note that backup of 4kB is only visible header, the real keyslot data are located next to this area. If you do not want to send this, please post luksDump and log from repair command with added --debug (it should print more info). You can also try keyslot checker in source code (written by Arno). But I think here we need repair the header first. Thanks, Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
