Very Computer

I have SCO 3.2.4 installed and am trying to upgrade to 5.0 via cdrom.
I am trying to install the cdrom using mkdev cdrom.  During bootup
the BIOS tells me that the CDrom is on the secondary scsi card at id 6.
However when the SCO kernel displays the hardware configuration it
doesn't list this.  The SCSI card is recognized but device still is not.
I've run mkdev cdrom and have rebuilt and relinked the kernel with
ha=1 id=6 lun=0 and have created the high-sierra device also to no avail.  
Any ideas????
Please respond via email,
thanks,
David

Quote:Jill R Firch writes:

> I have SCO 3.2.4 installed and am trying to upgrade to 5.0 via cdrom.
> I am trying to install the cdrom using mkdev cdrom.  During bootup
> the BIOS tells me that the CDrom is on the secondary scsi card at id 6.
> However when the SCO kernel displays the hardware configuration it
> doesn't list this.  The SCSI card is recognized but device still is not.
> I've run mkdev cdrom and have rebuilt and relinked the kernel with
> ha=1 id=6 lun=0 and have created the high-sierra device also to no avail.  
> Any ideas????
> Please respond via email,

Why via email??

Are you David or Jill???

Why fight so hard? SCO distributions all default to looking for a CDROM at
ID=5, so just rejumper the drive itself, or you'll have to remember to type
in extra stuff at each and every install.

Do you really have TWO host adapters in your 3.2v4 machine? If not, then
you should be using '0' as the number for 'ha'.

--

JP overstates the difficulty involved.  Since ODT 2.0 or so, you've been
able to tell the install where your devices are through a nice dialog.
Older releases then required a reboot, where the software provided its
own replacement bootstrings to access the devices, if they weren't at
the "expected" locations.  With Release 5 this is done dynamically
without requiring a reboot.

Quote:> Isn't it just more convenient to the user to have the installation scan
> the HBA for devices, a determine what's located where?

Yes, this would be even better.

Quote:> It *should* be enough that the SCSI devices are jumpered to avoid
> conflicts. The rest should be in the hands of the installation software.

> Check out the way UnixWare handles this. Not perfect, but not bad.
> Its installation (actually), every bootup scans the SCSI buses for
> devices, and operates accoringly on CD-ROMs and tape drives.

I've seen some complaints about this, where if a device was missing,
other devices would get moved around -- the device naming or minor
numbers would change from one boot to the next.  This seems like it
could be quite dangerous.  In principle I'd like to have the OS
automatically recognize all recognizable devices (which certainly
includes all SCSI peripherals).  Safely implementing this might be a bit
tricky.  Correct me if I'm wrong about devices shifting under UnixWare
-- maybe they fixed that in 2.0?

Quote:>Bela<

PS: I've discovered that none of my email has been going anywhere for
    the last few days.  The name server appears to be insane on the
    machine where I read mail.  So if anyone's expecting mail from me,
    it'll probably be Monday before it's fixed.

i just love it when word thrashers trivialize software/hardware development.

besides even if sco did allow unlimited configuration options, that still
wont keep some bonehead from hooking it up unterminated or in id conflict
with something else. i think its easier for joe_marginal_integrator
to be told just 'do it this way'. at least they are focused on a single,
well defined objective.

Quote:>--
>--It *should* be enough that the SCSI devices are jumpered to avoid
>--conflicts. The rest should be in the hands of the installation software.
>--
>--Check out the way UnixWare handles this. Not perfect, but not bad.
>--Its installation (actually), every bootup scans the SCSI buses for
>--devices, and operates accoringly on CD-ROMs and tape drives.

when unixware can handle _Correctly_ a fraction of the hardware that
sco can now, then and only then can you use them as an example.

Quote:>--
>----
>-- Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario

how beautiful can it be if all these sour words keep poring from this address?

tiring of this sco-bashing, jackc...

=============================================================================

                                   408-684-9002(fax)    sco.com!blznrzn!jack

=============================================================================

Quote:>Why fight so hard? SCO distributions all default to looking for a CDROM at
>ID=5,

Why is this still necessary?

Isn't it just more convenient to the user to have the installation scan
the HBA for devices, a determine what's located where?

It *should* be enough that the SCSI devices are jumpered to avoid
conflicts. The rest should be in the hands of the installation software.

Check out the way UnixWare handles this. Not perfect, but not bad.
Its installation (actually), every bootup scans the SCSI buses for
devices, and operates accoringly on CD-ROMs and tape drives.

--
 Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario

    There are two types of people: those who divide people into two types,
                            and those who don't.

You're quite right, especially considering that the installation already
does a pretty good job of discerning NICs and video cards.

--

Actually, there are two conventions; one fixed and one variable.
On bootup, each CD-ROM and tape is given two device nodes;

On one sample system, for instance, with an Adaptec 1542, a CD-ROM
at ID 4 and a SCSI tape at ID 6, the following are built at bootup
based on a scan of the SCSI buses:

/dev/rcdrom/c0b0t4l0
/dev/rmt/c0b0t6l0*
*AND*
/dev/rcdrom/cdrom1
/dev/rmt/*tape1

(The asterisks indicate variations on the tape device names to indicate
rewind/non-rewind, etc. Other device names, such as associated block
devices, are also built but deleted for brevety.)

The top two names indicate Controller #, SCSI bus # (to allow for
multi-channel adapters), ID # and LUN #. Software that *expects* to see
a specific kind of device at a specific ID, and gives an error if there
is no device there, uses the naming convention of the top two. These are
the main devices.

The lower two device names are linked to the others at bootup.
Software which just wants to access "the first CD-ROM" (likely, on
most systems, to be the only CD-ROM) or "the first tape drive" can do
so without worrying about the individual SCSI IDs of the drives.
This is especially helpful during the initial install, where one
doesn't have to pick specific IDs for tape and/or CD, yet the install
software recognizes the drive(s) whichever ID they are set to.

Since I don't always assemble the hardware I install Unix onto, this
facility makes it *far* less likely that I'll have to open the case
in order to install UnixWare -- few hardware vendors give much care to
the IDs at which things are set, 'cause most DOS drivers scan the bus
to finds CDs and tapes too.

--
 Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario

    There are two types of people: those who divide people into two types,
                            and those who don't.