Dear managers!
Thank you very much for your responses, the most valuable coming from
"Dr. Tom Blinn, 603-884-0646" <tpb_at_doctor.zk3.dec.com>:
"... I suspect that you're tripping on some bug in the install
scripting; I suspect (but without access to an instance of the disk it's
hard to tell) that something in the installation logic is not expecting
the vendor ID field in the disk to be as complicated as what your disk
is probably returning. Needless to say, I apologize for our product's
failure to meet your needs in this area..
The GUI just uses things like commands to get information, then tries to
use that information to map things up. If it's getting confused, it may
not be able to find the right disk or read the disk label.
The character cell install runs the .profile script from the kit to do
all of the control; in fact, the .profile script runs the GUI install,
too. There is a program called "finder" that is, if I recall right, the
active agent in identifying target disks for installation. I suspect it
can't handle the disk you've got -- that it's getting confused by the
disk ID string's length and number of words. There is no good reason
for this but in my experience, the installation team would excuse the
misbehavior by claiming it's an unsupported device, instead of admitting
that their logic is flawed.
You might need to find a simpler disk to install to, then after you've
got the system software installed, copy it to your big disk and adjust
things as necessary to run the system from the QUANTUM VIKING II."
and alan_at_nabeth.cxo.dec.com:
"The printable part of the SCSI Inquiry data consist of three fields:
Vendor ID - 8 bytes
Product ID - 16 bytes
Product revision level - 4 bytes
The driver reformats the fields as a single string, with spaces in right
places to make it readable. So, the vendor ID is "QUANTUM ". This
probably isn't a problem, but the product ID using all 16 bytes could
be.
If you have an extra disk, you could install to the supported disk and
then migrate the information. The installation may only care about the
root file system, which limits the amount of data that would need to be
moved after the installation."
So it turns out that the disk´s vendor id field is the culprit. It
causes finder to not identify the vendor ID correctly. Therefore the
disk is not usable for installation. It's operable under DU, though
(I´ve verified that), so what I'm going to do is follow Tom's and Alan's
advice and copy an already running version of DU 4.0F onto the disk...
Regards
Peter
Original message follows:
I'm still being in the process of installing DU 4.0F on a PW433au. The
disk i've chosen (QUANTUM VIKING II 9.1WLS 3506) is not recognised by
the installation procedure regardless whether I choose X-based ("Can't
read the existing label on device I") or command line based installation
("This system appears to have no disk(s)..."). The installation is
subsequently aborted.
What puzzles me most is that the OS booted from CDROM appears to support
the disk (recognised as rz16 during initialization): I can create
partitions by writing a disk label and I can use newfs to create file
systems. I can even mount these file systems and copy files. Everything
seems to work perfectly well except...
I can hardly believe the disk isn't supported.
--
Dipl.-Phys. Rolf-Peter Kienzle
Dept. of Remote Sensing and Land Information Systems
University of Freiburg, D-79085 Freiburg, Germany
Tel/Fax +49 761 203 8643/8640 e-mail: kienzlep_at_uni-freiburg.de
Received on Wed Dec 08 1999 - 17:01:30 NZDT