Bela Lubkin explains this:
GB is "gigabyte", presuming to use SI unit prefixes. The SI "giga" or
"G" prefix means 10^9, not 2^30. The computer industry has long had a
problem with things like "40 megabyte" hard disks that were actually 40
million bytes, which is only 38.1 times 2^20. Now we have gigabyte
disks; a "40 gigabyte" is only 37.3 times 2^30.
For a more concrete case of where it matters: the OSR5 IDE device driver
currently does not support 48-bit LBA addressing. It is thus limited to
supporting drives <= 128GiB, or <= 137.4GB. You buy a 130GB IDE hard
drive: is it going to work or not?
A new system of binary prefixes, to parallel the SI decimal prefixes,
has been proposed. Four of the prefixes are "kibi, mebi, gibi, tebi"
or "Ki, Mi, Gi, Ti", meaning 2^10, 20, 30, 40. See
That's 16 bytes below the 1 megabye physical limit of the X86 in
real mode. This is expressed in hexadecimal notation (notice the
Aliases in /etc/default/boot
The "man F boot" page gives examples of aliases, as does "man
bootos". The most necessary alias is "defbootstr": without that,
you'd have to specifically type what you wanted at Boot:, and the
AUTOBOOT and TIMEOUT settings would have no effect.
Booting from a floppy
If you don't have one of the Supertars, you'll make Emergency boot
floppy sets with "mkdev fd".
It seems that there is ALWAYS some problem with "mkdev hd" on
every release of SCO Unix. If you can't successfully create these
(successfully means that they actually WORK- you need to TEST them
by attempting to boot), see SCO's Search Database and search
for "mkdev fd". You'll probably want to refine that search to your
specific OS version or to the actual error you got.
Boot floppies can solve all sorts of problems, from missing boot
code to forgotten root passwords.
The procedure for recovering from a forgotten password
varies with different releases. For OSR5 version 5.0.4, I found
that the following was successful using the system (mkdev fd) boot
mount /dev/hd0root /mnt
/mnt/bin/chroot /mnt /bin/su root
# at this point, you are logged in as root and sitting in the "/"
# directory of the hard drive
# change the password and do anything else you need to do.
# probably completely unnecessary!
If your hard drive crashed prior to this, you'll need to
before trying to munt it. You can boot from the install media
for OSR5: see //aplawrence.com/cgi-bin/ta.pl?arg=105312
For other versions, see Lost Root Password SCO Unix
The bootos program is used to load other partitions. To boot by
name, you either need to create an alias in /etc/default/boot (such
as "qnx=bootos 4") or, for the names that bootos already
understands (dos,nt,xenix, etc.: see "man bootos"), it is
sufficient to create a link from /stand/bootos to /stand/xenix (for
I haven't yet found the documentation that says what does this,
but /etc/uadmin seems a likely suspect:
# strings /etc/uadmin | grep default
Also undocumented is what triggers this copy to take place. Is
it the presence of the /dev/boot filesystem or merely the presence
of /stand? I don't know. Nor do I know how that
/stand/etc/default/boot.new referenced above is used.
Device drivers can lie
The output that appears during boot like
%dumtest 0x017C-0x0181 6 7 Test driver
comes from the driver, and it could be incorrect. This "dumtest"
output is from a driver I wrote that deliberately lies. Here's the
# compile with cc -o Driver.o -c -bcoff dummy.c
printcfg("dumtest",380,5,6,7,"Test driver",(char *)0);
printf("You'll get ");
printf("nothing from me.\n");
The driver was installed with
/etc/conf/bin/idinstall -ak dum
using these System and Master files:
dum Y 1 0 0 0 0 0 0 0
dum Iorc ic dum 0 0 0 1 -1
It actually doesn't use any port addresses, interrupts or dma, it
just says that it does.
To see this driver work, you'll need to extract it's major
number from /etc/conf/cf.d/mdevice (idinstall adds a new line there
when it runs) and then create a device node; for example
mknode /dev/mytest c 133 0
Then, "cat /dev/mytest" will trigger the driver's open, read, and
DMA (Direct Memory Access) is a function that allows some other
device to read or write memory directly without using the CPU.
Controllers that have 32 bit addressing (a SCSI controller will
indicate that by a "d" in the fts= string) can access memory above
16M, but controllers that don't, can't. All memory above 16M
automatically gets marked as /n.
This copies the code from /etc/masterboot onto the first sector
of the boot disk. That's an area where boot viruses try to install,
so your bios might have it locked against write. If that's the
case, you'd need to turn that protection off first.
A floppy gets searched for masterboot code also, but sometimes
there's no code there to execute- for example with a Unix formatted
diskette or even a diskette with data on it. If you attempt to boot
with a diskette like that, usually nothing happens- the machine
just hangs, apparently dead (some BIOS'es have enough sense to
check for valid code and proceed to the hard drive if they don't
find it). Depending on what's actually on the disk, other strange
things could happen- the screen could fill with repeating
characters, or the printer could get turned on, but usually it just
stops dead. People who are used to MSDOS are surprised by that
because they expect to see a message to insert a bootable disk.
That message doesn't generally come from the BIOS, however; it
comes from the "masterboot" code. MSDOS format routines add
"masterboot" code that doesn't boot, but does contain that helpful
message. That's just not there on a Unix diskette.
hdboot0 and hdboot1
The MSDOS analogues of these are IO.SYS and MSDOS.SYS. Unlike
SCO Unix, when you see those files on a DOS disk, you are looking
at the actual boot code, and it has to be specifically placed in
the right sectors by MSDOS format. If you removed those from that
DOS disk, it could not boot. Removing /etc/hdboot0 or /etc/hdboot1
from a SCO system would not affect boot.
/stand/boot (or /boot on systems without /stand fs) is a
real file, and removing that would have disastrous consequences.
That's when you'd really need your emergency boot floppy. Are yours
up to date and do you have more than one set?
You may only see "H" or some other letter on your screen, but
actually A through L have been displayed. These represent various
checks by the kernel, and if it should ever stop booting, knowing
what each letter means could help tell you what the problem might
be. There is a SCO technical article that hasn't been updated for
several years, but is probably still helpful: see TA 106055
/boot determines whether or not a program is "standalone"
(capable of running without kernel or library support) by examining
its header to see that it is, in fact, a standalone. The man page
for /etc/magic explains the concept, but /boot doesn't use this
file: what to look for is apparently hard-coded into it.
Yes, there is Microsoft code herein.
The code involved has to do with things like Xenix and the
"doscp" tools. All of this has been removed from Unixware, which
annoys some people but saves SCO a pile of licensing money.
Partitions contain file systems. If you want three or four file
systems, you only need one partition. You can only have 7 divisions
in a divvy table, so this means that the maximum number of
filesystems you could get on one hard drive is 28.
Partitions are referenced like this:
/dev/hd01: first partition
/dev/hd02: second partition
/dev/hd03: thrird partition
/dev/hd04: fourth partition
The file /dev/hd0a will always be the active partition, but it
isn't a link to one of the above: it has it's own minor number. See
"man HW hd" for details.
Read Only Memory. In this context, it's the memory that contains
the PC BIOS (Basic Input/Output System) or memory on an expansion
card. As the name implies, this is memory that can be read, but
can't be written to (though there may be special routines in the
BIOS that allow such memory to be changed for the purpose of
upgrading the BIOS). You can examine the under 1 meg memory on a
SCO machine using showmem.
The BIOS code finds ROM by sequentially reading through memory
and looking for the pattern 0x55 followed by 0xaa (it only looks
for this from 0xA0000 through 0xFFFFF because that's the only place
it should be).
To determine what's useable memory and what isn't, the "Sizing
Memory" code has to scan through the entire possible address space
to see what's available. It gets the "base" memory (under 1MB) from
a BIOS location, but it scans for the rest.
The "man HW boot" page tries to explain this, but I'm not sure I
understand what the significance of this is, so I'm not going to
try to guess.
Commands such as "link" and "bootos" are actually external
programs that /boot will load and pass control to. These programs
need to be specially compiled, because they cannot use kernel or
Using other Operating
In general, you need to install the other OS first. Your
OpenServer Handbook explains this in detail in the chapter "Using
other Operating Systems with an SCO system".
If you did that the other way around (installed SCO first) , you
can fix it by booting Windows, running fdisk to make the SCO
partion active, rebooting, and running "dparam -w" to rewrite the
MBR (that might not be necessary but it doesn't hurt).
However- Windows OS's have been known for being incredibly
stupid about the end of their partition during installation, and
will sometimes dumbly write into the next partition, so you may
want to make the slice you left for Windows a little smaller if it
precedes the SCO partition.
There are bigger problems if installing NT- basically you can't
do it unless you install NT first. I don't know yet what problems
there will be with Win2000.
The "wd.delay" bootstring was introduced with the RS504c release
supplement for 5.0.4. to correct a problem where the system would
delay for a long time searching for EIDE devices. Bela Lubkin
explained it in this way: (the original posting by Bela is
(link dead, sorry)
Finding ATAPI devices is a 2-step process. In the first step, the
driver sends a request to the bus to learn whether any ATAPI
devices are present. The answer to this request does not identify
how many ATAPI devices, nor on which position(s); only that at
least one is present.
If there are ATAPI devices present, the driver then sends requests
to both master & slave positions on that bus, asking them to
specifically identify themselves.
The ATAPI spec requires the operating system / device driver to
wait 30 seconds for a device to identify itself.
If an ATAPI device is actually present, it usually identifies
itself immediately. If a non-ATAPI device (like an EIDE hard disk)
is present, it immediately rejects the request. But if *no* device
is present at that position, there is no response, and the driver
waits the full 30 seconds required by the spec.
You generally see the delay only on IDE buses with one ATAPI device
and nothing else attached. If there were no ATAPI devices, the
driver would never send the 30-second query. If there were 2
devices, both would answer immediately.
By setting wd.delay, you are intentionally overriding this portion
of the ATAPI spec. *You* know there isn't a slow ATAPI device in
that empty position. You would need to increase the delay only if,
when adding a ATAPI device, you found that it wasn't recognized. I
think that's unlikely because no devices actually take advantage of
the 30-second pause allowed by the spec. (If they did, they
probably wouldn't work with the ATAPI drivers in any other
operating system, so how likely is it that they'd ever get
Any of the Intel processors (and their clones) including
8086,80286,80386, 80486 and the Pentiums. See also The Processor & Coprocessor and Pentium Pro Processor System