Need disk info (

[David J. Camp]

>
>
>>From david at wubios.wustl.edu Wed Aug 23 01:57:31 1989
>>
>>We just recently installed a Wren V and are running SunOS 4.0.3, and it
>>works like a champ.  The installation was not straightforward though.  I
>>have been planning to send a horror story to comp.sys.sun, but if you
>>are impatient for details, reply to me and I will give you more
>>information.  -David-
>
>Hi, David.  I would like to get some details.  I need to get this thing 
>running on 4.0.3 before students return, or wait until the Christmas break
>(when I'll have time to deal with it).
>
>  Thanks a bunch,
>    David Brown
>    david at pyr.gatech.edu
>

This is what I have so far.  I hope it is helpful.

This is a sob story about our ordeal in installing a new 600MB Wren V disk
drive on our Sun 3/260.  We ordered the Wren and a Sun MD25 controller
from SSI, who promised two week delivery.  Although they failed to deliver
on time, they were extra helpful in trying to get the disk installed and
the system operational.  After numerous delays and one foiled attempt to
use an alternate controller, we decided to daisy chain the new disk onto
the existing MD21 controller, until the new controller was available from
Sun, who is reported to be shipping *nothing* because of problems
converting to their new inventory system.  Well, we got the disk
installed, and it seemed like it was starting to work, so we closed the
lid, and tried to boot.  No luck.  After much discussion and failed
attempts, SSI decided to call in the Pro from Peoria, Phil Dubee of ATS.
He brought with him various Sun parts, and easily fixed the problem by
ssubstituting a new SCSI controller.  To be safe, he took the entire disk
back to Peoria for testing, and returned it in a few days.  He got the
system back up so that we could format the disk.  Everything was going
fine at this point, when we were about to create a symbolic link from /tmp
to /var/tmp.  I proceded to remove everything inb the /tmp directory.  I
learned that the files starting with '.' were not removed, so I issued
'/bin/rm -r /tmp/.*' which promptly started deleting my entire file
system, starting with /tmp/..  (root).  That was not too bad, since we had
level zero backups.  Much to our surprise, our tape drive was
unresponsive.  We have called our servicemen back for a repair, but
meanwhile we were dead in the water.  Luckily, the /etc/restore command
was intact, and we were able to use the tape drive on a remote system in
the same room!  As I write this we are restoring our files.  I suspect
this was one of the first Sun systems that SSI has handled in Saint Louis,
so they should be more efficient for the experience in the future.

Now for the useful information.  We learned from the System
Administrator's Manual that the format command is not clearly explained to
our satisfaction.  Although most of the information is present, I thought
it would be helpful to give a simple list of the steps required to format
a new disk.  The first thing we tried was to define our own substitute for
the /etc/format.dat file.  We learned that this was not helpful.  When
using our modified version, the format command refused to recognize our
disk.  We never did figure out what we were doing wrong, but we found that
we could use the default file with success.  When you first enter the
format program, it will prompt you with a list of disks.  One of the disks
corresponded to our disk, although I am told you can use the 'unknown'
entry if it is present.  It prompted us for the number of cylinders, etc,
to which we used the defaults, and we got the format> prompt.  The
complexity is in that the Wren actually uses a variable number of sectors
per track, depending on the distance from the spindle.  Apparently, you
can tell the controller any number of sectors per cylinder, and the drive
will accomodate you.  Thus we used the 'type' subcommand to generate a
pretend drive with the requisite paramters.  A consultant named John
Mainini of Frontier gave us a set of parameters that he has determined
will work on any Sun.  Those are 1522 cylinders plus 2 alternates, 15
heads, 51 sectors per track, and 3600 rpm.  Next we ran the 'defect'
subcommand, used 'original' to get the manufacturers defect list, 'dump'
to make a copy in a file, and 'commit' to make the changes effective.
Next we ran the 'format' subcommand.  It estimated it would take 14
minutes, but in fact took over an hour.  Once format was complete, we ran
'partition' and defined our desired partitions.  We then used 'label' to
make the changes effective.  For good measure, we ran 'label' both from
the 'partition' submenu, and directly from the format> prompt, but I think
that was unnecessary.  Now we were sone with format, (quit) and run newfs
on each partition.  It was necessary to generate the various empty
directories corresponding to the new partitions, and edit the /etc/fstab
file to mention the new partitions, We could then mount the new
partitions.

Once we got all of our files restored from the remote tape drive.  We
tried to reboot.  Oops, we were supposed to run installboot.  Now our disk
would not boot, and our tape drive was inoperative.  There is always
another way.  We proceeded to install the Sun3 SunOS on a nearby Sun4, so
that we could boot it in client mode.  After much frustration, we got it
to work.  However, while booting from the Ethernet, it got caught in the
Size: prompt where is says 'Size: #####|/-\####|/-\#####'.  When it got to
the first spinning prompt, it slowed way down, and took a long time.
Every now and then it would say something like the server was not
responding, and then it would recover and we would see a flurry of network
activity.  What made things worse, was that sometimes once it booted, it
complained that it could not find its domain, and we had to reboot.

Once we got it booted, we ran installboot and were then able to boot
normally.  We finished setting up our new parititions, and the new disk is
now running happily, providing us with lots of extra space.  -David-

Bitnet:   david at wubios.wustl                ^      Mr. David J. Camp
Internet: david%wubios at wucs1.wustl.edu    < * >    Box 8067, Biostatistics
uucp:     uunet!wucs1!wubios!david          v      660 South Euclid
Washington University (314) 36-23635               Saint Louis, MO 63110