[Udpcast] Re: Problem with recovery partition data

Donald Teed dteed at artistic.ca
Mon Apr 19 17:52:28 CEST 2004


In general, should a disk image be identical each time
when compressed with lzop?  I mean, does it make sense to
verify the image by doing this:

cmp image1.lzop image2.lzop

where image2 was created by sending and receiving again image1?

--Donald Teed


On Fri, 16 Apr 2004, Alain Knaff wrote:

> begin  Friday 16 April 2004 04:27, Donald Teed quote:
> > When cmp -l was used to compare the compressed image files,
> > they were mostly the same except for about 7 bytes around the beginning -
> > I didn't let it finish but waited for about 15 minutes
> > and there were no new differences reported.  So that
> > confirms what I suspected - that the partition table
> > was getting corrupted.
> 
> This is very interesting. Now, if we could also have the exact output
> of cmp -l, it would be great!
> 
> My theory about what happens is that on first boot, the BIOS changes
> these for some strange reason. Maybe, for some yet unknown reason, the
> BIOS thinks that the disk needs "initializing" and resets those bytes
> which might contain certain settings that it thinks are his.
> 
> It might be interesting to find out _when_ exactly they change.
> 
> One method is to run a  "hexdump -n 512 /dev/hda" on the disk at
> various stages of the duplication. This prints out a hexdump of the
> first 512 bytes. Then just check whether the 7 bytes have their "good"
> state or the changed state.
> 
> N.B. You can run this command right after the udp-receive without
> rebooting by pressing Alt-F2 and pressing return.  This gives you a
> shell where you can run various commands. You can get back to the menu
> with Alt-F1
> 
> You may need to prefix the command with the word "busybox":
> 
>   busybox hexdump -n 512 /dev/hda
> 
> You can also specify an offset:
> 
>   busybox hexdump -n 256 -s 256 /dev/hda
> 
> This prints out the bytes 256 til 511 (practical to print out only
> around the offset where you expect the change, so you don't need to
> wade through 32 lines of output...).
> 
> My gut feeling is that right after udp-receive, you find the 7 bytes
> in their "original" (good) state, but that they are change after first
> reboot. Or maybe, they only change for certain kinds of reboot
> (i.e. they remain untouched for network boot, but change when
> attempting to boot from the disk).
> 
> I think we can reasonably rule out the following hypothesises:
> 
>  - Network transfer corruption:  No, because then lzop compression
>    would fail in a *very* obvious way (and corruption would be
>    randomly spread accross the whole disk, rather than limited to 7
>    bytes somewhere in the MBR / partition table)
>  - Hard disk read or write corruption: If that was the case,
>    corruption would be spread out evenly accross the whole disk
>  - Different interpretation of hard disk geometry: We would see
>    corruption near the end of the disk, rather than near the
>    beginning.
> 
> Regards,
> 
> Alain
> 
> 



More information about the Udpcast mailing list