Booting OSR5

Footnotes and Definitions for OSR5 Boot articles

  • GiB

    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
  • 0xffff0

    That's 16 bytes below the 1 megabye physical limit of the X86 in real mode. This is expressed in hexadecimal notation (notice the leading "0x").

  • 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 floppies:

    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

    fsck /dev/hd0root

    before trying to munt it. You can boot from the install media for OSR5: see //

    For other versions, see Lost Root Password SCO Unix

  • bootos

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

  • Copying /etc/default/boot

    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/ 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 source:
    #include <sys/types.h>
    #include <sys/cmn_err.h>
    # compile with cc -o Driver.o -c -bcoff dummy.c
    duminit() {
            printcfg("dumtest",380,5,6,7,"Test driver",(char *)0);
    dumopen() {
            printf("You'll get ");
    dumread() {
            printf("nothing from me.\n");
    dumclose() {
    The driver was installed with
    /etc/conf/bin/idinstall -ak dum
    using these System and Master files:
    # System
    dum     Y       1       0       0       0       0       0       0       0
    # Master
    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 close routines.
  • DMAable memory

    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.

  • dparam -w

    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.

  • Floppy Boot

    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?

  • Boot Leters

    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

  • Magic numbers

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

  • Microsoft

    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

    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.
  • ROM

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

  • Sizing Memory

    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.

  • "special" memory

    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.

  • standalone programs

    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 library routines.

  • Using other Operating Systems

    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.

  • wd.delay

    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 available from[LBURL=_LBHTwww.aplawrence.com_LBFS,]/threadmsg_ct.xp?AN=296805627 (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
  • X86 Processor

    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 Architecture

© September 1999 A.P. Lawrence. All rights reserved

Got something to add? Send me email.

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Tony Lawrence

Kerio Samepage

Have you tried Searching this site?

Support Rates

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