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