SUMMARY : Problems formatting Wren IV drives under SunOS 4.1.1

From: Chris Hopkins (
Date: Thu Oct 17 1991 - 12:07:50 CDT

On Sat, 21 Sep 91 I sent the following message:


Sun Managers,

We have found a problem with attempting to upgrade our Sun systems from
SunOS 4.0.3 to SunOS 4.1.1 this weekend.

The problem occurs with 4/330 machines which have an internal (Sun supplied)
Wren IV drive which announces itself as:

sd6: <CDC Wren IV 94171-344 cyl 1545 alt 2 hd 9 sec 46>

when booting. Whilst using SunOS 4.0.3 we have had no problems with these
drives. However, when installing SunOS 4.1.1, trouble occurs when
trying to format the disk when the following is seen:


sun# format
Searching for disks...done

        0. sd6 at sm0 slave 24
           sd6: <CDC Wren IV 94171-344 cyl 1545 alt 2 hd 9 sec 46>
Specify disk (enter its number): 0
selecting sd6: <CDC Wren IV 94171-344>
[disk formatted, defect list found]

        disk - select a disk
        type - select (define) a disk type
        partition - select (define) a partition table
        current - describe the current disk
        format - format and analyze the disk
        repair - repair a defective sector
        show - translate a disk address
        label - write label to the disk
        analyze - surface analysis
        defect - defect list management
        backup - search for backup labels
format> format
Ready to format. Formatting cannot be interrupted
and takes 16 minutes (estimated). Continue? y
Beginning format. The current time is Sat Sep 21 17:16:44 1991
Block 3 (0/0/3), Fatal non-media error (hardware error)


This disk has the following defect list:

 num cyl hd bfi len sec
   1 323 2 13050
   2 337 0 20590
   3 341 7 290
   4 341 7 17690
   5 567 5 29290
   6 568 5 29290
   7 569 5 29290
   8 570 5 29290
   9 571 5 29290
  10 572 5 29290
  11 573 5 29290
  12 574 5 29290
  13 1047 8 8410
  14 1048 8 8410
  15 1049 8 8410
  16 1050 8 8410
  17 1051 8 8410
  18 1052 8 8410
  19 1053 8 8410
  20 1054 8 8410
  21 1055 8 8410
  22 1164 3 6670
  23 1420 6 4350
  24 1420 6 4930
  25 1441 4 12470
total of 25 defects.

The format.dat being used is the one supplied in SunOS 4.1.1

The problem seems to happen with some but not all of our 4/330 systems. After
having trouble with the first set of machines we tried, we later only
ran "newfs" to set up the filesystem for the new OS but have also had problems
getting "newfs" to run correctly - the machines complain of a failure
to complete writes to the disk.

I can't believe that this is a hardware fault as too many machines are affected
for it to be coincidence but am at a loss as to how to solve the problem.
We do have a hardware/software support contract with Sun but I would like
to complete these upgrades this weekend if I can.

Has anyone seen this problem before and can suggest a solution?


First my apologies for not summarising sooner but unfortunately I haven't had
any really conclusive answers and I have been waiting for Sun to come with
a definitive solution (apart from replacing the disk) -- they haven't :-(

So, here are the responses I received:


From: "Anthony A. Datri" <>

Why are you trying to format the disk in the first place?

I've had this problem on Sun 4's trying to format brand-new drives, and
just gave up formatting them -- they typically come from the vendor formatted,
and I just have to slap a label on them. I've found, though, that formatting
on a Sun 3 or a Solbourne usually works.

>> Well I guess I never thought of using format as being a risky process. It
>> seemed from responses I have seen in the past from the sun-managers list that
>> reformatting the drives from time to time is beneficial as it compensates
>> for wear which affects the tracking of the heads.


From: (Jan Berger Henriksen)

Oh, have I seen this problem before :-) The second variety is when
format fails attempting to write *beyond* the physical size of the
the disk (like 4537/15/9 or something).

I have no solutions for you, only a couple of work-arounds you may try:

        - with the block 0/0/3 message, it is sometimes possible to
          initialize an *empty* defect list, and then have format succeed
        - but, mostly, just label the disk and run newfs.

There's nothing that requires a format in installing a new OS, but running
newfs in this case is a *good* thing, due to a more efficient file-system
in 4.1 and above. The problem becomes *major* when you really need to
format a disk due to bad sectors etc.

We currently have asked our vendor to look into this, and they are
being *real* quiet.

>> Unfortunately, using an empty defect list did not work and after format had
>> failed, it was impossible to run newfs.


From: Kerien Fitzpatrick <>

Sounds to me more like a firmware revision on the Wren drives. You
might take a look at them and see if you can find a commonality of
problems to firmware rev.

How old are your 4/330? Between 4.0.3 and 4.1.1 I believe Sun switched
to SCSI-2 and old Wrens may have the correct firmware for that.

>> Our hardware configurations have not changed since the systems were bought.
>> The disks can from Sun and worked fine under 4.0.3 -- all we were trying to
>> do was upgrade the operating system.


From: "Frank P. Bresz" <>

I saw a very similar problem when we upgraded a 3/260 to a 4/330. I have
used your mail as ammo against Sun. I will let you know if I hear anything
from them, and would appreciate if you could let me/theNET know what you hear.

>> I wish I had something more positive to say but all Sun did was replace the
>> disks concerned and say that two failing at once must be a coicidence :-(
>> NB we only tried formatting four before we decided to only newfs the rest!


From: "alex;923-4483" <>

You are out to far, and hitting into the reserved space.

I use

        1416 cylinders 9 heads 46 sectors/track

On a 941710-307 its

        1809 cylinders 9 heads 36 sectors/track

>> We tried this but to no avail.


From: Kirt Schaper <vapet!kirt>

I had the same problem with 1 of 2 4/370's. I couldn't
format the drive or restore the old system. We're under
Sun maintenance and they swapped the disk and everything
was OK.

>> This was the solution we were forced to adopt. Unfortunately, it now means
>> that we can no longer trust "format" which is somewhat inconvenient. I would
>> still like to know why format failed.

Thanks to all who responded. If anyone finds out the real reason why format
seems to fail in similar circumstances I would be glad to hear.

Chris Hopkins
British Aerospace
Sowerby Research Centre

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:18 CDT