From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <wagner@tansi.org>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id GyftBB1OKdc4 for <dm-crypt@saout.de>;
 Fri,  5 Aug 2011 17:08:58 +0200 (CEST)
Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3])
 by mail.saout.de (Postfix) with ESMTP
 for <dm-crypt@saout.de>; Fri,  5 Aug 2011 17:08:57 +0200 (CEST)
Received: from gatewagner.dyndns.org (84-74-166-21.dclient.hispeed.ch
 [84.74.166.21]) by v4.tansi.org (Postfix) with ESMTPA id 9E126206039
 for <dm-crypt@saout.de>; Fri,  5 Aug 2011 17:08:57 +0200 (CEST)
Date: Fri, 5 Aug 2011 17:08:56 +0200
From: Arno Wagner <arno@wagner.name>
Message-ID: <20110805150856.GA17583@tansi.org>
References: <CAOOH3pqkS91HeAxta490Xpr3NT_g+=TWh49NyPO3xYs4XwjO5g@mail.gmail.com>
 <CAOOH3prY2scQMY9MPv0n31S+vAYoSEgWCyz+3pNa7HNN-U76sQ@mail.gmail.com>
 <4E3B5378.2070003@redhat.com>
 <CAOOH3poMKtT0j_Uuuy9bmEepMgVwpmi5s-awqS5O8R19u34xHg@mail.gmail.com>
 <CAOOH3ppo9zNQ14cTe_qw-iz0yKwqJSDgwTyOJ6OBL_3BFmj-PQ@mail.gmail.com>
 <4E3BFB4F.9050508@redhat.com>
 <CAOOH3prtyLExiLrkyxSHVRqR7Tx6BYq4xDHiDfB3QTcjns-wiQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOOH3prtyLExiLrkyxSHVRqR7Tx6BYq4xDHiDfB3QTcjns-wiQ@mail.gmail.com>
Subject: Re: [dm-crypt] How can a passphrase be incorrect even after
 `luksHeaderBackup` and `luksHeaderRestore`?
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On Fri, Aug 05, 2011 at 05:02:13PM +0200, Paul Menzel wrote:
> 2011/8/5 Milan Broz <mbroz@redhat.com>:
> > 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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