From: Mike Cochran (slyball@covad.net)
Date: Wed Nov 27 2002 - 10:46:26 EST
Well I was up and running within 24 hours of posting here which is pretty
terrific. Since I was in a hurry I chose the anticlimactic potential
solution that seemed to have the highest chance of success first rather than
a more methodical approach. Here is the advice Selden Ball gave me:
It's a limitation in the 4.0f installation script.
> Some models of Quantum disks simply aren't recognized.
> We ran into this same problem with some of their Viking disks.
> I think it's because of the multiple spaces in the model name in the
> SCSI device information that they return. Note that your error message
> refers to the disks as being named "IV" rather than displaying the full
> name.
> One workaround that I used for a while is to install 4.0F on a
> non-Quantum disk (e.g. Seagate) and then copy the partitions to
> the Quantum drive. The system will boot from the Quantum disk
> and run with no problems. That's such a royal pain, though, that
> it's probably better just to replace the disks. That's what we're doing.
This answer smelled right. I could not explain the "IV" either, and if the
problem was due to a corrupt label why would it be happening exactly the
same on both disks? The cover was already off, I had a seagate barracuda
lying around, and it was only minutes to install it and of course it worked
fine right away.
When I have a few more spare moments I will try Jay Vlack's idea on the
quantum drives and leave a short summary. He suggested to use chmod to make
the disk writeable from the console, then to use the disk exerciser to wipe
clean the first 8 megs of the drive, destroying any label:
>>> chmod +w dka100
>>> exer -a w dka100 &
>>> show_status
(When the Bytes Written counter passes 8MB (8388608) you can stop the
exer process by initializing the system:)
>>> init
Thanks also to David Warren, Jerome Berkman.
Mike (spamtarget@covad.net)
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:00 EDT