[Udpcast] Re: Problem with recovery partition data

Alain Knaff alain at knaff.lu
Fri Apr 16 13:29:57 CEST 2004

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



Udpcast mailing list
Udpcast at udpcast.linux.lu

More information about the Udpcast mailing list