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)
