Problem with recovery partition data

Donald Teed dteed at artistic.ca
Wed Apr 14 15:05:12 CEST 2004


On Tue, 13 Apr 2004, Alain Knaff wrote:

> The first thing I'd check is to do a compare (using the cmp command)
> between an original (working) hard disk, and a udpcasted disk.
> 
> In order to do this, build the two disks into a same machine one on
> the primary controller, one on the secondary, boot from a Knoppix CD,
> (or from an udpcast CD...) and run a compare:
> 
>  cmp -l /dev/hda /dev/hdc

I'm not sure if I can hook up 2 disks and a cdrom to the notebook
at the same time, and I don't have a network bootable
Linux I can use at the moment.  I'll see if I can do
something like this.

Another possible test would be to upload an image
made from ghost but for 2 different disks, and then do
a cmp on the two image files on the server.  That would
at least verify whether there was something different
for a unique serial number.

> Maybe what's going on here is that the disk's serial number (can be
> displayed using hdparm -i /dev/hda) is stored somewhere in the
> partition table, maybe in some scrambled form. The F11 functionality
> would only works if the physical serial number, and the one in the
> partition table agree?

I thought about that, and my test with the equivalent of g4u
(Ghost 4 Unix) would be consistant with that possibility
of a checksum bit reflecting a serial number or something,
but I also did an image and restore to the same physical disk
with udpcast yesterday and that failed.
 
> It might be interesting to check what happens if you play back an
> image to the disk where it originally came from:
> 
> Disk A ===> Disk B ===> Disk A
> 
> If that works, then I think it might be a serial number issue. (Maybe
> overwrite Disk A with sth else between the two transfers, or manually
> switch off the F11 functionality)

I did this with udpcast as the transfer method and I zeroed
the drive with dd between the restore.  Using that method,
the g4u method of image and restore was able to boot with F11.
Using the same approach and the same physical disk for the master
and restored disk, udpcast failed to provide the F11 boot option
(even with the CMOS flag forced to on from an IBM boot floppy).

> Another theory is that somehow the disk geometry as it appears to
> Linux is not the complete disk, and that one or more sectors near the
> end of the disk do not get copied, because for some reason the kernel
> (i.e. operating system binary) is mistaken about the exact size of the
> disk? If those sectors contain information that is critical for the
> F11 functionality, this might explain stuff.

"The kernel" - would be the busybox operating system?  I've been
wondering if this is a variable I should replace since using even
a 8 month old KNOPPIX I have no problems with the dd gzip ftp
method (g4u).

I have the feeling that the exercise with cmp would not offer
me any more detail than what I know now: that somewhere in the process
data is lost.  So what I need to do is pinpoint what part of
the pieces introduces the flaw.
 
> It's rather obvious that this is unrelated to UDP level corruption, or
> else lzop would have complained very loudly.
> 
> It must be something that goes on locally in the machine.
> 
> Maybe also the manufacturer of the machine might have some info how
> the F11 functionality works, unless he considers that a trade secret,
> of course ;-)

I was thinking it could be a trade secret that Ghost and
a few others know about, but since my other open source
option works properly, and udpcast/busybox fails under
the same method (keeping the same disk as source and target),
I doubt it.

Another interesting observation is that simply unhiding and
rehiding the restore partition from Partition Magic
corrects the F11 problem.  Would that mean the error is in
the beginning of the disk where the partition table
is located?

Regards,

--Donald Teed



More information about the Udpcast mailing list