On 11/26/2011 07:45 PM, Milan Broz wrote: > On 11/26/2011 03:19 PM, Mika Kujanpää wrote: >> I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get >> >> cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3 >> LUKS keyslot 4 is invalid. >> LUKS keyslot 5 is invalid. Perhaps another item to FAQ: In cryptsetup 1.4.x I added check of keyslot data offset. (Keyslot offset is calculated during format for all slots including inactive slots.) If any keyslot offset points to the area outside of LUKS header, header is corrupted (IOW keylot point to the payload data area and in theory can overwrite user data when activated.) And exactly this happened there, inactive slot 4 and 5 had wrong offset. Because there was know signature 0x55 0xAA in last bytes of the first sector I guess some "clever" partition tool wrote few bytes there after LUKS was formatted. if you run luksDump --debug here, you will see better error message, here e.g. # Reading LUKS header of size 1024 from device /dev/sdb # Invalid offset 1760061416 in keyslot 4 (beyond data area offset 4096). LUKS keyslot 4 is invalid. How to fix that depends on situation... If you have old cryptsetup, you can activate device and reformat the header using "How do I recover the master key from a mapped LUKS container?" in FAQ. With exact knowledge of LUKS header you can fix that manually. (I used simple dd from another device in this case but offset depends on situation.) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
