SCO Unix, Xenix and ODT General FAQ
This article is from a FAQ concerning SCO operating
systems. While some of the information may be applicable to any OS,
or any Unix or Linux OS, it may be specific to SCO Xenix, Open
There is lots of Linux, Mac OS X and general Unix info elsewhere on
this site: Search this site is the best
way to find anything.
There are a lot of different situations possible here - far too
many to cover. I'll handle a few; any common additions to this list
are certainly welcome.
Upgrading memory - on the hardware side, that's easy; add
the memory and run whatever your hardware uses for a setup program.
One gotcha here is that many motherboards with L2 cache can only
cache up to a certain amount of memory. Check with your motherboard
manufacturer. In many cases, you need at least 64 kB of cache per
16 MB of system memory. From the software side, Xenix handles only
16 MB of RAM; different versions of Unix handle different amounts,
so check the release notes for your version. The kernel will
automatically see the additional memory, but may not put it to
optimal use. There are a few kernel parameters which can auto-tune
themselves within certain ranges (the best-known is NBUF),
but most are fixed at link time. So the short answer is that the
system will _use_ the memory, but perhaps not in the way you want
it to unless you configure and link a new kernel.
Upgrading the CPU - it should work fine, with one notable
exception. Older Unix (and Xenix GT) releases have a timing loop in
the ad (Adaptec 154x) driver detection code which will time out on
many high-end 486 or higher machines, resulting in the host adapter
not being detected. Recent Unix releases have this cured; there is
a patch for at least some older Unix versions. See the question on
154x detection in section 3.
Using an EIDE drive - first, some background. Traditional
hard drives appear to consist of cylinders, heads, and sectors, and
the standard hard drive controller driver in SCO products has
traditionally expected standard (MFM, RLL, many ESDI, and ATA) hard
drives to appear this way. For ATA drives, this is fine up to about
500 MB, at which point the interface details and the BIOS conspire
to cause problems. EIDE gets around this by defining a new
addressing mode - LBA (Logical Block Addressing). LBA must be
supported by your operating system and/or your BIOS, however, and
no SCO product prior to OpenServer Release 5 supported LBA mode out
of the box. There is a note in the second section of this FAQ on
how you may get an EIDE drive beyond 500 MB to work on 3.2v4.x.
Also, LBA support is one of the features of uod429a; check the
documentation for this patch.
If you're running OpenServer Release 5, your EIDE hardware
should work just fine. If you're running an earlier release of SCO
Unix, or any release of SCO Xenix, your EIDE hardware should work
as long as it's in CHS mode and NOT in LBA mode.
The other caveat is that since /boot
is real-mode code which does its disk access through the BIOS, and
since the BIOS can only access up to 1024 cylinders, there are
several files and directories which must lie entirely within the
first 1024 cylinders in order for you to boot. The easiest way to
do this is to keep your entire boot filesystem within the first
1024 cylinders. For fresh OSR5 installations, you have the option
of creating separate boot and root filesystems; this is generally a
good idea, and means that your root filesystem can be as large as
you like (since it's only the boot filesystem which needs to be in
the first 1024 cylinders). If you do not select a separate boot
filesystem, or if you're running an older version of Unix or Xenix,
your entire root filesystem should live within the first 1024
Newer BIOSES no longer have that 1024 cylinder
Changing SCSI host adapters - there's a big gotcha here.
Different host adapters (even the same one, often, if configured
differently) use different logical mappings of the drive, and a
drive set up under one host adapter may not be readable under
another. Even two versions of the same adapter may have this
problem; I've seen problems moving from an Adaptec 154xB to a
154xC, and Adaptec recommends reformatting (!). So it may work ...
or it may not. Never ever try this without at least one
backup which verifies 100% perfectly ... and see the note earlier in this FAQ about using tar or cpio for your backups before considering either to be a good backup program. There is a note in the Unix-specific part of this FAQ on a
possible procedure for such a change.
Using an ATAPI CD-ROM - SCO Xenix doesn't support
CD-ROMs. SCO Unix (at least since version 3.2.2) does, but prior to
OpenServer Release 5, they had to be SCSI CD-ROMs. While SCSI is
generally a wiser choice, support for ATAPI CD-ROMs has been added
to OpenServer Release 5. While many IDE CD-ROMs are ATAPI CD-ROMs,
not all IDE CD-ROMs follow the ATAPI spec. Only those which do are
supported. Note that uod429a adds support
for ATAPI CD-ROMs; check the notes for this patch to determine
whether it's applicable to your system.
My 2 cents; I've recently upgraded my system (a vanilla
EIDE/ATAPI based machine). Before replacing the MB and the CPU, I
carefully wrote down the list of PCI devices as recognized by the
BIOS before the OS5 boot prompt (my system is equipped with a PCI
video and network card and a pretty old ISA sound card); also I
checked to make sure they were re-inserted in the same PCI slots of
the newly built machine. After powering up the machine, everything
worked as expected, apart from the fact that it was WAY faster
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic