From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pm.debian@googlemail.com>
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 nfkk6a3e-tXz for <dm-crypt@saout.de>;
 Fri,  5 Aug 2011 17:02:14 +0200 (CEST)
Received: from mail-fx0-f50.google.com (mail-fx0-f50.google.com
 [209.85.161.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Fri,  5 Aug 2011 17:02:14 +0200 (CEST)
Received: by fxh2 with SMTP id 2so2759554fxh.37
 for <dm-crypt@saout.de>; Fri, 05 Aug 2011 08:02:13 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <4E3BFB4F.9050508@redhat.com>
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>
Date: Fri, 5 Aug 2011 17:02:13 +0200
Message-ID: <CAOOH3prtyLExiLrkyxSHVRqR7Tx6BYq4xDHiDfB3QTcjns-wiQ@mail.gmail.com>
From: Paul Menzel <pm.debian@googlemail.com>
Content-Type: text/plain; charset=UTF-8
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: Milan Broz <mbroz@redhat.com>
Cc: dm-crypt@saout.de

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.

--- 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