[Udpcast] Re: Problem with recovery partition data
dteed at artistic.ca
Tue Apr 20 21:41:05 CEST 2004
OK, that lzop tip explains one of the sources of "error" I was
seeing - it was just the timestamp in the lzop compressed file
that made cmp of images differ. I've switched to gzip for
testing of images being identical.
I have good news... Switching to the 2.6.5 kernel for a better
tg3 driver on the Broadcom 5702 ethernet has resolved the
problem I had with F11 restore breaking. We are now getting
identical duplications of the IBM R31 models.
I can only guess that there was some timing issue with UDP
multicast in the tg3 driver that was fixed since 2.4.24
(the kernel that originally was used on the udpcast server
and had failed to produce accurate images).
A big thanks to Alain for the kernel updates, fixes (busybox shell),
lots of helpful information on DHCP options, and troubleshooting advice!
I'm a fan. We need to get udpcast T-shirts or something. This
must be twice as cool as Samba.
On Mon, 19 Apr 2004, Alain Knaff wrote:
> begin Monday 19 April 2004 17:52, Donald Teed quote:
> > 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?
> No, unfortunately this doesn't work out: lzop includes the date in the
> compressed file, so compressing twice the same device yields different
> Obviously, if you decompress these two different files again, you get
> the same contents however.
> Thus, for comparison purposes, best work on *un*compressed data.
> N.B. If you do the test on a file (rather than on a device), it will
> work, because in that case, the date used is the one from the file,
> rather than current time.
More information about the Udpcast