This is not a porting guide; this is a transition guide: a guide
to the major differences between SCO and Linux that anyone familiar
with one may find confusing about the other. As both OS'es are
themselves always in transition, some of this material will change
quickly. I'll keep it up to date as best I can, of course. Mostly
this article concerns SCO OSR5 and not Unixware; in some places
I've noted differences but not always.
Keep in mind that many things that may seem very different are
shell differences, not operating system differences. Bash, sh and
ksh, although similar, are also very different.
If you are trying to get remote access to an old SCO box that doesn't have TCP/IP, a simple and inexpensive solution is to put up a small Linux box for ssh access and then use minicom or Kermit or whatever to get to the old SCO system. Cheaper than an upgrade!
Keep in mind that you should always check man pages- Linux tends
to use GNU commands whereas SCO uses traditional Unix, and while
the differences are often minor and subtle, sometimes they are
enough to break your scripts. Even subtle differences can trip you
up, but on the other hand, most of whatever you are used to on
either OS will probably just work on the other. Linux has the ibcs2
module which will even let you run many SCO binaries directly, and
SCO has "lxrun" (from Skunkware) which lets you run many Linux binaries on SCO.
I suppose I should mention that SCO's Unixware OS contains a lot of binary compatability for applications originally designed to run on SCO's Open Server (OSR5) product.
Most Linux distributions use LILO, and you'll find considerable
mention of it in FAQS and news group postings. SCO's boot loader,
however, is seldom mentioned at all in SCO newgroups. The
difference is that LILO is a very simple loader that needs a
configuration file and (most importantly) needs disk addresses
hard-coded within itself. This last part is done by running
/sbin/lilo, and it's necessary to do that whenever a new kernel is
built because the LILO loader can't walk a filesystem and needs
that hard coded information.
To have a choice of kernels to boot from, LILO needs to have
been preconfigured to know about them (/etc/lilo.conf), but the SCO
loader can find and load any kernel without pre-arrangement.
Linux device drivers can be (and usually are) modules that can
be loaded as needed and unloaded when they are not. SCO Unixware
also has that ability, though most of its drivers are not supplied
that way. SCO Openserver does not support loadable modules except
Building a new kernel
This is something done much more often on SCO than on Linux.
Loadable modules and the ability to directly modify kernel
variables (by "sysctl" on some distributions, or by directly
writing directly to files in /proc ) make it unnecessary.
For example, to modify the value of shmmax on a Linux system,
you could simply echo the desired value to /proc/sys/kernel/shmmax
or (if you have it) use sysctl. On SCO, you'd change it with either
/etc/conf/bin/idtune, /etc/conf/cf.d/configure or the SCOAdmin
manager, but you'd still have to relink a new kernel and reboot for
the change to take effect.
Linking a kernel on SCO can be done through "scoadmin" or
Rebuilding a kernel on Linux is a much more involved procedure,
which usualy starts with running "make config" (or "make
menuconfig", "make xconfig") in the /usr/src/linux directory. You'd
followed by copying the new kernel to the boot filesystem. You
aren't done yet; you need to compile modules (make modules) and if
you want to be able to boot from the old kernel you'll need to have
renamed the existing module directory first. Finally you would
configure /etc/lilo.conf and run /sbin/lilo. It all sounds terribly
complicated to someone used to SCO, but it's not all that bad once
you get used to it- and of course this is not something you do all
that often anyway.
Filesystems, partitions, divisions
There are major conceptual differences here. With Linux,
filesystems are built directly on partitions. An extended partion
can contain more than one filesystem, but it still shows up in
fdisk as multiple partitions. This is the output from Linux fdisk;
there really are only 2 partitions on this disk. Note that the
Linux partitions all start within the "Extended" partition (look at
the Start and End columns).
Disk /dev/hda: 64 heads, 63 sectors, 1023 cylinders
Units = cylinders of 4032 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 377 760000+ c Win95 FAT32 (LBA)
/dev/hda2 378 1023 1302336 5 Extended
/dev/hda5 378 386 18112+ 83 Linux
/dev/hda6 387 990 1217632+ 83 Linux
/dev/hda7 991 1023 66496+ 82 Linux swap
SCO puts "divisions" on partitions. A division can contain up to
7 filesystems. You use the "divvy" tool to manipulate the division
table. Therefor fdisk on a SCO machine shows a different
Current Hard Disk Drive: /dev/rhd00
| Partition | Status | Type | Start | End | Size |
| 1 | Active | UNIX | 16575 | 66299 | 49725 |
| 2 | Inactive | UNIX | 1 | 16574 | 16574 |
Total disk size: 66555 tracks (256 reserved for masterboot and diagnostics)
This is a little unusual: normally you'd have only one partition
and if you did have more than one, usually it would be because you
want to run multiple operating systems. However, the divvy table
shows the file systems actually present. This would be the divvy
table for ONE of the partitions- the partition that contains root
and boot. The other partition might only have one file system on
it, or it might have seven. Note that the "eighth" division
actually is just the entire partition.
| Name | Type | New FS | # | First Block | Last Block |
| boot | EAFS | no | 0 | 0| 29999|
| swap | NON FS | no | 1 | 30000| 157999|
| root | HTFS | no | 2 | 158000| 2080406|
| | NOT USED | no | 3 | -| -|
| | NOT USED | no | 4 | -| -|
| | NOT USED | no | 5 | -| -|
| recover | NON FS | no | 6 | 2080407| 2080416|
| d1057all | WHOLE DISK | no | 7 | 0| 2088417|
2080417 1K blocks for divisions, 8001 1K blocks reserved for the system
n[ame] Name or rename a division.
c[reate] Create a new file system on this division.
t[ype] Select or change filesystem type on new filesystems.
p[revent] Prevent a new file system from being created on this division.
s[tart] Start a division on a different block.
e[nd] End a division on a different block.
r[estore] Restore the original division table.
Enter your choice or q to quit:
It seems whenever I stick fdisk or divvy examples in an
article, some helpful person writes to me to explain the use of
<TABLE> tags in HTML. Yes, I know how to write tables- what
you are looking at above is NOT my crude attempt at ASCII art, but
is the actual character output from the programs!
SCO has an /etc/default/boot file that can control many of the
actions of the boot loader; in some respects this is similar to
/etc/lilo.conf on Linux systems for the purpose of passing
parameters to the kernel.
At the present time, I don't know of any Linux tools that can
mount SCO filesystems. The major hurdle, of course, is the concept
of divisions vs. partitions.
Linux Kernels pre 2.4 have a 2GB file size limit, as does SCO
OSR5. The 2.4 kernels will lift that limit as SCO Unixware already
has. The 2.4 kernels are also supposed to have a Veritas-like (or
is it actually Veritas?) file system- OpenServer and Unixware can
have that also but commonly do not.
The Linux analog to /etc/default/filesys is /etc/fstab.
Most Linux distributions use init, so SCO folk will be
comfortable with that, but the contents of inittab are very
different, particularly for the "rc" or system boot files. SCO has
its startup scripts under /etc/rc2.d; Linux would usualy be
/etc/rc.d/init.d - but this varies very much between distributions-
you need to trace it through /etc/inittab to find out.
Pre Linux 2.4 kernels, /dev on either OS is pretty similar,
though device names are different. The 2.4 release (not yet out as
I write this) apparently will change all that and all you'll have
in /dev (which won't be a real fs anymore) is the actual hardware
you are running.
Coming from either side, it can be tough to figure out what is
what. Floppy disks are pretty easy, and hard disks are fairly self
evident (though keep in mind that SCO creates links to the
filesystem names shown in the divvy table- there will be a
/dev/root and /dev/rroot for example). But tape drives can be
frustrating: SCO may have the working tape drive linked to
/dev/rct0; if not, and it's SCSI, it's /dev/rStp0. On Linux,
/dev/st0 is the first Scsi tape device, and IDE tape is /dev/ht0 or
one of your /dev/hd? devices (because it's IDE).
Pseudo ttys are named a little differently: Linux runs ttyp from
0 through f and then moves to ttyq (and after z wraps around to
ttya through e); sco starts at 0 and keeps on going through 10, 11,
SCO systems have a number of hardware related commands:
"hwconfig", "hw" and "sconf" are the most common. Linux has an
awful lot of information located just under /proc; much of whatever
you'd want to know can be found just by looking at such files as
/proc/interrupts, /proc/ioports, /proc/modules, /proc/meminfo etc.
Be careful though: those are ASCII files, but not everything under
The usual default shell on Linux is "bash". On SCO it's "sh"
(though "ksh" is common also). SCO users shouldn't have much
trouble adjusting to bash (though there certainly are differences
worth learning about!), and Linux folk can install bash from
Skunkware - but
DON'T make bash root's default shell- you run a real danger of
breaking the startup files execution.
Typically, Linux stty settings for the interrupt character (and
others) are different between SCO and Unix and will cause great
annoyance in either direction. SCO traditionally uses the DELETE
key as Linux uses CTRL-C; you can, of course, change this behaviour
SCO users are accustomed to the shell correcting their mistypings
of "cd" commands. Bash can do something similar, see Clever Bash Tricks
If you are on a SCO system without bash and you really miss
command line recall, use ksh.
Cron is very different between SCO and Linux. First, the
location of files is different: all SCO crontabs are in
/usr/spool/cron/crontab , but Linux has them in several places:
/var/spool/cron for user's files, and both /etc/crontab and files
in /etc/cron.d (those in /etc/cron.d include an extra column which
says which user to run as). Linux crontabs can also contain
environment variable settings; SCO users will find that useful,
while Linux users on SCO will be annoyed.
Older Linux uses BSD /etc/printcap style printing; SCO users should be
at least marginally comfortable with that, but Linux users are
going to be confused by SCO's standard System V style printing. An
article here discusses SCO
Printing; most of what a SCO transplant to Linux needs to know
is in the man pages for printcap, lpd and lpc.
Most Linux distros use "ipchains", some older folks may be more
used to the "ipfwadm" commands, and it's all about to change again
with the new 2.4 kernels coming soon.
Sco has SCO PPP and Morningstar PPP; these can be configured
with SCOAdmin or see SCO PPP
for a quick guide to setting that up manually. Linux distros often
have different tools; KDE desktops have Kppp ; RedHat uses
linuxconf or control panel, Caldera uses lizard, and so on. Linux
ppp setup is usually quite a bit easier than it is on SCO.
As mentioned at the beginning, there is cross compatibility
through lxrun and ibcs2. Additionally, you can compile software on
SCO- assuming you have a development system, which is not usually
the case. You can put the GNU development system on SCO OSR5 and
Unixware (from Skunkware again), but make
files don't often have good support for SCO, and you may find it
easier to just get the binaries from Skunkware or an ftp site
Emergency Boot Disks
Sco users often run one of the Supertars that have their own
emergency boot disks; otherwise you can create them with "mkdev
fd"; Linux systems usually have "mkbootdisk".
Most Linux distros can be shutdown at the console with
CTRL-ALT-DEL. Sco systems cannot be.
SCO has BTLD's ( boot time loadable drivers) loaded with the "link"
command at boot. Linux btlds are "driver diskette" 's - add "dd" to boot options to load a driver module during initial installation. See (for
example) Appendix F. Driver Diskettes