Austin Hook wrote:
> After buying a used Dell 2850 PowerEdge rack mount server I tried to
> install 3.8 but I found that the CDROM seemed to be giving me bad data.
> The tar/unzip process during install seemed to have trouble with larger
> data files, complaining something about having to search for header data
> after apparently getting some junk.  What was curious is that the read
> itself didnt seem to report any errors, only the tar extract process
> seemed to be complaining.

You sure someone didn't sell you defective CDs? ;)

(to those who have noted my ability to respond to someone without
realizing who it was I was responding to, no, not this time.  Hiya,
Austin! :)

> So I installed over my network by ftp, using the same CD #1 from the 3.8
> set.  All went well.
> 
> Afterwards I decided to do the following (typescript follows):
> 
> Script started on Fri Jan 13 10:30:15 2006
> # #  Previously I did a mkdir /cdrom
> # mount -t cd9660 -r /dev/cd0a /cdrom
> # cp /cdrom/3.8/i386/base38.tgz .
> # diff /cdrom/3.8/i386/base38.tgz base38.tgz
> Binary files /cdrom/3.8/i386/base38.tgz and base38.tgz differ
> # exit
> 
> Script done on Fri Jan 13 10:32:16 2006
> 
> In other words the file I got on hard drive after copying from the CDROM
> was not the same as the file on the CDROM, and yet no read errors were
> reported to me.

Thanks for digging up another happily repressed memory.  (grumble)

Yeah, I've seen this before.  Defective CDROM drive.  No idea how this
is possible, look at the descriptions, it seems there is all kinds of
error detection in a CDROM drive, but I've seen exactly what you
describe multiple times on multiple OSs with at least two different
CDROM drives.  Change drive (even with a non-defective same model,
somehow I managed to have identical copies of both drives that did that
to me), problem vanishes.  Be grateful for the error when uncompressing.
 Really nasty when it happens and the OS you are installing just relies
on reported read errors to verify the files it pulled from CDROM.

But yes, it is possible to have a CDROM drive malfunction so that it
will pull invalid data from the CD, and NEVER REPORT A PROBLEM TO THE
OS.  In addition to the two drives I had that did that to me personally,
I think I have diagnosed this problem on at least one other person's
system.  Curiously, when I've seen this, it REALLY shows itself big.  No
(or very few?) "one-time" events, so this probably indicates some kind
of malfunction in the error detection system on the drive.

> However, if I do this on another machine -- the one where I mounted the
> CDROM to do the across-net install, the two files do not differ.
> 
> In all cases, on any machine or CDROM, I get the same length of file for
> base38.tgz:  36790935.  However a md5 checksum done either directly on the
> Dell 2850 or on the copy I attempted to make, shows a different checksum,
> whereas on other machines the checksums are the same for originals
> directly computed off the cdrom or the copy I make to hard drive -- and
> the those good checksums are different from both the original and the copy
> I access on the Dell.  I presume copies to the Dell, over the net are
> fine.  So it's just the process of reading from the CDROM on the Dell that
> is happy to give bad data without saying so.
> 
> Am I missing something?

Yeah, the fun of that same kind of thing happening when reading and
writing to a hard disk.  That was horrible *shudder*.  Not an OpenBSD
story, though.

Nick.
(gonna have nightmares tonight)

Reply via email to