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
next prev parent 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.