All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Menzel <pm.debian@googlemail.com>
To: Milan Broz <mbroz@redhat.com>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] How can a passphrase be incorrect even after `luksHeaderBackup` and `luksHeaderRestore`?
Date: Fri, 5 Aug 2011 14:11:26 +0200	[thread overview]
Message-ID: <CAOOH3ppo9zNQ14cTe_qw-iz0yKwqJSDgwTyOJ6OBL_3BFmj-PQ@mail.gmail.com> (raw)
In-Reply-To: <CAOOH3poMKtT0j_Uuuy9bmEepMgVwpmi5s-awqS5O8R19u34xHg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4230 bytes --]

2011/8/5 Paul Menzel <pm.debian@googlemail.com>:
> 2011/8/5 Milan Broz <mbroz@redhat.com>:
>> On 08/05/2011 01:18 AM, Paul Menzel wrote:
>>> % sudo md5sum /tmp/*header
>>> 7b897c620776f549324810a8aeb9921e  /tmp/sda2.header
>>> 7b897c620776f549324810a8aeb9921e  /tmp/sda.header
>>> ce314509007b2c76eb85e7b89ee25da5  /tmp/sdb.header
>>> ------- 8< --- entered commands --- >8 -------
>>>
>>> I would have assumed that all files are identical, i. e. they have the
>>> same hash.
>>
>> It should be the same.
>> (But there is gap between header and keyslot which is explicitly wiped
>> during backup. But from the commands you run it should be the same now.)

[…]

>> Can you try the same exercise but running it through loop device?
>>
>> (dd e.g. 4M from both sd[ab] disks, map it to loop devices and run the same
>> commands - luksHeaderBackup/Restore.
>
> ------- 8< --- entered commands --- >8 -------

[ Got header from loop mounted `dd copies`. ]

> root@grml ~ # md5sum *header
> 7b897c620776f549324810a8aeb9921e  sda.header
> ce314509007b2c76eb85e7b89ee25da5  sdb.header
> root@grml ~ # cryptsetup luksHeaderRestore /dev/loop3
> --header-backup-file sdb.header
>
> WARNING!
> ========
> Device /dev/loop3 already contains LUKS header. Replacing header will
> destroy existing keyslots.
>
> Are you sure? (Type uppercase yes): YES
> root@grml ~ # cryptsetup luksHeaderBackup /dev/loop3
> --header-backup-file sda.header2
> root@grml ~ # md5sum *header*
> 7b897c620776f549324810a8aeb9921e  sda.header
> ce314509007b2c76eb85e7b89ee25da5  sda.header2
> ce314509007b2c76eb85e7b89ee25da5  sdb.header
> ------- 8< --- entered commands --- >8 -------

One addition. `cryptsetup luksOpen /dev/loop3` does *not* work on the
original file gotten from `/dev/sda2` with `dd`. It *does* work after
`cryptsetup luksHeaderRestore /dev/loop3 --header-backup-file
sdb.header`.

>> Do you see the same problem?
>
> 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

--- 8< --- sfdisk output --- >8 ---
% sudo sfdisk -l /dev/sda

Disk /dev/sda: 243201 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1   *      0+     61      62-    497983+  fd  Linux raid autodetect
/dev/sda2         62  243200  243139  1953014017+  fd  Linux raid autodetect
                end: (c,h,s) expected (1023,254,63) found (512,254,63)
/dev/sda3          0       -       0          0    0  Empty
/dev/sda4          0       -       0          0    0  Empty
% sudo sfdisk -V /dev/sda
partition 2: end: (c,h,s) expected (1023,254,63) found (512,254,63)
/dev/sda: OK
--- 8< --- sfdisk output --- >8 ---

and he guesses that I will be able to reproduce the problem when
writing with `dd oflag=direct …`.

Unfortunately, this does not seem to be the case.

I attach my commands and their outputs since it would be horrible to
read  with Google Mail line wrapping “feature”.

--- 8< --- md5sum of dd commands --- >8 ---
# md5sum *drive*

62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048-iflag-direct
11faaf01449e87f40378945392819c09
new-drive--dd-bs512-count2048-iflag-direct-sync--with-dd-from-old--written-with-oflag-direct-sync-to-new
11faaf01449e87f40378945392819c09
new-drive--dd-bs512-count2048--with-dd-from-old
11faaf01449e87f40378945392819c09
new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-sync-to-new
11faaf01449e87f40378945392819c09
new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new
11faaf01449e87f40378945392819c09
new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new2
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048-iflag-direct
--- 8< --- md5sum of dd commands --- >8 ---


Thanks,

Paul

[-- Attachment #2: 20110805--history-of-shell-comands-and-output --]
[-- Type: application/octet-stream, Size: 6332 bytes --]

root@grml ~/ein # dd if=/dev/sdb2 of=old-drive--dd-bs512-count2048 bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.0343698 s, 30.5 MB/s
root@grml ~/ein # dd if=/dev/sdb2 of=old-drive--dd-bs512-count2048-iflag-direct bs=512 count=2048 iflag=direct
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.209783 s, 5.0 MB/s
root@grml ~/ein # dd if=/dev/sda2 of=new-drive--dd-bs512-count2048 bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.455503 s, 2.3 MB/s
root@grml ~/ein # dd if=/dev/sda2 of=new-drive--dd-bs512-count2048-iflag-direct bs=512 count=2048 iflag=direct
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.767138 s, 1.4 MB/s
root@grml ~/ein # md5sum *drive*
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048-iflag-direct
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048-iflag-direct
root@grml ~/ein # dd if=old-drive--dd-bs512-count2048 of=/dev/sda2 bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.0365978 s, 28.7 MB/s
root@grml ~/ein # dd if=/dev/sda2 of=new-drive--dd-bs512-count2048--with-dd-from-old bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.463175 s, 2.3 MB/s
root@grml ~/ein # md5sum old-drive--dd-bs512-count2048 new-drive--dd-bs512-count2048--with-dd-from-old
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old
root@grml ~/ein # cryptsetup luksOpen /dev/sda2 sda2_crypt
Enter passphrase for /dev/sda2:
root@grml ~/ein # # That worked and I could access my data after mounting `sda2_crypt`.
root@grml ~/ein # dd if=old-drive--dd-bs512-count2048 of=/dev/sda2 bs=512 count=2048 oflag=direct
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.365299 s, 2.9 MB/s
root@grml ~/ein # dd if=/dev/sda2 of=new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.442945 s, 2.4 MB/s
root@grml ~/ein # md5sum *drive*
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048-iflag-direct
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048-iflag-direct
root@grml ~/ein # # I tested if `blockdev --setro /dev/sda2` for *reading* (for writing it was turned on) made a difference. It did not.
root@grml ~/ein # dd if=/dev/sda2 of=new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new2 bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.0204029 s, 51.4 MB/s
root@grml ~/ein # md5sum *drive*
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048-iflag-direct
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new2
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048-iflag-direct
root@grml ~/ein # dd if=old-drive--dd-bs512-count2048 of=/dev/sda2 bs=512 count=2048 oflag=direct,sync
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 51.4745 s, 20.4 kB/s
root@grml ~/ein # dd if=/dev/sda2 of=new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-sync-to-new bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.0296868 s, 35.3 MB/s
root@grml ~/ein # md5sum *drive*                                                                                                             62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048-iflag-direct
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-sync-to-new
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new2
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048-iflag-direct
root@grml ~/ein # dd iflag=direct,sync if=/dev/sda2 of=new-drive--dd-bs512-count2048-iflag-direct-sync--with-dd-from-old--written-with-oflag-direct-sync-to-new bs=512 count=2048
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.328304 s, 3.2 MB/s
root@grml ~/ein # md5sum *drive*                                                                                                             62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs512-count2048-iflag-direct
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048-iflag-direct-sync--with-dd-from-old--written-with-oflag-direct-sync-to-new
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-sync-to-new
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new
11faaf01449e87f40378945392819c09  new-drive--dd-bs512-count2048--with-dd-from-old--written-with-oflag-direct-to-new2
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048
11faaf01449e87f40378945392819c09  old-drive--dd-bs512-count2048-iflag-direct

  reply	other threads:[~2011-08-05 12:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 21:31 [dm-crypt] How can a passphrase be incorrect even after `luksHeaderBackup` and `luksHeaderRestore`? Paul Menzel
2011-08-04 23:18 ` Paul Menzel
2011-08-05  2:20   ` Milan Broz
2011-08-05  8:41     ` Paul Menzel
2011-08-05 12:11       ` Paul Menzel [this message]
2011-08-05 14:16         ` Milan Broz
2011-08-05 14:52           ` Arno Wagner
2011-08-05 14:55             ` Arno Wagner
2011-08-05 17:47             ` Milan Broz
2011-08-05 15:02           ` Paul Menzel
2011-08-05 15:08             ` Arno Wagner
2011-09-01 19:08           ` Paul Menzel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOOH3ppo9zNQ14cTe_qw-iz0yKwqJSDgwTyOJ6OBL_3BFmj-PQ@mail.gmail.com \
    --to=pm.debian@googlemail.com \
    --cc=dm-crypt@saout.de \
    --cc=mbroz@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.