More on adding hard disks

[Doug Pintar]

To anyone who was offended by the tone of my previous posting on adding hard
disks under 386/ix 2.0.2, I would like to publicly apologize.  I had hoped
the smiley would forestall the flames, forgetting how frustrating it is when
you're fighting with a system that seems hostile.  I in no way meant to
trivialize Gregory Woodbury's experiences with our software.  However, I think
there is a need to shed some light on his problems and his proposed solution.

In article <1990Jun3.063727.10379 at wolves.uucp> he writes:
>            As an early item in the thread noted, your "precious" little
>    sysadm scripts DID NOT WORK CORRECTLY!  If the d*mned /etc/disk*
>    routines worked right (i.e. didn't assume something illegal about the
>    particular number of drives and which drive was being installed) then
>    none of this painful affair would have made it to the net in the first
>    place.

The first article I found on this subject was
<1990May27.092900.828 at wolves.uucp> in which there is no mention of failures
of the sysadm scripts.  I have personally installed several add-on SCSI
devices using sysadm.  It hasn't failed me yet.  I'm a little unclear on
the comments that the /etc/disk* routines don't work right, as there is
no documentation on how they are SUPPOSED to work.  They are designed to
be run from a script that knows exactly what each one of them does, NOT
to be run by hand by someone unfamiliar with the processes involved.

>            Besides, I've probably forgotten more about the sysadm scripting
>    system than you ever knew.

Quite possibly true.  However, the issue here is setting up a disk, NOT how
sysadm scripts are built.

>        final effective sequence:
>
>        1.  /etc/diskconfig on /dev/dsk/c1d0p0 to get basic geometry
>                (be careful - some of the /etc/disk* commands will trash
>                /etc/partitions - make a backup!)
>
>        2.  run fdisk /dev/dsk/c1d0p0 and make unix partitions
>        3.  put the basic disk "stanza" in /etc/partitions
>        4.  run mkpart -i diskNN to create initial vtoc
>        5.  backup /etc/partitions and run /etc/disksetup
>                this will fail! but partition stanzas will be placed in
>                /etc/partitions for your selected configuration.

The problem here is that /etc/disksetup is the WRONG program to run at this
point.  'disksetup' is designed to build things on BOOT disks, and hence
scribbles on /etc/partitions with gleeful abandon.  A glance through the
sysadm addharddisk script shows it using '/etc/adddisk', which is the
correct program.  It writes the new disk's entries in /tmp/partitions.  This
file is appended to /etc/partitions as the final act of adding a new disk,
so your original version of the file is safe until the process is completed.
As for all the other operations in Gregory's list, they ARE performed by the
sysadm addharddisk function.  Each filesystem is labelled and has a
lost+found directory created on it.

>             Its no wonder that ISC had a bad reputation for customer support
>     if you are an example of their finest.  This is the second time that I
>     have found problems with pieces of ISC code and had absolutly no help
>     from ISC on the problem.

As a matter of fact, I'm not an example of customer support at all!  I'm a
developer.  I believe our customer service personnel are infinitely more
patient and polite than I am.  As for a problem with ISC code related to the
adding of hard disks and controllers, if you could show me a real example of
a problem (and not merely a perception of one) I'd be glad to pass it along
to our support staff.

Doug Pintar

<gee Mom, I got flamed, and it wasn't even in talk.bizarre!>