2011/8/5 Paul Menzel <pm.debian@xxxxxxxxxxxxxx>:
> 2011/8/5 Milan Broz <mbroz@xxxxxxxxxx>:
>> 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:
20110805--history-of-shell-comands-and-output
Description: Binary data
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
