Adding hard drives to an existing SCSI controller - SCO

This is a discussion on Adding hard drives to an existing SCSI controller - SCO ; I'm dealing with an OpenServer 5.0.6 system, which is a new OS for me. I need to add SCSI drives to an existing system, which already has boot drives, and find that the "mkdev hd" utility insists that I know ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Adding hard drives to an existing SCSI controller

  1. Adding hard drives to an existing SCSI controller

    I'm dealing with an OpenServer 5.0.6 system, which is a new OS for me.
    I need to add SCSI drives to an existing system, which already has
    boot drives, and find that the "mkdev hd" utility insists that I know
    a lot of information about the existing hardware, including LUN's and
    other data.

    Is there a graceful way to extract that information from the boot
    logs, or a readable configuration file somewhere? I've gotten spoiled
    by the BSD UNIX style "fdisk -l" command to list the available drives
    on other UNIX or Linux systems. The system has multipls SCSI
    controllers, and I really don't want to have to bring it down to poke
    things manually.

  2. Re: Adding hard drives to an existing SCSI controller

    Nico Kadel-Garcia wrote:
    > I'm dealing with an OpenServer 5.0.6 system, which is a new OS for me.
    > I need to add SCSI drives to an existing system, which already has
    > boot drives, and find that the "mkdev hd" utility insists that I know
    > a lot of information about the existing hardware, including LUN's and
    > other data.
    >
    > Is there a graceful way to extract that information from the boot
    > logs, or a readable configuration file somewhere? I've gotten spoiled
    > by the BSD UNIX style "fdisk -l" command to list the available drives
    > on other UNIX or Linux systems. The system has multipls SCSI
    > controllers, and I really don't want to have to bring it down to poke
    > things manually.


    Adding hard drives is not as simple under SCO as some other *ix's.

    But perhaps you have a RAID controller and 2 or more drives already.

    Then it should be simple to add a drive via the RAID firmware.

    If there's only one disk, or the existing disks are NOT in a RAID
    configuration, try here for a quick tutorial on adding HD's under SCO:

    http://aplawrence.com/Unixart/newdisk.html

    Before you start, make sure you have several backups of the entire SCO
    partition using one of the 'SuperTars' like BackupEdge or Lone-tar
    (www.microlite.com or www.lone-tar.com for full function 60 day demo's).

    Either one has bit level, check-summed backups you can count on and is
    far superior to standard tar or cpio.

    They can also be used to replace the existing disk with a much larger
    one without having to reload the OS from scratch.

    The above advice is in case you wind up confusing the boot disk and new
    disk names and wipe it out using divvy

    Good luck.

    --
    ----------------------------------------------------
    Pat Welch, UBB Computer Services, a WCS Affiliate
    SCO Authorized Partner
    Microlite BackupEdge Certified Reseller
    Unix/Linux/Windows/Hardware Sales/Support
    (209) 745-1401 Cell: (209) 251-9120
    E-mail: patubb@inreach.com
    ----------------------------------------------------

  3. Re: Adding hard drives to an existing SCSI controller


    ----- Original Message -----
    From: "Nico Kadel-Garcia"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Friday, January 25, 2008 7:00 AM
    Subject: Adding hard drives to an existing SCSI controller


    > I'm dealing with an OpenServer 5.0.6 system, which is a new OS for me.
    > I need to add SCSI drives to an existing system, which already has
    > boot drives, and find that the "mkdev hd" utility insists that I know
    > a lot of information about the existing hardware, including LUN's and
    > other data.
    >
    > Is there a graceful way to extract that information from the boot
    > logs, or a readable configuration file somewhere? I've gotten spoiled
    > by the BSD UNIX style "fdisk -l" command to list the available drives
    > on other UNIX or Linux systems. The system has multipls SCSI
    > controllers, and I really don't want to have to bring it down to poke
    > things manually.



    A few different things each give you most of the picture, together they give you all of the picture.

    # grep "type=S " /var/adm/messages |sort -u
    %disk - - - type=S ha=0 id=0 lun=0 bus=1 ht=amird

    %tape - - - type=S ha=0 id=2 lun=0 bus=1 ht=lsil

    This shows:
    On this system there are two scsi adapters actually in use.
    The only disk in this case is on an adapter that uses the "amird" driver.
    The only disk is lun 0, id 0, on bus 1, of "amird" adapter 0.
    (bus = channel)

    This does not show:
    There may be an adapter physically installed, and with the right driver configured into the kernel.
    All such configured adapters do show up in messages, but unless you recognize the names of the drivers a scsi adapters, you might not be able to reliably pick them out of the other adapters. On this system it happens to be easy to eliminate the ide adapter and the rest are scsi.

    # grep "^%adapter " /var/adm/messages |sort -u

    %adapter - 5 - type=amird ha=0 id=7

    %adapter 0x01F0-0x01F7 14 - type=IDE ctlr=primary dvr=wd

    %adapter 0xD400-0xD480 5 0 type=lsil ha=0 id=7 Chip=1030 10328



    Another place shows all the configured scsi adapters and all the configured lun/id/bus/adapter addresses, but does not show which of those are actually used. You may have for example, amird adapter 0, bu 0, ids 0 1 2 3 4, lun 0 all configured in the kernel, but not actually have any disks installed on ids 1 2 3 4. Above shows whats actually in use. Also it's not clear that the "wd" driver is ide, but above shows that.

    cat /etc/conf/cf.d/mscsi

    [...]

    * ha = device name of SCSI host adapter driver e.g. ad

    * attach= device name of attached SCSI device driver e.g. Sdsk

    * number= host adapter number

    * ID = controller number

    * lun = logical unit number

    * bus = host adapter bus number

    *

    *ha attach number ID lun bus

    *

    wd Srom 0 0 0 0

    amird Sdsk 0 0 0 1

    lsil Stp 0 2 0 0



    This shows that :

    Ignore "wd" since we know from further above that this is ide.

    The only configured adapters are amird and lsil

    Shows every adapter number, bus, id, lun that the kernel currently knows how to recognize without relinking. In this case, everything the kernel knows how to address, is actually being used, since we can match everything up with something in the /var/adm/messages output.



    At this point you should know enough to be able to add a new disk onto the amird card, on bus 1 (the 2nd bus, perhaps bus 0 is an external connecter in this case), and use any id other than 0 or 6

    The adapter itself uses 6, which I don't know if you can see that anywhere in software, except via the cards own admin util which differs from card to card, or in the bios setup at boot time. 6 is so standard it's practically a misconfiguration to have it any other way, but just for completeness, in the case of amird, the admin util is /etc/megamgr, is installed with the driver, and has almost exactly the same features and interface as the cards bios setup. In there, in the physical drive view, you can see that id 6 is occupied by the card itself.

    If you have an admin util for the card, then you can see the channels and id's in use that way too of course. For many (most?) plain non-raid scsi cards there may be no admin util. For some an admin util may exist but not be installed because it's not part of the driver installer (adaptec cards and /usr/dpt/raidutil). In at least one case, certain new adaptec cards, a run-time admin util exists, but it's practically useless since it requires java and X, is an interactive gui, and only works at the console. (in theory it can be made to work remotely but I never managed it except by the brute force way of setting up vnc to get remote access to a local X session)

    There is also the command "sconf".

    On a 5.0.7 box it's safe to run "sconf -v"

    I beleive that it's not safe to run sconf manually on any earlier version.

    I'm unsure about 5.0.6 but definitely in earlier versions it can (will always?) crash the box on the spot.

    So, I'd man sconf and then NOT run it unless Bela or someone actually from SCO comes on and says to.

    You can do all of this looking and determining what exists and what's in use perfectly safely while the box is running, but you do have to reboot at least once along the way before a new disk actually works.

    --

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!







    (others may be installed and even have the driver configured into the kernel, I'll show that in a sec)

  4. Re: Adding hard drives to an existing SCSI controller


    ----- Original Message -----
    From: "Brian K. White"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Friday, January 25, 2008 9:55 AM
    Subject: Re: Adding hard drives to an existing SCSI controller



    > This does not show:
    > There may be an adapter physically installed, and with the right driver configured into the kernel.


    I meant to say, it's possible there may be other adapters installed, and configured with drivers, that don't actually have any disks or tapes connected. They wouldn't be shown in that grep. The rest of the post covered seeing for certain every working adapter regardless what is connected to it.

    --
    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  5. Re: Adding hard drives to an existing SCSI controller

    Nico Kadel-Garcia wrote:

    > I'm dealing with an OpenServer 5.0.6 system, which is a new OS for me.
    > I need to add SCSI drives to an existing system, which already has
    > boot drives, and find that the "mkdev hd" utility insists that I know
    > a lot of information about the existing hardware, including LUN's and
    > other data.
    >
    > Is there a graceful way to extract that information from the boot
    > logs, or a readable configuration file somewhere? I've gotten spoiled
    > by the BSD UNIX style "fdisk -l" command to list the available drives
    > on other UNIX or Linux systems. The system has multipls SCSI
    > controllers, and I really don't want to have to bring it down to poke
    > things manually.


    Run `hwconfig -h`. "adapter" lines are your SCSI host adapters:

    adapter 0x2400-0x24ff 5 - type=ad320 ha=0 slot=0 bus=0 id=7 fts=sto
    adapter 0x2c00-0x2cff 10 - type=ad320 ha=1 slot=0 bus=0 id=7 fts=sto
    adapter 0x1f0-0x1f7 14 - type=IDE ctlr=0 dvr=wd
    adapter 0x170-0x177 15 - type=IDE ctlr=1 dvr=wd

    This example shows two Adaptec 320 (79xx, AHA-29320) and the two IDE
    controllers (they show as "wd" with earlier drivers). For the SCSI,
    "id=7" shows that the adapters are using ID 7, which is pretty standard.

    "type=S" lines are SCSI peripherals:

    cd-rom - - - type=S ha=1 id=4 lun=0 bus=0 ht=ad320
    tape - - - type=S ha=1 id=2 lun=0 bus=0 ht=ad320
    tape - - - type=S ha=1 id=3 lun=0 bus=0 ht=ad320
    disk - - - type=S ha=0 id=1 lun=0 bus=0 ht=ad320
    disk - - - type=S ha=0 id=0 lun=0 bus=0 ht=ad320

    Two disks on the 0th ad320, 2 tapes and a CD on the 1st. All the other
    parameters are there.

    In most cases there are man pages for the host adapter drivers, but my
    example system is a bad example -- neither ad320 nor "IDE" show up as
    man pages! `man wd` gives the IDE driver man page, and there's no
    ad320. But almost all others should work. Run `apropos "host adapter"`
    for a nearly complete list of HBA driver man pages. Look at the
    contents of /etc/default/scsihas for a complete list (including any that
    may be missing their man pages).

    >Bela<


+ Reply to Thread