On 12 March, I wrote:
> I have a CDC Wren VII 1.2 GB disk that I bought about one year ago. I am
> trying to use it to boot an ELC. It fails with the following messages:
> Boot device /sbus/esp0,800000/sd@3,0
> Can't read disk label
> Can't open Sun disk label package
> boot-block startup failed
> Illegal Instruction
> I have trying booting an SS2 with this disk and it also fails, but it will
> successfully boot an SLC. On the ELC and SS2, I can mount the various
> partitions of this disk without problems.
> The disk identifies itself (in response to a probe-scsi) as
> IMPRIMIS94601-15 097300015970 Copyright (c) 1990 Seagate All
> rights reserved 0005
> At auto-config when booting off of a different disk, it identifies itself as
> CDC Wren VII 94601-12G Cyl 1925 alt 2 hd 15 sec 70
> Does anyone know
>  Why it is failing to boot?
>  What can I do about it?
> I seem to recall having seen something about this a while ago, but the wais
> archive seems to be down. (Any one know anything about that?)
First, I seems as if the wais archive as moved to cmns-sun.think.com (all of
the other information is the same).
As for the replies:
Tom Conroy (tom_conroy@3Com.COM) suggested "that there is a problem
either with SCSI bus termination or with SCSI cable length."
Marcel Bernards (Bernards@ECN.NL) offered "probably a fresh
installboot from a diskless booted SS2 will do. If not, maybe some bad
cable connection is bothering you."
Perry Hutchison (Perry_Hutchison.Portland@xerox.com) suggested "using
its format(8) and installboot(8) to label the disk and install the
bootblocks? There may be an OS version and/or kernel architecture
The correct answer came from Michael D. Reynolds (icgmfg.mke.ab.com),
Charlie Butterfield (email@example.com), and Shelley L. Shostak
It has to do with the firmware on the older Wren VII drives.
Shelley's response was the most informative and appears below.
Charlie's response is also useful (and in my opinion the correct one.
Unfortunately, I had neither the time nor the money to send me disk
back, and I had to use this disk as my boot device.) and also appears below.
--- From Shelly L. Shostak ---
This is a well known problem. Here's what some kind person sent me.
Shelley L. Shostak (919) 660-6573
Computer Science Dept. firstname.lastname@example.org
Durham, N.C. 27706
Date: Wed, 23 Oct 91 09:04:10 +0100
From: idtsun1!duepmeie (Clemens Duepmeier)
Subject: Re: Can't boot SS2 from external scsi disk
I hope that I can help you.
The reason, that you can't boot from a WREN VI 94241-502 SCSI is a bug in
the firmware of the disk. There is a work around, which is described in the
following reply from Daniel Phaneuf.
Problem is due to a Wren VII firmware bug.
There is a simple workaround.
The Wren VII drive screws up when issued a "spin up" command with the
"immediate" bit set. Sometime after that command is issued, a subsequent
command will fail (the particular command which fails is a "read", reporting
an "internal target error" status).
The problem does not occur if the "spin-up" command does not have the
immediate bit set. (The immediate bit, when set, means that the device
should start the operation and then complete the SCSI transaction, without
making the CPU waiting for the operation to complete.)
Add the following commands to the NVRAMRC file. The effect is to turn off
the immediate bit on the spinup command.
0: true to fcode-debug?
1: probe-all install-console banner
2: cd /sd
3: patch 0 1 sstart
setenv use-nvramrc? true
Then power cycle. Subsequent attempts to boot from the Wren drive
should be successful.
--- From Charlie Butterfield ---
We had this problem too. The SS2 boot code behaves a bit differently
than the SS1/SS1+ and exposed a bug in the Wren VII firmware, which
has since been fixed by Seagate. The problem only shows up on "old"
Wren VII disks booting from the SS2.
According to one of our suppliers (Andataco) this problem was fixed by
Seagate back in April 1991 with firmware ("diskware") revision 4638.
BEWARE: there is a purported fix to the problem that involves patching
the boot code on the SS2 (via the nvramrc mechanism). We got this patch
from Sun but it didn't work for us! The best solution is to fix the
disks. [I agree, but the nvramrc fix worked for me -- paul]
Possible solutions are:
1) send the "old" disks back for updated firmware. (BEST SOLUTION)
2) reconfigure your systems so all "old" boot disks are on SS1/SS1+
machines, and only use "new" disks to boot the SS2's.
3) buy new boot disks and use the old ones for non-boot disks.
In any event, if you keep your old disks, you probably should mark them
with a notice to avoid someone later (when all this is forgotten)
trying to use it as a boot disk.
-- Paul T. Keener email@example.com University of Pennsylvania
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:40 CDT