No one really expects your system to remain stagnant. As your company
grows, your computer should be able to grow with it. You can add more
memory or a new printer with little or no changes to the operating
system itself. However, if you need to add something like a hard disk
or CD-ROM drive, the operating system needs to be told about these
changes. Therefore, you need some mechanism to be able to add new
devices. This mechanism is the shell scripts in /usr/lib/mkdev,
collectively referred to as the "mkdev scripts."
(Pronounced "make-dev scripts")
Although their appearance has change between ODT and
OpenServer, what they do functionally has changed little. OpenServer
provides both a graphical and character based program to configure
the hardware. This is the Hardware/Kernel Manager and is functionally
the same as the sysadmsh
in ODT. Despite the outward appearance it is basically the
same as the mkdev scripts. In many cases, just like sysadmsh,
the Hardware/Kernel Manager actually calls the mkdev scripts to
configure the hardware. To make life easier, I will be referring to
the mkdev scripts throughout this discussion. However, since the
scripts are called from sysadmsh
and the Hardware/Kernel Manager, the information still applies.
One thing I need to point out is that these scripts are not just to
add devices. Originally this was the case, hence the name mkdev.
However, as SCO UNIX grew, any addition to the system functionality
was made through mkdev scripts. For example, when you run mkdev
fd, you are not adding a floppy disk to your system, but
rather you are giving the choice of creating a boot or root
filesystem floppy or one with a UNIX filesystem on it. When you run
mkdev mmdf, there is no
MMDF device to be created. Instead, you are configuring MMDF.
However, this is not the only way that devices can get added to the
system. Third Party drivers can do anything they want. Not that they
should, they just can. Even if a driver is installed using custom,
there is nothing that guarantees that this mechanism is used.
As with any device you add to your system, I need to remind you to
have everything planned out before you start. Know what hardware
exists on your machine and what settings each card has. Look at the
documentation to see what settings are possible in case you need to
change them. If you are adding a new device of a particular type, the
odds are you are going to need to make some changes.
On a standard ODT system, there are two dozen different scripts.
Therefore taking about each of them in details would probably take up
this whole chapter, if not the whole book. Therefore, we are going to
talk about the scripts in general and then get to some specifics
about the more commonly used one as we address the issue that can
As I have said before and I will say a hundred time again, before
you start to do anything, prepare yourself. Get everything together
that will be needed prior to starting. Gather the manuals and
diagrams, get your notebook out and have the settings of all the
other cards in front of you. Also, before you start read both the
Release Notes and the chapter on installing in the OpenServer
Perhaps the most important thing to do before you run any
mkdev script is to how the hardware is really configured. I need to
emphasize the word really. Many customers have gotten arrogant
with me, almost to the point of being angry because the insist that
they hardware is set at the "defaults" and I insist that
they check anyway.
Unfortunately for me, in most of the cases the devices are set at the
default. However, confirming this takes less time then trying to get
something installed for a couple of hours and only then finding out
they are not at the default. Therefore, I would insist that the
customer check before we continue. I did have one customer who made
noises like he was checking and "confirmed" the fact that
the device was at the default. After almost an hour of trying to get
it to work, I asked him to change the settings to something other
then the defaults, thinking maybe there was a conflict with some
other device. Well, as you guessed, he didn't need to do anything to
make things non-default, they were already there! Lesson learned:
DON'T lie to tech support.
Another important part of the preparation is to understand what it is
you are trying to accomplish. If you are having trouble with your
modem where it works, but not correctly, then playing around with
mkdev serial (which
configures the serial port) is not what you want to do. If you are
running into trouble getting Merge to work, the problem may lie
elsewhere than the mkdev dos
script (which adds support for DOS filesystems).
One thing I need to point out is that many of these scripts can be
used to reconfigure existing devices as well as remove them.
Therefore, don't just think of these as scripts to add devices.
There are a few sub-directories in /usr/lib/mkdev.
Two of them, oaforms and
oamenus provide the nice
menuing capabilities of certain scripts such as mkdev
lp and mkdev graphics.
The other sub-directory, perms,
contains permissions files similar to those in /etc/perms.
These are accessed when the appropriate devices are added or
The exception is perms/HDLIST.
This is because of the relatively complex nature of the hard disk
minor numbering scheme for the hard disks. We'll get into this in a
little more details when we cover the mkdev
It is a common misunderstanding that the mkdev
scripts do not configure the devices. The configure the
device drivers. This may appear like a subte difference, but
is a very important one. If you were to be configuring the
device, then you could set the interrupt, DMA and base address.
Instead, you are configuring the software to expect the hardware has
a certain configuration. If you run an mkdev
script and tell it that a device has a certain interrupt, then
you must make sure that the hardware in configured the same way.7
One of the most important things about installing hardware is knowing
what you are doing. Now this may seem like an overly obvious thing to
say, but there is a lot more to installing software than people
One of the most common problems I see is that cards are simply
snapped into the bus slot with the expectation that whatever settings
are made at the factory must be correct. This is true in many, if not
most cases. Unless you have multiple boards of the same type (not
necessarily the same manufacturer), you can usually get away with
leaving the board at the default. However, what is the
Unless you are buying your hardware second hand, there ought to be
some kind of documentation or manual that come with it. For some,
like hard disks, this may only be a single sheet. Others, like my
host adapter come with booklets of 50 pages or more. These not only
give you the default settings, but tell you how to check as well as
change the settings.
On ISA cards, settings are changed by either switches or
jumpers. Switches, also called DIP-Switches come in several
varieties. Piano switches, look just like piano keys and can be
pressed down or popped up. Slide switches move back an forth to
adjust the settings. In most cases the switches are labeled in one of
three ways: on-off, 0-1 and closed-open. Do not assume that on, open
or 1 means that a particular functionality is active. Sometimes 'on'
means to turn on disabling the function. Always check the
documentation to be sure.
Jumpers are clips that slide over pairs of metal posts to make an
electrical connection. In most cases, the posts are fairly thin
(about the size of a sewing needle) and usually come in rows of pin
pairs. Since you need both posts to make a connection, it is okay to
store unused jumpers by connecting them to just one of the posts. You
change the setting by moving the jumper from one pair of pins to
The most common things that they configure are base address, IRQ and
DMA. However, they sometimes are used to enable or disable certain
functionality. For example, jumpers are often used to determine
whether an IDE hard disk is the master or the slave.
The other three bus types, MCA, EISA, and PCI bus cards do not have
DIP switches or jumpers. They normally come with some kind of
configuration information provided on a diskette. Provided with the
machine itself is a configuration program that reads the information
from the diskettes and helps to ensure that there are no conflicts.
Although hardware settings are configured through these programs, it
is still possible in some cases to create conflicts yourself, but the
configuration utility will warn you.
Sometimes the configuration utility is provided on a separate
floppy. Usually this is a DOS floppy, but is not bootable. Therefore,
you will need to first boot off a DOS floppy before you can configure
the card. MCA machines have a bootable configuration disk that
contains the configuration information for the hardware provided with
the machine If this is the case, then this disk is as important as
the SCO UNIX installation media. If this disk gets trashed, then
there is no way you will even be able to add another piece of
hardware, your kids will hate you and your co-workers will think you
are a geek. On the other hard, you could get a copy from the
manufacturer, but that's a hassle. The real problem is that some
machines, like the IBM PS/2 series, recognize when you add a new card
to the system and won't let you boot until you feed it the
In some cases, the configuration program is part of the hardware
(BIOS) or resides in a normally inaccessible part of the hard disk.
Check the machine documentation for details.
Knowing what kind of card you have is not only important to
configure the card, but unless you know what kind of bus type you
have, you may not be able to even stick it in the machine. This is
because all of the different cards have a different size or shape. As
you would guess, the slots on the motherboard they go into also have
different sizes and shapes.
Hopefully, you knew what kind of card to buy before you bought it.
However, it is often the case where an administrator will know what
kind of slots are on the machine from reading the documentation, but
never opened the case up so has no idea what the slots look like. If
this is a pure ISA or MCA machine, then this is not a problem as none
of the cards for any other bus will fit into one of these slots.
Problems arise when you have mixed bus types. For example, it is very
common today to have PCI or VLB included with ISA or EISA. I have
also seen MCA machines with PCI slots, as well as both PCI and
VLB in addition to the primary bus (usually ISA or EISA). If you've
gotten confused reading this, image what will happen when you try to
install one of these cards.
More than likely you are using your SCO machine as a server.
Therefore, the computer you bought probably has at least six slots in
it. This can be more if you have a tower case or have PCI in addition
to the primary bus. Due to their distinct size and shape, it is
difficult to get cards into slots where they don't belong. Usually
there is some mechanism (i.e. notches in the card) that prevent you
from sticking them in the wrong slots.
On some motherboards you will find a PCI slot right next to an ISA or
EISA slot. By "right next to" I mean that the seperation
between the PCI slot and the other is much less than between slots of
the same type. This is to prevent you from using both slots. Note
that the PCI electronics are on the opposite side of the board from
ISA and EISA. Therefore, it's impossible to fill one slot and then
use the other.
When installing the expansion cards, you need to make sure
that the computer is disconnected from all power supplies. The safest
thing is to shutdown the system and then pull the plug from the wall
socket. That way you ensure that no power is getting to the bus, even
if it is turned off. Although the likelihood of you injuring yourself
seriously is low, you have a greater chance of frying some component
of your motherboard or expansion card.
Another suggestion is to ground yourself before touching any of the
electronic components. You can do this by either touching a grounded
metal object (other than the computer itself) or wearing a grounding
strap. These usually come with a small instruction sheet telling
where the best place to connect it is.
When I first started in SCO Support we had a machine that
would reboot itself if someone so much as touched it who wasn't
grounded. I have also cleared my CMOS a couple of times myself.
Therefore, I can speak from experience when I say how important this
When you open the case you will see a row of bus card slots, lined up
in parallel. Near the outside/back end of the slot, there is a
backing plate that is probably attached to the computer frame by a
single screw. Since in most cases, there is some connector, etc that
sticks out of the slot, this plate will probably have to be removed.
In addition, the card will have an attachment similar to the backing
plate that is used to hold the card in place. I have seen cards that
do not have any external connector, so you could insert them without
first removing the backing plate. However, they are not secure as
nothing is holding them in place.
This plate has a lip a the top with the hole for the screw. In order
to get the orientation right for the screw hole, the card will
probably be inserted correctly. (Provided it is in the right kind of
slot) As you are inserting the card into the slot, make sure that is
going in completely perpendicular to motherboard. That is, make sure
that both ends are going into the slot evenly and that the card is
not tilted. Be careful not to push to hard, but also keep in mind
that the card must "snap" into place. Once the card is
seated properly in the slot, you can make the necessary cable
connection to the card.
After the cables are connected, your machine can be rebooted. Many
people recommend first closing the computer's case before turning on
the power switch. Experience has taught me to first reboot the
machine and test the card first, before putting the case back on. If,
on the other hand, you know you have done everything
correctly, the go ahead and close things up.
SCO UNIX provides a couple of utilities that can be used to check
what you have installed if you are running either EISA or MCA. If you
have an EISA system, use the eisa(ADM)
utility. The one drawback is that this can only show you what EISA
cards you have installed. This is because ISA cards have no way of
communicating with the bus the same way EISA can. If you have an MCA
machine, you use the slot(ADM)
command. Note that both of these commands can only view the
configuration and not change it. To change it you need to run the
appropriate configuration program.
Avoiding address, interrupt and DMA conflicts is often difficult. If
your system consists solely of non-ISA cards, then it is easy to use
the configuration utilities to do the work for you. However, the
moment you add an ISA card, then you must look at the card
specifically to see how it is configured and to avoid and conflicts
If you have ISA and PCI cards, you can use the PCI setup program to
tell you which interrupts are in use by ISA bus cards. If you don't,
then it is possible that there will be interrupt conflicts between
ISA bus card and a PCI bus card, or even two ISA cards.
Unlike DOS, every expansion card that you add to an SCO system
requires a driver. Many, such as those for IDE hard disks, are
already configured in your system. Even if the driver for a new piece
of hardware exists on your system, it may nor be linked into your
kernel. Therefore, the piece of hardware it controls is inaccessible.
There isn't too much you can say about adding CPU's. There is no
mkdev script to run. There are no jumpers to set on the CPU. In some
newer machines, there is a level that pops out the old CPU and you
pop in a new one. This is (as far as I have seen) only on 486 machine
to allow you to add a Pentium. These are called Zero-Insertion-Force
(ZIF) socket, since you use the lever is used to lock the CPU into
place and it requires zero force to insert it.
One thing that needs to be considered is the speed of the CPU. You
may want to increase the speed of the CPU, by simply buying a faster
one. From SCO's perspective this is okay. You plug it in, and it can
work with it. However, it might not be from the hardware's
perspective. Motherboards are often sold with the same speed as the
CPU. This is because they cannot handle faster speeds. Therefore, in
many cases you cannot simple replace the CPU with a faster one.
In other cases, the motherboard is of higher quality and can handle
even the fastest Pentium. However, if you only had a 50Mhz 486, then
you might have to change jumpers to accommodate the slower CPU. Often
these changes effect such things as the memory waits states. Here you
need to check the motherboard documentation.
The day with probably come when you need to expand the RAM on your
system. As more users are added and they do more work, the little RAM
you have won't be enough. Once you have decided that you need more
RAM, you still have most of your work ahead of you.
One of the key issues is the kind of RAM. In almost all newer
machines, RAM comes in the form of SIMM modules. As I mentioned in
chapter 12, these are about the size of a stick of chewing gun, with
the chips mounted directly on the cards. These have almost entirely
replaced the old RAM that was composed on individual chips.
There are two primary type of SIMMs. The somewhat larger is called a
PS/2 SIMM as it was first used on PS/2 machines. This has 72
connectors on it and can be immediately distinguished by the small
notch in the. The other kind is referred to as non-PS/2, normal,
regular, etc. This has 30-pins and no notch. There is also a 32-pin
SIMM. However, this is uncommon. I have never seen one, but was told
of this by someone who works in the chip manufacturing business.
Two important aspects of RAM is the speed and whether or not it has
parity. The speed of RAM is measured in nano-seconds(ns). Most RAM
today is either 70 or 60ns, with a few machines still being sold with
80ns. The speed of RAM is a measure of how quickly you can read a
particular memory location.
Although it is possible in many cases to mix RAM speeds, I
advise against this. First, memory can only be accessed as quickly as
the slowest chip. Therefore, you can nothing by adding faster RAM,
and loose if you add slower RAM. I have also seen machines where
mixing speeds actually causes problems. Since the difference between
80ns and 70ns is more than 10%, the delay waiting for the slower
(80ns) RAM makes the system think that there is a problem. This
usually results in kernel panics.
Another issue is the motherboard design. For example, on my machine,
I have two banks of memory with four slots each. Because of the way
the memory access logic is designed, I must fill a bank completely,
otherwise, nothing in that bank with be recognized. On other
machines, you can add single SIMMs. Check the documentation that came
with the motherboard.
Another important issue is the fact that SCO UNIX uses only extended
not expanded memory. Expanded memory dates back to the early days
when the XT bus could only handle up to 1MB of RAM. In order to give
programs access to more memory than the computer could handle, some
memory board manufacturers came up with the concept of "bank
switching". With bank switching, a 64K area between 640K and 1Mb
is reserved and then portions above 1Mb are "switched" in
to this reserved block as needed.
When the AT bus was developed, it could access more memory. However
to make it compatible with older peripherals, the area between 640K
to 1MB was left "unused". You often see this when SCO UNIX
boots that it doesn't use that area. Memory beyond 1MB is known as
Some machines have a hardware limitation on the maximum amount of
memory that can be installed. Since I use 30-pin SIMMs, the largest
available (as of this writing) is 4Mb. Because of this, I max out at
32 MB when I fill all eight of my slots. If you have 72-pin memory,
there are larger modules, such as 8, 16 and even 64Mb. Again refer to
you motherboard manual for details. Currently, OpenServer officially
supports up to 512MB of main memory. However, I was told there is a
machine at SCO running with 1Gb. I was also told that OpenServer
should support up to 2Gb.
If you experience repeated panics with parity errors, consider
replacing your memory. Because of the way memory is accessed you may
have to remove or replace entire banks (like mine). I have also seen
cases where mixing memory types and speeds can cause the panics. For
example, if you have a machine that "allows" both 4MB and
1MB SIMMs, the demands that SCO puts on the machine may be too much
and it panics. However, running the same configuration with Windows
works fine. The panics may also be the result of improperly inserted
SIMMs. That is, if the SIMM is loose, it may not make a good contact
with the slot. If the machine gets jarred, the contact may be lost.
In some cases you can simply add the memory and the machine will
recognize it (like mine). However, I have some machines where you
have to set jumpers to enable each bank as you add memory. In other
cases, where you have filled up all the slots on the motherboard, you
can add a memory expansion card. If this is on a machine like a PS/2,
it requires you to tell the system of the memory expansion card using
the configuration disk.
If this is the first device you are adding to the host adapter, you
need to configure that host adapter into the system. You will then be
prompted for such information as IRQ and base address. If you have
either a PCI or EISA machine, you won't be prompted for these values
as these are configured into the CMOS by the appropriate
configuration utility and they are then read by the driver at boot
If you are adding a second (or anything after that) host adapter you
will have to disable the BIOS on it. Remember from our discussion on
SCSI in the chapter on hardware, that the system will look for a
bootable hard disk. If the BIOS on the second host adapter is
enabled, the system may try to boot from this one. If it is the same
model host adapter, then it will probably have to change the base
address, IRQ and DMA, as well.
Remember that every device on the SCSI bus, including the host
adapter itself, is identified by a SCSI ID. SCSI IDs range from 0-7
on standard SCSI and 0-15 on a Wide-SCSI bus. Regardless of what
type, the host adapter is almost exclusively set to ID 7. It is this
ID that is used to identify devices on the bus, not their location in
relation to the host adapter.
Since there is no real need to have a SCSI host adapter configured
unless something is attached, the only "official" way to
add a host adapter to the system is to go through the procedures to
add one of the attached devices. If the system recognizes that you do
not have a configured host adapter, you will be prompted to add one.
If you are adding a device to an existing host adapter, then the
driver for that host adapter is already linked into the kernel. (At
least we hope so) You only need to make the kernel aware of the new
device. Each device gets an entry in /etc/conf/cf.d/mscsi.
This tells the system what host adapter type the device is
attached to, what kind of device it is, which host adapter number it
is attached to, the ID, LUN, and bus number for every device on
every SCSI bus. The nice things about the installation is that you
don't have to worry about editing the mscsi
file yourself. All you have to do is supply the correct information
and the installation programs will add this for you.
One change that was made in OpenServer was adding an extra
column to mscsi. This is
for SCSI host adapters that provide two channels. The new column in
mscsi (the sixth one) is
for the channel. If the device is on the second channel, this entry
will be a 1. If the device is on the first channel or the adapter
isn't support twin-channel, then this entry is 0. If the entry is
missing, the system assumes it is 0.
When you run either the Hardware/Kernel Manager or one of the mkdev
scripts, the first thing you are asked it what host adapter 'type'.
Here you need to put in the internal name of the device driver. The
default will be either an Adaptec 154x if this is the first one you
are installing or the last host adapter you installed. If you don't
know you can get a list of the available one either by looking in
entering 'h' when you are asked for the type (It says to do this on
Next, you are asked what host adapter number. Since you can
only have two of any kind, you are given the choice of either 0 for
the first or 1 for the second host adapter.Open Server also supports
twin channel SCSI host adapters. You are, therefore, asked which
channel the device is one. If you have a host adapter with only one
channel, enter 0 as the channel.
Be careful here. Some host adapters label their channels A and B,
rather than 0 and 1. Since both A and 0 come first, these are the
same channel. That makes B and 1 the same channel. Although does seem
logical, unless someone specifically tells you, you are still
You are next asked the ID of the device. Remember that the ID is not
the position on the SCSI bus, but is something that you need to
explictely set. Make sure that the ID you are inputting to the mkdev
script is correct. Just like base addresses, IRQs and everything
else, this has to match. The problem is that determing the ID is not
always easy. Remember from our discussion on SCSI device in chapter
12. You might have jumpers or switches that can have several
different labels. Unless you have used this model of device before,
you will probably need to double-check the doc to be sure. (Checking
the doc is always a good idea.)
The last question is the logical unit number (LUN) of the device.
Currently, SCO doies not support any device that is set to something
other than LUN 0. This is not to say that it won't work.. It's simply
an issue of all devices that SCO supports directly have embedded
controllers so they can only be set to LUN 0.
If the root disk is IDE, EIDE or ESDI, then you can add another disk
of that type or add a SCSI disk. (assuming you have a SCSI host
adapter) Keep in mind that the number of disks is limited by The
MAX_DISK dynamic kernel parameter. If set to 0, the maximum number is
Some host adapters, like the Adaptec AHA1510 do not have a BIOS.
Therefore, you cannot install onto a disk connected to this adapter.
This can be used only as a secondary adapter. There are dozens of
host adapters supported by SCO, with more being added to each
release. Each has certain characteristics that need to be addresses.
If there are known problems with a specific host adapter it will be
listed in the Release Notes or in the Open Server Handbook.
One of the most commonly used and often messed up scripts is the one
to add hard disks to your system: mkdev
hd. The reason that the mkdev
script is so often messed up is that people are not prepared when
they start. They do not know the current configuration on their
system. As a result they often guess when running this script. What
then happens is that the system flails and dies during the next
reboot because it is looking for things that are not there.
Since the mkdev hd script
is only called after the system itself is installed and you are
adding a new disk, there is a better chance that you know what kind
of disk. However, this is not always the case. I have talked with
customers who are the software consultants and have technicians add
the hardware. In some cases they don't even know what kind of hard
disk they are installing.
If you have trouble figuring out what kind of hard disk you have,
either refer to the documentation that came with the drive, call the
vendor or re-read the section at the beginning of the book on hard
The key thing to keep in mind is making sure how the disk is
configured. Every drive should come with some kind of documentation.
Either a detailed, multi-page manual as is the case with many SCSI
drives, or a single sheet, a is common with IDE drives. This usually
contains information about the default settings of the drive. Don't
trust them. Check out the settings yourself to ensure they are
correct before you stick the drive in the machine. It is easier to
check beforehand than it is after your tried to install it and
If it's an IDE drive, then one of the key issues is whether it is the
master or slave. If you are adding a second drive to a system that
only has one drive, then you are obviously adding the slave. If you
already have two drives on the first IDE controller and this is the
first one on the second controller. then it is the master.
Another key issue is making sure the cabling is right. In the
section on hard disks earlier, I mentioned that the position on the
cable is irrelevant for IDE drives; the jumpers determine which
drive is which. A problem often crops up when connecting the cable to
the drive itself.
Usually there is a small "key" on the connector on the
cable which fits into a notch on the drive-side connector. If the
"key" is missing or the drive-side connector is wide
enough, it may be possible to fit the connectors together backwards.
Fortunately, you don't have to resort to "trial and error"
to figure out which is which. On one side of the cable, there will be
a colored stripe (usually red). This is line 1 of the 40-line IDE
cable. In fact, on almost all ribbon cables, line 1 is marked red.
On the drive side, things are a little more complicated. The IDE
cable has 40 parallel lines, but the connectors (both on the cable
and on the drive) are in two parallel rows. Usually the connector on
the drive is either male (pins) or there is a small "card"
sticking out that is similar to an expansion card. These alternate
with the odd numbered lines on one side and the even numbered lines
on the other.
On the drive near the connector, often on the circuit board itself
will be some small numbers. These tell you which pin is which.
Sometimes there will be a 1 and 2 on one end with 39 and 40 on the
other. Other times there will be just a 1 and 39. (I have seen cases
where there is just a 2 and 40).
SCSI drives may have jumpers to configure them, but they may also be
configured in other ways such as with dials, dip switches, or piano
switches. Like IDE drives, SCSI usually has one set of jumpers. This
will be for the SCSI ID of the drive. In some cases there will be up
to eight pairs of pins to indicate which SCSI ID. Others have three
pins that operate in binary. (For more details on SCSI configuration,
see the section on SCSI in the hardware chapter.)
Standard SCSI cable looks very similar to the IDE, except that the
cable has 50 lines instead of just 40. However, the same issues with
the key and slot, as well as the number applies. On the other hand, I
can't remember seeing a SCSI device where the key and slot didn't
match up correctly.
If you are not sure of how the drive is configured, check the
documentation that came with your drive. If that can't be found, most
hard disk manufacturers have fax services that will fax you
installation information on any drive they have.
The first thing the mkdev hd
script does is to check your root hard disk. This is important
because you cannot have both a SCSI and IDE drive in your system and
boot from the SCSI. Therefore, if you system only has SCSI drives and
you run this script, you are only given the option to add another
SCSI hard disk. (I talked about the reasons for this in the section
on SCSI in the chapter on hardware)
Well, this is not entirely true. If you are running OpenServer 5.0,
then you are given a menu option to add an IDE drive. You can start
it and it will go through like it is trying to add the hard disk,
but it eventually errors out. To me, this is a bug.
The mkdev hd script
accesses the functions to determine the hard disk type through two
another scripts: /usr/lib/sh/std_funcs
The script std_funcs
contains several standard functions that provide interfaces for user
input and output. This script contains some interesting functions,
but unfortunately that is not the topic of this section. However, I
would recommend looking at it as it not only because it has some
useful functions, but uses some interesting tricks of the shell.
The other script, .hdfuncs,
contains hard disk functions (what else?). This is where most of the
actual work gets done when adding a hard disk. Should you be adding a
SCSI hard disk, the .hdfuncs
calls another script
One of the first things the mkdev
hd scripts does it
to check for the architecture type. Actually this isn't quite true.
The system simply asks "Am I MCA?" If not, it doesn't care
if it's ISA or EISA, just that it's not MCA. This is very important
as the drivers are very different between MCA and AT architectures.
Whereas, ISA devices work fine in EISA machines.
Just after this, the system checks for the existence of the link
kit. This is a very important step. Without the link kit, none of the
necessary drivers are on the system and you won't be able to add
anything. The nice thing is that if the system determines that the
link kit is not installed, you are asked if you want to install it.
Next we get to see where one of our esoteric devices finally comes of
use: /dev/string/cfg. The
.hdfuncs script uses it to
find out what the boot hard disk type is. This is because, as I
mentioned before, you can't have both SCSI and non-SCSI and boot from
the SCSI. If .hdfuncs
finds that your boot hard disk is SCSI. It will only allow you to add
another SCSI. If this is the case, it actually runs the .scsi
Here you are ask about the host adapter and how the drive is
configured. This is where is become essential that you know your
hardware configuration. The script makes some suggestion about what
the values are based on what it can determine, however these are not
always the correct values to input.
For example, one of the things it suggests is the prefix of the host
adapter you are adding. It firsts checks
/etc/conf/cf.d/mscsi and uses the last host adapter prefix it
finds. This makes sense because if you are adding a SCSI device, then
most likely it will be to the same host adapter as the last device
If there are no entries in mscsi,
it looks for a boot device. This is also obtained through
makes sense because in most cases you are adding a SCSI device to an
existing host adapter and there are no entries in mscsi,
you probably want to add it to the boot host adapter.
This is a place where people run into problems. They simple
don't know what to input there. They were given installation
instructions for the hardware, but the hardware vendor may not
provide instructions for UNIX. In most cases it is safe to take the
default. However, be safe! Know what you have. The same also applies
to the SCSI ID and LUN. If you don't know, don't guess. If you know
you are adding a new host adapter, .scsi
will prompt you for information about this host adapter to be able to
configure it into the kernel.
Once the script decides that your input is a valid device one of two
things will happen. If the hard disk is brand new and the system has
never accessed it before, you will have to relink the kernel, reboot
and run mkdev hd again
before you can access the drive to make the partitions. The reason
for this is that the first time you run mkdev
hd, the kernel is configured to recognize the drive. It is not
until you reboot that the system recognizes the drive and is able to
access it. Only then can you partition the disk and make filesystems.
Remember that the second time you run mkdev
hd, you must use the exact same values.
The second time you run mkdev
hd, you are brought into fdisk
to partition the drive. The fdisk
utility is used to create UNIX partitions. You can define up to four
partitions, which can be no larger than 2TB (2 terabytes) or the
maximum size of the disk, which ever is smaller. Keep in mind that
filesystems are limited to smaller sizes, you may not be able to
create a partition that is the full size of the disk, then create
only a single filesystem. Also, if this disk was already use and the
partition table is still valid, you could simple quite out of fdisk
without changing any of the values.
I need to emphasize something here. On ODT, there must be at least
one active UNIX partition for mkdev
hd to work properly. For those of you with a little experience
know that if there is only one partition, the system automatically
makes it active. So if it's a new drive and you are using the entire
disk for UNIX, there is no problem. Also, if you are adding a UNIX
partition to a hard disk which already has a DOS partition, this is
also no problem, as you can simply make the UNIX partition active.
However, what do you do if the entire disk is used for DOS and
you want to be able to access it, let's say, through Merge? Ah,
therein lies the rub. The .hdfuncs
script will not allow you to continue if there is no active UNIX
partition. Yes, you can quit out of the mkdev process, however, the
system has trapped the interrupt key. If you quit, all the device
node information is deleted and you are back to where you started.
The solution to this is not really what we're here to talk about. You
will either have to edit mkdev
fd or add the nodes
by hand. Fortunately, OpenServer allows you to add a DOS-only disk.
In the mkdev hd script,
each of the device names has to be created as the hard disk is added.
There a literally dozens of names that need to get created. For SCSI
devices, these names are based on the order drives get installed and
not necessarily the order they appear on the bus. Therefore the
devices cannot be created in advance or put in a file like the other
devices. These must be created when the script is run.
During this process a "seed" value is calculated, based on
which the remaining minor numbers are calculated. This "seed"
value is one of those multiples of 64 that are used for each hard
disk. Remember from our discussion of major and minor numbers? The
first hard disk has major numbers between 0-63, the second between
64-127, etc. The first number in the range (i.e. 0, 64, 128, or 192)
is the lowest value that the minor number can be for any device on
this hard disk. This is the "seed" value and is simply
added to the minor number calculated for each device for the hard
If there are already four hard disks on the system, then the seed
number will be at least 256. Remember from our discussion of major
and minor numbers. Each is stored in a single byte. Therefore, it is
impossible to have minor number above 255, therefore you can't have
more than four hard disks on a system, right?
Well, several years ago this was true. Four hard disks on a system
was considered to be quite a lot. Therefore, it did not bother the
"powers-that-be" too much that there was this limitation.
As databases grew into the gigabyte range, four hard disk was no
longer "a lot." Especially considering that a SCSI bus
could handle six per host adapter, this limitation was becoming a bit
annoying. Something had to be done to address this issue. That
something was extended minor numbers.
Well, if you want to find out more about extended minor numbers, read
the section on major and minor numbers. If you're already read the
section, then you understand what we're taking about.
If the mkdev hd script has
determined that the seed value is greater than 255, it gets a new
major number that is then used for the extended minor numbers.
After completing fdisk,
divvy is called, which is
used to create divisions and filesystems on those divisions. By
default one filesystem is create on the active partition that you
just made. However, you are asked if you want to make any changes.
Even if you don't want to make changes, it's a good idea to say that
you do. This way you are brought into an interactive session of
divvy and you can see if
things look reasonable. I also find it useful to checks for typoes
that I might have made when inputting the values. In addition, you
can name the filesystem that's created. Otherwise you end up with
some weird name. You then can exit divvy
and the filesystem is created.
You need to be very careful here if this was disk that you had used
before. For example, you updated the OS or had to reinstall after a
system crash. Although you are brought into divvy, you don't have
to change anything. However, there are probably no devices nodes for
these filesystems, so you will probably at least have to name them.
If you want to keep the data, don't create the filesystems.
Creating the filesystem clears out the inode table, making your data
is used to create the filesystem on the divisions, the mkdev
hd process does not actually make the filesystem readily
available. You do have the names of the device nodes as well as the
name(s) of the filesystem(s). Therefore, every time you boot you
could run the mount command
by hand to add the filesystem(s). This is obnoxious, but you could do
A better alternative would be to have the system mount the
filesystem(s) automatically. (Assuming this is what you wanted) This
is done through another mkdev script
This is one of the script where you are not actually "making"
any devices. However, you are adding some functionality to your
system. During the course of this script you are prompted for the
device name of the filesystem (this is the name you input in divvy)
and the name of the directory of where you want to mount the
filesystem. By convention this is the same as the name of the
filesystem, however there is nothing that prevents you from naming it
At this point you see a message the says:
Reserving slots in lost+found directory ...
Here, the system is creating 62 files and removing them. Why? Think
back to the discussion of filesystem in chapter 6.
Next, you are asked for the manner in which is should be mounted
(never, always or prompt). The convention is to always mount it,
which kind of makes sense. Why go through all that trouble to add a
filesystem if you never want to access it? If there are conditions at
your site where you might want to not mount it, then choose one of
the other options.
Finally, you are asked whether users should be able to mount
this filesystem. Be careful. If you say "yes", then every
user has the power to do so. Although they may not have access to
files underneath the mount point, anyone can still mount it. It is
useful if you have a user whose sole function is to do backups, so
having the ability to mount filesystems is very useful. However, if
the user cannot read the file, it can't be backed-up. If you give
them root authority to back everything up, then they don't need to be
able to mount the filesystem as a user.
Another commonly used script is mkdev
fd, for "make device floppy." Again, this is another
case where no device is actually created. This script creates
floppies that can be used in emergencies to boot your system.
You are prompted to input the type of floppy you want to use as well
as whether you want to use either drive 0 or drive 1. If you are
creating a filesystem floppy (the next prompt asks what kind of
floppy you are creating), then there is no problem in using drive 1.
However, if you are creating boot floppy, this must be drive 0. Also,
you need to know the kind of floppy drive you have. If you chose the
wrong kind (size or density), the script fails.
After you chose the floppy drive, you are given the choice of what
kind of floppy you want to create. A filesystem floppy, is essential
empty. It contains the filesystem structure that a filesystem on the
hard disk does. However, since it is accessing a smaller space there
are few inodes so the inode table is smaller. Like a newly created
filesystem on the hard disk, this one is empty.
The other two type are usually created in pairs and as a pair are
often referred to as a boot/root floppy set. A boot floppy is exactly
what it sounds like. It contains the necessary information to boot
and load the kernel. A root filesystem floppy contains a filesystem
as well as the file necessary to get the system going into
maintenance mode. In addition, it contains utilities that can be used
to recovery from a crash and restore your data. To see what files are
copied onto the floppy, take a look at /usr/lib/mkdev/perms/FD.
It is advisable, recommended, suggested, desirable, etc that you
create a boot/root floppy set every time you add or delete drivers
that effect either the hard disk or tape drive. These are the most
important drivers and devices you have for crash recovery. When you
system goes down and you can't access it through the boot/root
floppy, then you only alternative is to reinstall.
Just like mkdev hd and
mkdev fs come in pairs, so
do mkdev cdrom and mkdev
high-sierra. Just like the first pair, you do not absolutely
need to add a high-sierra filesystem to be able to access the CD-ROM.
If you remember from our discussion on the
/dev directory there is such a thing as a cd-tape device.
Since you are not actually mounting the device, there is no need to
add a filesystem driver for it. Additionally, if you have a UNIX
Filesystem CD, then the filesystem driver is already installed.
If you are adding a SCSI CD-ROM, then it must be attached to a
supported host adapter to be able to use the configuration utilities.
Although you may find a third party driver, you will once again run
into the question of who is going to support it.
Open Server allows a maximum of 255 CD-ROM drivers per system. How
many are possible on each host adapter is only limited by the host
adapter itself. For example, you can only have 7 on a SCSI-1 host
adapter, but 15 on a Wide-SCSI-2. If this is the first CD-ROM you are
installing on the system, you are also prompted to add support for
the High-Sierra filesystem. This is the format that DOS CD-ROMs use,
so you must install the high-sierra filesystem if you want to access
Generally, adding floptical drives is the same for any other SCSI
device. You need to ensure that there are no conflicts and that the
hardware settings match what you tell the system they are. Here, too,
you are limited to the number of devices that the SCSI bus supports.
Although there is a wide range of hard disks that are support in
either ODT or Open Server, the combinations that you can add are not
that wide. Here I am not referring to either manufacturers of sizes,
but rather the type of hard disk, such as IDE or SCSI. One problem is
mixing SCSI and non-SCSI hard disks. Personal preference says not
to. It is annoying. You are also limited by the fact that if you have
already installed the system on a SCSI disk, then you cannot later
add a non-SCSI disk.
The thing to note is that the high-sierra (also known as ISO-9660) is
the same type as DOS and Windows use. Therefore, don't think that
just because you added DOS functionality to your system, you will be
able to access a "DOS" CD-ROM. The new Rockridge
filesystem supported in OpenServer is an extension of the high-sierra
filesystem in that is supports version numbers and long filenames.
There are two nice things about the mkdev
cdrom script. First, it gives you the option of adding a
standard CD-ROM or a cd-tape drive. Therefore, you can save a little
space in your kernel if you need to by only adding what you need. The
second nice thing is that if you are adding a standard CD-ROM, you
are ask if you want to add the high-sierra filesystem. Now, there is
a mkdev scrip to add the high-sierra, which mkdev
cdrom calls. However, it's nice to have things done for us.
Wouldn't you say?
Like hard disk, if you are adding a CD-ROM and there is not already a
SCSI device on your system, the kernel will need to be configured for
the host adapter. Also, if you are adding it to a second host
adapter, you will need to configure that as well.
If you are a good little system administrator then you have already
bought yourself a tape drive and have configured it into your system.
Therefore, I don't need to talk about adding one. On the other hand,
there may come a time when the tape drive you have is not sufficient
for you needs and you have to add a new one. As you would guess, the
script to do this is mkdev tape.
Before you begin to install the tape drive be sure to have read your
tape drive hardware manual. This will often contain information about
the physical installation of the device as well as configuration.
Whenever, I think about installing tape drives, I think of the first
SCSI tape drive I had. There were three jumpers to set the SCSI ID.
It didn't make sense that you could only set it to ID 0, 1 or 2. Had
I read the manual first, I would have known that this was the binary
representation of the number.
As you expected, the values have to be correct for the device to
work. You need to know the type of controller you have, the base
address, IRQ and DMA. Note that for the DMA channel, you only have an
option of 3 or 5 when running mkdev
tape. If the tape drive you are adding has it's own controller
card, then the base address, IRQ and DMA channel are configured on
ISA machines with jumpers or switches. Non-ISA cards can probably be
configured via the configuration utilities.
If you remember our discussion on device nodes, you know there are
several different kinds of tape drives. A standard cartridge tape,
also referred to as a QIC-02 is a about the size of a Betamax video
tape. For the younger readers, this is a little smaller than a VHS
tape. (Or twice the size of a music cassette) This kind of tape is
installed using the Cartridge Tape Drive option. You can either
configure this tape drive for auto-configuration or you can input the
There are a couple of things that things that can go wrong when
installing a QIC-02 tape drive. The most common is that it simply
does not show up at boot. Instead of the standard configuration
string, you get a NOTICE that says the tape controller was not found.
This is usually the result of the base address configured in the
mkdev script not matching the hardware. However, I had one customer
who was having a terrible time configuring a QIC-02. He had removed
it and reinstalled it several times, with no success. He was sure
that the parameters were correct, because he had used the same tape
drive in another machine. Normally, there is no problem with
switching QIC-02 tape drives from one machine to another, provided
you move the controller card and not just the tape drive. Needless to
say, the tape drive work fine when he installed the card. (What he
had done was to simply move the tape drive over to the new machine
and plugged power into it.)
As with any piece of hardware, make sure the controller is seated
properly. You may also have to try a different slot. Maybe the slot
is bad. Maybe something else. The first machine that I got when I was
in support that I could install UNIX on was a "hand-me-down."
The longer you worked there, the more likely you were to get a newer
machine. Conversely, the newbie got the hand-me-downs. The one I got,
(datrat, as the previous owner had christened) was very sensitive.
There was only one QIC-02 controller card in the department that work
in my machine. It only worked with one tape drive and in only one
slot. Other people could used any combination of drive, card and
slot. Not me. One Drive. One Card. One Slot.
If the drive is recognized at boot, but hangs when you issue tape
commands, makes sure that the DMA and IRQ are correct. Another
possible problem is that the controller card is in the slot, but the
drive is not connected to the controller. If the tape drive is
external, then it probably has to be powered up at boot time to be
recognized. An incorrect IRQ can also result in the message:
Another possibility is
that the device node as become corrupted. If it's a QIC-02, tape
drive, the device node should look like this:
1 root root 10, 0 Feb 14 12:00 rct0
If not, try removing
then reinstalling the tape drive.
The second option is for a Mini-Cartridge. This option is used to
install Irwin tape drives only. The tape for this kind of drive are
about the size of a cigarette pack. The drives are hooked up to the
floppy controller. Mini-tape drives may use the floppy disk drive
controller. Some Irwins will have their own controller. Irwin mini
tape drivers differ from others in that they are not configurable and
therefore do not require you to enter any parameters when you are
installing it. However, you must ensure that the tape drive is set to
The third option in mkdev
tape is for QIC-40/QIC-80 tape drives. The cartridges are the
same size as for an Irwin. If you are installing a non-Irwin mini,
there are a couple of things to be careful of. First, the
installation mkdev script is the QIC-40/80 script, not the mini
cartridge. This is for Irwins only. Although the tapes are physically
the same, Irwin tape drives require a different driver.
You are prompted to select whether you are installing a QIC-40 or
QIC-80 drive. Also you select whether to enable extended length
tapes. Not all tape drives support this. Therefore, you must be sure
that the drive can support it, before you enable extended length
If either Irwin or QIC-40/80 tape drive is not recognized at boot-up,
it display a message similar to when it can't find a QIC-02. This is
due the standard problems of incorrect configuration.
It is possible to have two floppies and add a QIC-40/80, provided
that the tape drive is configurable for soft select. On
certain tape drives, the unit or drive number can be set by the
driver. On Archive and Mountain drives this is called Soft Select
mode. On Wangtek drives this is called Phantom select mode. In each
case this set on the drive. Check the hardware doc to see if you
drive can handle this. It is a good idea to set it, if you can, as it
helps to limit the number of problems.
The fourth option is for a SCSI tape drive. There are five
different type of SCSI tape drives you can add: Cartridge, Exabyte,
9-Track, DAT and Compaq SCSI. On OpenServer there is an Option for
generic SCSI tape drives if you are not sure what kind you have.
However, being the good little system administrator that you are, you
do know, so you don't need to use this option.
As with any SCSI device you have to be sure of the configuration. You
can have multiple SCSI tape drives on the system, provided they have
unique SCSI IDs.
With a SCSI tape drive, you may end up with a message indicating
there is no controller response. The obvious things to check are the
same with any SCSI device, such as proper ID, cabling and SCSI
termination. If you have more than on host adapter, make sure that
you specified the correct one. Also, if you have OpenServer make sure
that you have selected the correct bus if you host adapter is
Like cartridge tapes, external SCSI tape usually have to be
turned on when the system boots. If the drive is internal, check to
see that the drive initializes when you insert a tape. That is, it
will probably make a few "whirring" noises. Also keep in
mind that a SCSI tape may appear at boot, even though it is not
configured correctly. The initialization routines at boot, do not
check the hardware, but do print the configuration string. (Remember,
this is done with the printcfg()
routine)Therefore, you might see that the configuration
strings shows a device that isn't even on the system, let alone
The one important thing about adding a tape drive is that the boot
string can be modified to reflect this. You could rely on the kernel
having the correct parameters, or you could pass this parameters to
the kernel through the boot string. When adding a tape drive, you are
given the chance to modify the bootstring. If improperly typed in,
this can cause the system to panic when it's booting. So be careful
of what you type in.
The default tape drive accessed by many utilities is /dev/rct0.
If you install more than one tape drive, the mkdev script will prompt
for which drive you want to be the default tape drive. The device
node for this will then be linked to /dev/rct0.
You can do this by hand or through the menu option in the mkdev
In earlier versions of SCO, parallel ports were configured by default
on the system. When you installed, you had immediate access to the
parallel ports. This was useful as most printers ran off the parallel
port. However, things changed. The call load went up. Customer could
no longer access their parallel port. This was not surprising as the
parallel driver was no longer in the kernel on the N1.
The reason for this is simple: it wasn't needed. Well, it isn't all
that simple without understanding the reason why the engineers went
through the trouble of removing it. Why fix something that wasn't
broken or why remove something that didn't bother anyone? You don't
go get your appendix out just because you have nothing better to do
that day. Or do you?
The same thing applied to the parallel driver. It wasn't needed,
that's true, but it was taking up valuable space on the floppy. With
all the SCSI drivers in the kernel, there's not much room for
anything else. Therefore, some things had to go. One of those things
was the parallel driver. As I mentioned, it just wasn't needed during
This changed caused a large number of calls during the first months
after the product shipped. Many hours were spent walking people
through the mkdev parallel
script to add the parallel port. It isn't hard, but for the most
part, customers would much rather have someone tell them how to do it
rather than reading from a book. Besides, finding it in the
installation guide isn't all that easy. (Assuming, of course, you
don't look in the index or table of contents)
As I said, adding the parallel port is not all that difficult. When
you run mkdev parallel you
are given three choices for ports to add. If you are not sure how
your parallel port is configured, I would suggest you add all three.
When you reboot, the hardware screen will display the one you have
and you can then remove the others.
On a new system, it is common to add the parallel port and then
immediately add a printer. Or in many cases the reverse: you've added
a printer and it won't work 'cause you haven't run
mkdev parallel, yet.
The mkdev lp script is one
of the shortest and for good reason: the script itself doesn't do
much. Instead it calls /usr/lib/sysadm/lpsh.
The lpsh program is one of
the nice looking ones that uses the menus and so on in
oamenus and oaforms.
You can call this program yourself or even get to it through
sysadmsh. Since I talked about adding printers in the section on
printers, there really isn't much more I can say here.
Similar in function is mkdev
serial, although as you suspect you use this to add serial
ports instead of parallel ports. The real important issue is not to
use this script when trying to add intelligent multiport cards such
as those from Digiboard or Equinox. Both of these have there own
drivers and installation routines. They will modify the kernel
appropriately and add the device nodes. The
mkdev serial script is only to add non-intelligent (also
referred to as dumb, for the non-politically correct among us) serial
By default, only the COM1 device is configured into the kernel, even
if you have a COM2. This can be added later by running mkdev
There are many manufacturers of non-intelligent serial cards. These
cards do not have any special processor on them and are accessed
using the standard sio
driver. Because of the minor numbering scheme used for serial devices
(see the section on the /dev
directory) you can only add 8 non-intelligent serial ports, even
though there is an option in mkdev
serial to add a 16-port card.
Using the mkdev serial
script, there are only two options for such cards. They represent the
standard COM1 and COM2 ports. Depending on the number of ports you
want to add, you will be given a number of manufactures to choose
from. Although this does not represent all the ones available on the
market, but it does cover quite a few. There is a way to add addition
ones if you need to.
Let's first side step a minute and take a look at
It looks something like this:
sio Y 53 7 0 3 2f8 2ff 0 0
sio Y 26 7 0 4 3f8 3ff 0 0
In the section on the link kit, I went into details about the files
in the sdevice.d
directory. I said that column 3 represented the number of "units"
of that type that were configured. While this is also true for the
sdevice.d/sio file, there
is a level of indirection we need to address.
If we look at the above example, (which I have not changed from what
the system creates by default) we see the two line that represent
COM1 and COM2. It seems rather ridiculous to think that there are 53
COM1 ports and 26 COM2 ports on the system.
In this case, these do not directly represent the number of ports but
rather the offset into an array. This is the
sio_sup_brds array in
/etc/conf/pack.d/sio/space.c. If we look at the 54 line
(remember we start counting a 0) we see the entry for the
AT-IBM-COM2 device. Next, if we look at line 27, we see the entry for
the AT-IBM-COM1 device. (For details for what each entry means, see
the declaration of the board_t
structure in <sys/sioconf.h>.)
If you want to add a new board to this list copy an existing
entry and add it to the bottom of the array. I want to
empathize that this ought to go at the bottom of the list because the
entry in sdevice.d/sio is
the relative position in the array, placing an entry before line 27
or line 54 throws things out of whack.
The next time you run mkdev
serial, the entry you added with appear as one of the options.
Provided you've input everything correctly.
The limit of eight serial ports is not because the system does not
support it, but rather because there are few entries in
support it. The few that exist all micro-channel devices and are only
listed for COM2. This is because the minor numbers for COM2 start at
8. If a 16-port board were to be added to COM1, the minor numbers
would overlap those for COM2.
One common question that support gets is why you can't have COM3 or
COM4. Well, the official word is that you can't. The reason is that
COM1 and COM3 share interrupts and COM2 and COM4 share interrupts and
the SCO serial driver cannot support serial devices at the same
interrupt. However, this is generally true on older boards, newer
ones may allow you to configure both the base address and the
If we go back to /etc/conf/pack.d/sio/space.c
for a moment, we see that there actually are entries for COM3
and COM4. They can be configured like this:
I/O PORT ADDRESS
0x2F0 - 0x2F7
0x3E8 - 0x3EF
0x2E8 - 0x2EF
card can be configured to one of the configurations above, then you
can simply run mkdev serial
and select the proper COM port. If not, you can try to
change the entry in the sio/space.c
file to reflect your configuration. However, I cannot guarantee it. I
have personal experience with using the three settings above, not
with changing the sio/space.c
file. However, based on the way the file is put together, it should
Part of the mkdev script asks you to select a baud rate which for
devices attached to this port. This only means what default values
will be used when creating the entries in /etc/inittab
and the files in /etc/conf/init.d.
Once completed, the mkdev will add the entries to the Terminal
A common problem with serial cards is loss of characters. In certain
circumstances, this can be corrected by increasing the NCLIST kernel
parameter. If this does not correct the problem, then you may
consider getting a either an intelligent serial card (one with its
own processor) or one with a 16550 UART. This has a multiple
character buffer, which decreases the number of characters lost.
In general, installing a serial terminal is the same whether it is
connected to a standard COM port on an intelligent multi-port board.
In either case, you obviously have to ensure that the driver for that
port is linked into the kernel, otherwise the terminal will not be
able to talk to the system.
By default, terminals are set up using 9600 baud, 8 data bits, 1 stop
bit, no parity, full duplex, and XON/XOFF handshaking. If your
terminal cannot handle these settings, then you can either change the
line in inittab to reflect
the appropriate gettydefs
entry, or you can create your own gettydefs
entry if none of these fit. See the section on starting your system
or the gettydefs(F) man-page.
Pay attention to which pins are which on the terminal. You only need
to worry about three: transmit, receive and signal ground. The serial
port will be set up (probably) with pin 2 as transmit, 3 as receive
and 7 and ground if you have a DB25 (25-pin) connector. If you have a
DB9 (9-pin) connector pin 2 is receive, 3 is transmit and pin 5 is
ground. Make sure that the cabling is set up so that transmit on one
side goes to receive on the other and the two ground pins are
connect. In some cases you need a crossed cable, when the pin
numbering is the same on both sides (i.e. the same number of pins).
If pins 2 and 3 are different, then you need a straight through
You need to ensure that there is an entry for the terminal in
both /etc/inittab and
or a file in
not in inittab, but in
either of the other two locations, then potentially the serial port
was added to the device driver files, but the kernel was never
relink. Remember from our discussion on the kernel, when you do a
relink, part of rebuilding the kernel environment is creating a new
file by catting the files in etc/conf/init.d
onto the end of /etc/conf/cf.d/init.base.
Not relinking would explain why the entry was not in inittab.
On the other hand, if it's not in either of the other files, but is
then probably someone added it to inittab
by hand. This needs to be corrected by putting the entry in one of
the other files. Otherwise, the next time you relink, the entry is
If the entry is correct, you can enable it with the enable
command. Like this:
The enable command changes the entry in inittab
and either of the other locations from off
to respawn. If the
terminal is already enabled, you get a message saying so. It is the
fact that there is a respawn
that gives you the login prompt when the system starts and
gives you a new one when you log out. For more details, see the
section on starting and stopping the system and the inittab(F)
man-page. When enabled, the corresponding entry might look like this:
If the login prompt doesn't look right (i.e. garbage characters) then
probably the gettydefs
entry is incorrect. If you remember from our discussion of starting
and stopping the system, this is the last entry on the line. In this
case m. If the m
entry in gettydefs does
not match what the terminal is set for, you get incorrect behavior.
See the gettydefs(F)
man-page for more details.
If you don't see a login on the terminal, it's possible it was sent
before the terminal was turned on. Therefore, the terminal cannot
display it. If you press ENTER a couple of times an no login prompt
appears, maybe it's not really enabled or there is a hardware
problems. Disabled it and re-enabled it. You should also try simply
sending the date to the file, with:
date > /dev/<tty_name>
If that still produces nothing¸
then you may have a hardware problem. If you have enabled the
port, you can run:
to see if there is a getty
or login running on that
port. If not, there may be some serious software problems.
Often times the connector on the terminal is female. You can test the
terminal if take a paper clip and put one end in hole 2 and the other
end in hole three. By pressing keys on the keyboard, the data is
going out the transmit line (pin 2 or 3, doesn't matter) and comes
back in on the other pin. If nothing appears, first makes sure that
the terminal is turned on (I've had my share of those calls).
If it is turned on check the brightness (I've had enough of those, as
well). If still nothing, the monitor is probably on vacation.
If you suspect the cable or serial port, you can try the terminal on
a port that you know is working. Then switch parts one at a time,
until you isolate the part that's broken.
Another script that really points elsewhere is mkdev
graphics. In general, this does the same thing as when you
configure the video card through the System®Hardware
menu options in sysadmsh.
In fact, the exact same program is called. This, too, has the same
menuing functionality of lpsh.
In ODT, your video card and monitor were configured using mkdev
graphics. As with other mkdev scripts, mkdev
graphics still exists, but call the corresponding manager from
scoadmin. In this case it is the Video Configuration Manager. The
mkdev graphics script is
based on the same functions as the sysadmsh
so you have the same kind of windowing as with sysadmsh.
The Video Configuration Manager is the same as the other
One important difference you encounter right away. In ODT you
do not "Add" a video adapter, but rather "Update".
In OpenServer, there is button "Add Adapter." This is a
little confusing since when you get done, you are asked whether you
want to replace the existing video card. To me this is a bug,
or at least a very annoying feature. If I replace the adapter, I am
not adding anything. I am either replacing or updating the adapter,
but certainly not adding. At any rate, don't be confused when you run
If you select "add adapter", then you are presented with a
list of video cards. If you don't have a video card, but rather the
video chips are built onto the motherboard, you should look for the
chipset you have. If your card or chip set is not there, you should
either select one that is closest, or contact SCO or the
manufacturer. SCO might have included the driver in the newest copy
of the Advanced Hardware Supplement (AHS). If all else fails, try the
generic IBM VGA adapter. Although you may not get the resolution you
want, selecting this card normally gets you running.
When you finally select one, you may find that your card had "special
configuration information" if you select 'yes' to view it, you
are brought into SCOHelp, which will give you more details about the
card. If there is no additional information or you have finished
reading the help file, you need to select the resolution and the
monitor configuration. If you just click okay, you are reminded that
you haven't configured the card completely and are asked to do so or
Interestingly enough, if you have selected (highlighted) the video
adapter and then click on Modify instead of Add, you are told that
this action will remove the configured card (which is displayed) and
that you can cancel on the next screen. The next screen is simply the
Add Adapter screen, so you are at the same place.
CAUTION: If you are reconfiguring an existing graphics adapter
that uses I/O addresses and a memory mapped window, please be sure to
write down your current selections before you choose new ones. When
you choose new settings, the current I/O addresses and memory mapped
window are not saved. If you reconfigure an adapter, then later
choose not to save the configuration, the previous settings for the
grafinfo file are not restored.
When you select the option to modify the monitor, you are given the
choice of changing the monitor itself (model, brand, etc), the
resolution of the monitor or add a resolution. This allows you to
have multiple resolutions for the same monitor. There is a list of
monitors from which to choose from. Here again, find your or what
that closely matches. If you don't find one, there are several listed
that say "Other 15-inch" "Other 16-inch" etc.
Find the size you have and select that type.
Next, click on Change resolution to modify the resolution of your
monitor. Here you need to be careful. You might have a video card
that supports a higher resolution than the monitor. Remember that any
system is only as strong as its weakest link. If you try to push the
monitor beyond it's limits, you could physically damage it. At best,
you might end up with a crazy looking display. Therefore, select a
resolution and scan rate that your monitor supports.
Think back to our discussion of video cards. Maybe your card supports
a particular resolution "in principle". However, if you do
not have enough RAM to support that resolution, then your video card
really doesn't support it. Check the card documentation for how much
memory is need for each resolution. Higher resolution on monitors may
require setting the monitor to interlaced on non-interlaced mode.
Again, check the hardware documentation.
New to OpenServer is the idea of having multiple resolutions. Here
you can assign the console multiscreen function keys to different
resolutions. The ability to configure the function keys is also new
to OpenServer. If you want to use the monitor and resolution you
chose for each console multi-screen, select "Assign all function
keys". The time you would want to select a different monitor and
resolution is when you have a second video card and monitor that have
a different resolution. If you are configuring multiple cards and
monitors, I suggest that you group the function keys somehow. For
example, you could assign F1-F6 to one video card and F7-F12 to the
The Video Configuration Manager does not configure the kernel like
other driver, but instead gets its information from three ASCII
files, stored in /usr/lib/grafinfo.
The graphinfo files, contain the information for the graphicsi
(video) cards. derives the configuration choices it provides from
three sources: grafinfo (graphics card information) files, moninfo
(monitor information) files, function key or device files. The
grafinfo and moninfo files are ASCII text files that are located in
subdirectories of the /usr/lib/grafinfo
directory. These files describe the attributes of the graphics
adapters and monitors that are supported by the Graphical
The grafinfo files use the name of the particular adapter they
describe and an .xgi extension (for example, wonder.xgi); the moninfo
files use the name of the particular monitor they describe and a .mon
extension (for example, 8514.mon). The function key or devices files
are text files that are located in the /usr/lib/vidconf/devices
directory. These files contain the device driver names for all the
programmed function keys on the console (<F1> through <F12>)
as well as the device driver name for the console. The console driver
is used when the system is running in single user mode.
New to OpenServer are "readme" files for many of the video
drivers. In most cases, these can be displayed when running mkdev
The scripts mkdev ptty and
mkdev streams usually are
associated with either TCP/IP or X-Windows. Pseudo-ttys are virtual
terminals, that do not have any physical counter-part. For example,
if you connect to a remote machine via telnet,
the shell needs to write it's output somewhere. That somewhere is the
virtual, or pseudo-terminal you are using. When installing TCP/IP you
are asked how many pseudo-ttys you want installed. If you input a
value that later turns out to be too small, you can use the
mkdev ptty script to add more.
Streams are configure in the system be default when you add either
TCP/IP or X-Windows, and are a way to add modularity to drivers. Like
mkdev dos, the
mkdev streams script is like and on-off switch. Since streams
is essential to X-Windows and TCP/IP removing them if either one is
installed is not a good idea.
Next, we get to mkdev mouse.
There are several different kinds of mice as you might remember from
our discussion on the /dev
directory. Although not possible in a DOS or Windows environment, it
is possible under SCO to have multiple mice configured on your
In that discussion, I brought up the fact that there are three kinds
of mice: bus mice, serial mice and keyboard mice. The most annoying
to work with (at least in my mind and from and administrative
point-of-view) are bus mice. These have their own cards that are
plugged into slots in the machine. In order to configure them
correctly, you have to ensure that the jumpers (or switches) match
those that you tell the software. In addition, there is a problem
just in the fact that they require these setting. Most of the one I
have seen do not allow you to set IRQs higher than 9. Since the
interrupts below that are already in short supply, taking one away
for a bus mouse is annoying. My solution is a serial mouse.
Now a serial mouse does have the disadvantage of taking away a serial
port. If you attach a modem to the other serial port, both of them
are gone. Then, on the other hand, what else do you need the serial
ports for. In order to connect to the system, serial mice will have
either a DB9 or a DB25 connector. Some, like my Logitech Trackman
have a DB9 on the end of the cable, but provides a DB9 to DB25
Another nice thing about serial mice is that you don't have to
connect them to a standard COM port. If you have a multiport board
(intelligent on not), you can attach the mouse to any port on the
multiport board. Be careful, however. You want to be sure that you
attach the mouse to the non-modem control port (the lowercase letter,
Keyboard mice are connect to a dedicated port at the back of your
computer. They will usually have either a 6-pin or 9-pin mini-DIN
connectors. More and more computer vendors are selling their systems
with keyboard mouse plugs built-in. Often, the plug for the console
keyboard is the exact same size as the one for the mouse. Needless to
say, I got enough calls from customer when trying to install their
OS, they couldn't even boot because of a keyboard error or something
similar. (Now, ask yourself one question: "Is this really
an operating system problem.")
Now, if you think back to the section on starting and stopping the
system, the hardware check comes before the system tries to boot.
Therefore it hasn't even looked at the installation floppy, so there
is nothing the OS could have done to cause the problem. However, the
customer, not knowing the phone number for the hardware manufacturer
found SCO's quick enough and called us.
Unlike the other mouse types, installing a keyboard mouse without one
on your system can cause some problems. It is known to happen that
the keyboard will lock, if there is no keyboard mouse port on the
machine. If this happens you will need to boot off an old kernel and
remove the keyboard mouse driver.
During the installation process of either type of mouse, you are
asked the devices to which you want to associate the mouse with. You
could associate a mouse on COM1 with /dev/tty01-/dev/tty05
and the mouse on COM2 with
/dev/tty06-/dev/tty10. This might be useful if you had two
video cards in you system that split the console tty devices between
them. There is also an option within the mkdev script to change the
association of the mouse. Therefore, you can add a video card later
and change the device association.
Keep in mind that if you don't have the mouse configured correctly,
you will run into trouble when starting X. Sometimes you just can't
log in, so you have to switch screen to get a character login.
However, I have seen cases where you cannot even switch multi-screen.
Therefore you might want to test the mouse before you use it.
There is relatively unknown program that not only allows you to test
your, but allows you to use it with such things as sysadmsh
and even vi! To start it
in "vi mode", run the command like this:
usemouse -t vi -c vi
I'd recommend choosing a file that already exists to see the
behavior. You can also use the mouse with sysadmsh.This
is one of the other modes that usemouse
has. This is simply based on one of the configuration files in
In vi, the mouse buttons
should result in the follow actions:
The left button moves the cursor to the beginning of the file.
middle button deletes the current character.
right button moves the cursor to the end of the file.
To simulate the middle button on a two button mouse, press both of
the other buttons at the same time. This is called "chording".
You stop the usemouse
utility simply by typing exit at the shell prompt. This is because
usemouse starts a
sub-shell when it is invoked.
does not produce the correct behavior, go through the normal "sanity
checks" of ensuring the cabling is correct, jumper settings
match (if applicable), the card is seated correctly (if it's a bus
mouse) and is recognized at boot if a bus mouse and the serial is
recognized if a serial mouse, and that the mouse is supported.
In the section on hardware, I mentioned that the resolution of the
mouse effects how much it moves across the screen in proportion to
how much you move it across the mouse pad. If you have a keyboard
mouse, the resolution can be changed by editing
parameter determines how many "clicks" (or reports
or counts) are passed to the mouse driver for every millimeter you
move the mouse. The relationship between kbm_resolution
and the clicks per millimeter for a high-resolution
For a low resolution mouse, the relationship looks like this:
If you change this parameter, you must relink the kernel and reboot,
before the changes will take effect.
A common problem with mice is that they are sometime slow or
"sluggish." That is, they do no appear to move or react as
quickly as they should. This can be changed by modifying the
kbm_poll, also in
/etc/conf/pack.d/kbmouse/space.c. This parameter determines
how often the mouse driver will poll the mouse. The greater the value
the more often it will poll. If you decrease the value below 0xb0,
the system might freeze. A good starting value is 0x400.
Here again, you must relink and reboot for the changes to take
Miscellaneous mkdev Scripts
If you have a Compaq machine, there is one script that would be of
special use to you. The mkdev
ida script allows you to add an Intelligent Drive
Array. This give you the ability to talk to several physical
hard disks as one large one.
If you have a Corollary system, the
mkdev eccd script allows you to add the memory error checking
and correction (ECC) facility. The daemon associated with this device
regular checks memory and is capable of detecting single bit and
double bit errors. Single bit errors can be corrected, whereas a
double bit error cause a panic. the ECC facility notifies the system
of single bit errors and decreases the likelihood that they grow into
double bit errors.
Two remaining scripts, 'mkdev
vpixld' and 'mkdev
dda' are used if
you have VP/Ix on your system. If you don't know what VP/ix is don't
worry you don't want to. Since I am not going to be talking about
VP/ix at all, we are going to have to leave these alone.
There are two scripts that are linked together: shl
and layers. They add shell
layers to you system. Shell layers allow you to interact with more
that one shell session from a single terminal. This is comparable to
repeatedly typing sh to
get sub-shells. The key difference is that with sub-shells, you can
move only in one direction. Once you start a sub-shell, you do not
have ready access to the parent shells. With shell layers, you have
access to all shells.
This may sound like an interesting topic (which it is), however the
low number of calls and the simplicity of the subject cause me skip
One of the more simpler scripts is mkdev
dos. This is really nothing more than an on-off switch. This
script is used to either add DOS support or remove it. Once it's
added and you reboot, you will be able to mount DOS filesystems and
access them like any UNIX filesystem. You do not need to have
Merge installed to take advantage of this functionality. For more
details, see the chapter on DOS and Windows compatibility.
script that adds functionality without adding devices is mkdev
mmdf. The mkdev
mmdf script allows you to configure SCO UNIX's standard mail
system MMDF. There are quite a few configuration aspects to cover,
which we covered in detail in the section on MMDF.