SCO/Linux Transition Guide

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.

Also see New to SCO

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!

There is porting information in the FAQ:

• How can I mount a SCO file system in Linux or vice-versa?
• How can I transfer SCO accounts (passwd information) to Linux?
• Can Linux run OSR5 binaries?
• GCC Compiling Tips

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.

Even more support is available with the Open Server Kernel Personality for Unixware, but really, I think Linux is a better way to go.

Booting

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.

Modules

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 at boot.

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 by:

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 then usually:

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).

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 picture:

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.

Startup

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.

Devices

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, etc.

Hardware Info

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 /proc is.

Shells

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 with stty.

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

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.

Printing

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.

Newer Linuxes use CUPS. SCO users should review Using System V interface scripts with CUPS printing for an easier transition (but should take the time to understand CUPS also).

"lpc" doesn't exist on SCO

IP Filters etc.

SCO has tcpd available from Skunkware and an article here explains IPFILTER.

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.

PPP Connections

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.

Software

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".

Shutting Down

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

Got something to add? Send me email.

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us