All,

I've run into an interesting case of file corruption just now, trying to
upgrade a 4.99.3 installation on a Quadra 650 from last November to a
4.99.20 snapshot of today's sources.

As always, I rcp(1)ed the result of the cross build over from the
fileserver, installed the new GENERIC kernel, rebooted, went to single user
mode and started a script that checks the tarballs against the MD5 hashes
and goes on to untar them.

Now, although the MD5 comparison went fine, four of the tarballs came up
with gzip crc errors. A 'gzip --test' run came up with three corrupted
archives. Since I suspected the network transfer, I re-fetched the three
tarballs, this time with ftp, and unfortunately overwrote what I had
already fetched. Unsurprisingly, the re-fetched tarballs were also corrupt.

The tarballs on the fileserver are fine. Using a nubus sm(4) adapter
instead of the obio sn(4) also results in corrupted tarballs (which
probably means that Izumi-san's driver changes are not responsible here). A
memory test came up negative. The machine has built quite a few kernels
with 4.99.3, and has run a 'build.sh tools' from nfs-mounted sources a week
ago just fine.

While I go on thinking of how to recover the machine - does anyone run
bleeding-edge current, and can report their experience with an update?

	hauke


--
"It's never straight up and down"     (DEVO)