This is part of a series of articles that covers the
booting of an OSR5 machine. See Booting
OSR5 for other related articles.
The program that actually displays
SCO OpenServer(TM) Release 5
is /boot, but there are several steps that precede
I'm ignoring the POST (Power On Self Test) routines and
anything else (security checks, etc) that might be built into your
machine. Obviously all of that happens prior to boot, but isn't
important for this article.
When an X86
processor is turned on, it runs in real mode. This
is the mode that acts like the original 8086 processor, and
physical memory was limited to 1 megabyte in those machines. The
very top of that memory was, and still is, ROM. The processor starts
reading instructions from that memory at 0xffff0. What's always
there is a "jump" instruction that sends the CPU off to the PC
That specific boot code might be part of your original ROM, or
it might be on an add-on card such as a SCSI host adaptor or a boot
capable network card. If it is a disk, it is that code's job to
find out which disk boot from. One some PC's you may have some
control over that choice, but historically the boot device has been
the first IDE drive or SCSI ID 0.
It is possible to boot and run SCO from SCSI drives other than ID
0, but that does add complication, so I'm going to ignore that
until the end. It's also possible to boot from a network card, but if we
were going to boot Unix over a network, that would most likely be
done by /boot running on a floppy or small hard drive (see
The BIOS code doesn't do much. It's smart enough to find the
boot disk and read the first sector of that disk into memory. The
CPU then jumps to that code, which is expected to be the
masterboot code (that's the MBR - Master Boot Record -
in DOS terminology).
The same thing happens with a floppy disk (actually it's
just a little bit different, but the concepts are the same. See
"man HW boot" if you want the details).
You'll find an image of your masterboot code in /etc/masterboot,
and you can use "dparam
-w" to copy it to the first sector of the boot drive (see
Remember that /etc/masterboot is not what actually gets read by the
BIOS- that's just a copy for your convenience. What actually gets
read is whatever is in cylinder 0, head 0, sector 0- whether you
put it there or something else did (like a boot sector virus from
booting a Dos floppy).
The masterboot code looks for a partition table. That's
stored just following the masterboot code itself, so it isn't hard
to find. PC hard drives have 1 to 4 partitions. These are sometimes
called fdisk partitions because the MSDOS program that
created them was called that. Note these are NOT SCO divisions, and
the program that can access them under SCO is also called
fdisk. Here's the partition table from the machine I'm
writing this on:
I was amused recently when someone suggested that I should
have used an HTML table to display this. Actually, what follows is
not my clumsy attempt at ASCII art, but is a screenshot of the real
output you get with OSR5 fdisk.
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. For example, here's the
partition table from another machine here:
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
That machine runs both Linux and Windows and the partitions show
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. If you ran fdisk from Dos or
Windows, all you'd see is the Win95 and the Extended partitions.
This particular configuration was due to using the Linux "fips"
utility to shrink an existing Windows partition: see Installing RedHat 6.0.
Only one partition can be marked "ACTIVE". That partition is
indicated by an "*" in the Linux partition table, and is marked
"Active" on the SCO machine. The masterboot code identifies the
active partition, and then loads code from the first sector of that
partition. SCO calls that code hdboot0. As with the
masterboot code, you can find the code for it in /etc/hdboot0, but remember
that what is actually loaded is what is in the first sector of the
The hdboot0 code is only 512 bytes in size. It's primary
function is to load the code starting at sector three of the active
partion- 1536 bytes away from the start of it. That code is called
hdboot1. Note that up until this point, there is no
concept of file systems. Neither masterboot nor hdboot0 understand
file systems; they load very specific sectors from very specific
disks. The hdboot1 code, however, is almost 20kb in size, and it is
able to understand EAFS file systems. That is, it can read the
directory structure and follow paths to locate files, and once it
has found what it wants, it can use the inode information to read
the actual disk sectors needed. It can't understand HTFS or DTFS
file systems, and that's why OSR5 root file systems must either be
EAFS or there must be a /stand file system that is EAFS. The
hdboot1 code needs to understand EAFS because it needs to find and
load /boot (which usually becomes /stand/boot). After
loading, control transfers to the /boot code.
Instructions for restoring these files are often given
Many Linux systems use LILO, which can't read any kind of
file system at all, and therefore requires the raw disk locations to
be hard coded. This is done by /sbin/lilo (which you run BEFORE
booting a new kernel) reading a configuration file of what to boot,
and then locating the actual disk locations, which it tucks into
the LILO boot code.
The "active" partition is always /dev/hd0a, so it's easy to see
that /etc/boot0 does get copied to the first sector of that
partition. The /etc/boot1 ends up in the third sector because
sectors are 512 bytes, and the "dd" command skips 1k, or two
On OSR5 systems, you can use "instbb" instead:
instbb hd /dev/hd0a
"/etc/instbb" is a shell script; you can examine it to see how
it actually works.
You can look at and compare the actual contents of your disk
with these files using "hd":
hd /dev/hd0a | more
hd /etc/hdboot0 | more
dd if=/dev/hd0a skip=2 | hd | more
Like hdboot1, /boot obviously understands EAFS file systems. It
actually understands quite a few things. It even has a
configuration file, /etc/default/boot, and that might make you
think that it knows how to read more than an EAFS file system, but
it doesn't (well, it can read Xenix file systems, and S51K file
systems, but definitely not HTFS and DTFS). If you look in
/stand/etc/default (I'm ignoring systems that don't use /stand),
you'll find the file it actually does read and use. Normally, you
don't have to be concerned about this, because any orderly shutdown
(including a simple init 0) will copy /etc/default/boot to
This /boot (remember, it's actually /stand/boot on most systems)
is a fairly clever program. It's only about 70k in size, but it
knows how to do quite a few different tasks. the most important, of
course, being loading the kernel. Which kernel? A kernel that is
present on /stand, of course. The default kernel is specified in
/stand/etc/default/boot, but you can override that. You can, for
example, type "unix.old" and you'll boot that kernel. That's useful
when the kernel produced by the last relink is somehow broken.
It also understands quite a few other commands. For example,
"dir" will list the files it sees in its current directory, and
"biosgeom" will display the geometry of the hard drive (it's also
possible to set a new geometry with the same command). See "man HW
boot" for details.
Before it even puts up that "Boot" prompt, it looks for and will
read commands from .bootrc, if it exists. It reads
that before looking at /etc/default/boot, so this can be used to
load a tcp/ip driver so that a network boot can be done, for
example. After that, it reads /etc/default/boot, and then waits for
It doesn't necessarily wait forever. One of the parameters in
/etc/default/boot is the AUTOBOOT variable, which, if set to YES,
specifies that /boot should just go ahead and load the default
kernel if nothing happens for 60 seconds. You can speed that up or
slow it down by adding a TIMEOUT variable to the default file, but
if you do that, be very careful not to make the time too short.
There will come a day where you will need to intervene at the boot
prompt, and very short TIMEOUT combined with a fast machine can
prevent you from doing that. If your default kernel won't boot, you
have obvious trouble.
/boot can also load other partitions. This is useful for loading
other operating systems (you
don't need to buy Partition Magic or other tools to boot other
partitions). Actually, /boot doesn't really do that directly: it
uses "bootos". See "man bootos" for examples of that.
/boot also helpful if you need to boot from floppy. For
example, if your boot code (masterboot,hdboot0 or hdboot1 or even
/boot) were damaged, you could boot with an emergency boot floppy
(mkdev fd) and at the Boot prompt type "hd(40)unix". This will load
Unix from the hd(40) device (that's /stand on most OSR5 systems,
and /dev/root on 3.2V4.2 systems).
Booting SCSI drive when ID is not 0
By default, SCO Unix expected the boot drive to have ID 0. It was not uncommon to receive new systems with the ID set to 6, so we'd usually re-jumper the drive to what SCO expected. However, with a little understanding, you could
boot SCO on any SCSI ID at all.
As it was usual to have to open the machine anyway (if for no other reason than to check that SCSI termination and cabling was done correctly!), I usually just reset the ID's rather than follow this procedure.
From: [email protected] (Bill Vermillion)
Subject: Re: Installation problems ("free" UW 701)
Message-ID: <[email protected]>
Date: Fri, 9 Apr 1999 01:05:22 GMT
You can boot SCO from almost any SCSI ID you wish. Many of the
modern controllers have a setting to specify the boot drive,
however that's not a major limitation if you have something
as recent as an Adpatec 1542C (I've never tried from others).
If you try to install on another drive - say 1 for example -
and it is the first drive found in the system - and you don't
change the boot command on install, you will have problems.
The first drive seen is the boot drive. So if you had
an HD (removeable perhaps) at ID0, another at ID1, and a Zip at
ID6, the systsem would try to boot from ID1.
However the OS 'thinks' it is drive 0. At the install time
used the defbootstr option to set Sdsk to you adaptor
code (blc,ad,??) followed by the parameters in the form
of (0,0,0,0), which give the adator card number, the scsi bus, the
SCSI id, and the LUN.
Once you do that, anytime this drive appears as the first drive, it
will be used for boot.
On SCSI adpators that do not have the 'boot from drive xx' option,
and using the above caveat that you have something like a 1542c or
newer it's just as easy.
Go into the SCSI card set up and turn Scan for BIOS OFF for all
devices prior to the drive you wish to boot from. It's not black
magic, and there is no truth that SCO can ONLY boot from ID0.
I have a removeable HD (with power switch) as HD0. When I turn
it's power off, the next ID - in this case 1, is listed
as the first hard drive, and ID6 - a zip drive - is listed as the
second hard drive.
If I turn SCAN for BIOS off on 1 and 2. the first drive found is
the ZIP at ID6, and I boot into MSDOS. (I did it to try, not than
I run from it).
SCSI is far too flexible to be constrained as most people seem to
think it is.
You can boot from any drive that you can make see as the boot
PROVIDING you also supply the Sdsk parameters to boot: during the
initial install phase. Then you never have to do that again.
Bill Vermillion bv @ wjv.com