On Fri, Aug 05, 2011 at 05:02:13PM +0200, Paul Menzel wrote: > 2011/8/5 Milan Broz <mbroz@xxxxxxxxxx>: > > On 08/05/2011 02:11 PM, Paul Menzel wrote: > >>> No, as from the output above, I do not see the same problem. What > >>> could be the reason for this difference in behaviour? > >> > >> On #lvm Milan suggested that the problem lies with the new drive > >> having some misalignment > > > > I have checked the dump and there is clear corruption of first keyslot > > (0x1000 - 0x1400 offset). > > Is the key slot corruption the only corruption? So `dd`ing the part > from the old drive to the new (corrupted) drive should have fixed the > LUKS setup and no other metadata (LVM, ext3) should be influenced? > > > I'll try to find the source of problem now. > > Thank you for your help. > > I emphasize again these errors because the RAID1 was still active when > I tried `luksOpen` and the passphrases started to be declined. The RAID superblocks get frequently rewritten. There is an "event-count" in there used to detect when a disk fell out of the RAID (will have an older event counter). This may trash the keyslot if you wrote the header to the underlying device, not the RAID device or there is some device overlap. In fact that explanation now sounds most likely to me. Arno > --- dmesg --- > Aug 4 00:16:01 grml kernel: [ 7964.786362] device-mapper: > table: 253:0: crypt: Device lookup failed > Aug 4 00:16:01 grml kernel: [ 7964.786367] device-mapper: > ioctl: error adding target to table > Aug 4 00:16:01 grml udevd[2409]: inotify_add_watch(6, > /dev/dm-0, 10) failed: No such file or directory > Aug 4 00:16:01 grml udevd[2409]: inotify_add_watch(6, > /dev/dm-0, 10) failed: No such file or directory > > Aug 4 00:17:14 grml kernel: [ 8038.196371] md1: detected > capacity change from 1999886286848 to 0 > Aug 4 00:17:14 grml kernel: [ 8038.196395] md: md1 stopped. > Aug 4 00:17:14 grml kernel: [ 8038.196407] md: unbind<sda2> > Aug 4 00:17:14 grml kernel: [ 8038.212653] md: export_rdev(sda2) > --- dmesg --- > > Additionally right after that I did `luksHeaderBackup` and the > checksum of that file > > $ md5sum 20110804--new-drive--luksHeaderBackup--sda2--after-command-b > 7b897c620776f549324810a8aeb9921e > 20110804--new-drive--luksHeaderBackup--sda2--after-command-b > > is the same as when doing `luksHeaderRestore` from the old working > drive and then `luksHeaderBackup`. > > # md5sum sda.header > 7b897c620776f549324810a8aeb9921e sda.header > > So `luksHeaderRestore` does not seem to update it or only parts which > were not corrupted (since the passphrase does not work with it). > > > Thanks and sorry for stating the obvious, > > Paul > > > PS: I hope, someone on linux-raid will shed some light into how the > corruption could have happened. > > > [1] http://marc.info/?l=linux-raid&m=131248606026407&w=2 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
