UNIX system loader
boot is the first interactive program to be
executed at system startup. It is loaded by the system
BIOS, and its primary purpose is to load the
When boot loads, it first executes any commands
in /.bootrc. Then it presents a prompt on the
console. If the user presses <Enter> or if no
commands are typed at the prompt after a timeout interval,
boot executes the default string in
boot cannot load and execute normal UNIX
programs. However, there are a few special executables that
boot can load (including the kernel). In
addition, boot has a number of built-in commands
and variables, so it acts as an interpreter for a simple
boot may be executed from a floppy disk, a hard
disk partition, or a RAM disk on a diskless
workstation (which is loaded over a network from a
How boot interprets commands
Like the shells, boot attempts to execute any
command typed at the boot prompt. However, boot's
syntactic conventions differ from the shells. In the
absence of any other arguments, pressing <Enter>
makes boot try to execute the default bootstring
as specified in /etc/default/boot.
Boot parses a command line into a series of strings (termed
bootstrings) that may be commands to execute, or arguments
to commands. When you type a command, boot
checks the first item to see if it is a recognized internal
command. If it is recognized, it is executed; if not,
boot checks to see if it is an alias, resolves
the alias (if it is one), appends any other arguments on
the command line to the expanded alias, and attempts to
execute the resulting line as a program.
There is one special alias, defbootstr, defined
in /etc/default/boot. This specifies the default
string. If <Enter> is pressed (with no other
commands), boot executes defbootstr.
defbootstr is usually defined as the UNIX
kernel. (This is why boot usually loads the
kernel if you press <Enter> at the boot prompt.)
Aliases are defined in the defaults file (see
). Definitions take the form:
command [ = ] definition
ALTDEF [ = ] filename
The first form defines command as an alias for definition.
The second form specifies that boot should scan filename
for alternative alias definitions.
Configuring the boot environment
There are two methods of changing the default behavior of boot.
The file /etc/default/boot is used to alter the initial
values of certain variables, while the .bootrc file allows
the user to always run one or more commands before boot
displays the command prompt.
Once boot has initialized its internal variables, but
before it initializes the console, it reads /etc/default/boot.
This contains a list of keyword=value commands
that modify the internal variables. (The keywords are not case sensitive.)
The following keywords are recognized:
Specifies an alternative file from /etc/default/boot. The
alternate file is loaded and scanned for keywords.
Specifies whether boot times out and brings the system up
automatically in the absence of user input. If AUTOBOOT is set
to YES, then if no keyboard input is received within a timeout value,
boot will behave as if a user pressed <Enter>: that is, the
default bootstring will be executed. If AUTOBOOT is set
to NO, boot never times out.
Specifies the communication parameters to use when the console in use
is a serial terminal. The values accepted are a subset of the values
and allow the speed and line characteristics (start, stop, data bits, and
parity) to be set.
Specifies the console to use by default. This can be either the graphics
console (SYSTTY=0), or a serial console (SYSTTY=1)
attached to the first serial port.
Specifies the length of time in seconds to wait for user input before
automatically booting. A value of 0 causes boot to execute
the default command immediately if AUTOBOOT is set to YES.
The .bootrc file, if present, is executed after the console
has been initialized, but before the prompt is displayed. It is
especially useful in network installations, where a packet driver and
tftp driver may have to be loaded before the user can successfully
load a kernel.
Lines are read from the file and executed as if they had been typed at
the console except they do not go through the aliasing described in
``How boot interprets commands'',
and built-in commands cannot be executed.
Blank lines or lines beginning with ``#'' are ignored. Commands
cannot be continued onto the next line, and are limited to 255 characters
The command line options below allow the user to change the default
behavior of boot:
Specify the device from which boot-time loadable driver packages are loaded.
The default is the media from which boot was loaded. Please see the
manual page for details.
Override the primary hard disk geometry stored in the
BIOS. With no arguments, biosgeom reports the
The 486 and Pentium processors have an internal on-chip memory cache
(level-one or L1 cache) and an optional external memory cache
(level-two or L2 cache).
If your machine will not size memory or boot correctly,
you may need to adjust the behavior of the caches
using the following flags:
Flush the L1 and L2 caches (default).
Disable L1 and L2 cache flushing.
Booting will take less time if flushing is disabled;
however, this may cause some machines to
size memory incorrectly or to fail to boot.
Allow the WBINVD
instruction to be used while scanning memory
(WBINVD writes back and invalidates
data in the L2 cache).
This is the default behavior except on
some multiprocessor systems which are known to have problems
with the implementation of WBINVD.
boot normally disables the use of WBINVD
and cache flushing (see the description of the /d flag)
on such systems.
Do not allow the WBINVD
instruction to be used during memory scan.
You may need to specify this flag on some multiprocessor systems which
size memory incorrectly or which fail to boot.
Such problems may be due to an error in the implementation
If /o is specified,
/d should normally also be specified to disable
Enable the L1 cache before loading the kernel (default).
Machine performance is enhanced if caching is enabled.
Disable the L1 cache.
This may be necessary for some machines where there are problems with
cache coherence (this occurs when DMA does not notify
the internal cache that memory has been written to directly).
Disables reporting of Machine Check exceptions.
Report Machine Check exceptions but take no action in response.
A number of special options are available as arguments to mem.
These adjust the amount of memory that boot is aware of, in
various ways; see
``Boot memory management''
The amount of low memory (memory below 1Mb) is held in a
BIOS variable. This variable is reported directly to the
kernel as the amount of memory present in the machine. Generally, this
is 640KB, but it may be reduced by one or 2KB if an extended
BIOS data area is present. (The EBDA, if present,
is not reclaimed, so that DOS emulators such as Merge can access
Uses PCI BIOS ROM 32-bit routines,
if the BIOS supports them, instead of accessing
the hardware directly.
Early versions of the Phoenix 486 EISA BIOS caused
the caller's stack to be corrupted while copying data into high
memory. To work around this problem, the option phoenix486
can be added as a parameter to the boot command line.
prompt [ ="string" ]
boot prints the string and waits for you to
press <Enter> after loading the external program (to which prompt is
Specify the path to a ramdisk image. (If no path is specified, the
ramdisk command fails.)
The ramdisk image may then be loaded and used as a root device.
ramdisk may also be used as an argument to
an external command.
ramdiskprompt [ ="string" ]
boot prints the string and waits for you to
press <Enter>, which you should do
after you have inserted the disk containing the ramdisk.
Internal boot commands
The following commands are built into boot. Unlike the commands
described above, they do not change boot's default behavior:
Lists the devices boot knows about; boot
can only load programs and boot-linked
driver packages from these devices.
Enters the boot debugger. See
dir [ directory ]
Lists the files in directory;
the default is the root of the filesystem from which boot
link [ program [ arguments ] ... ]
Causes boot to prompt for a list of packages to link to
program as it is executed. (This is used for installing
device drivers that are not part of the kernel; see the
manual page for details.)
Alternatively, the argument
link="package list" may be used to specify
the packages to be linked into the program identified by defbootstr.
Specifies the system console used by the UNIX kernel.
Display version information for boot.
External boot commands
boot cannot load and execute ordinary UNIX programs. However,
certain external programs can be executed. These are the kernel, plus
Command line arguments that boot does not recognize are
passed to the external program as parameters.
The system kernel, /unix, the arguments for which are specified
This is usually the default file specified by the
Allows loading of operating systems from partitions other than the
currently active one. Typing bootos ? lists all the
partitions on the primary hard disk, and the type of operating
system they are thought to contain.
Allows low-level formatting of hard disks connected via an OMTI
controller. This functionality is now provided by the boot debugger, but
the program is retained for backwards compatibility.
How boot locates files
The pathname of the program to
be loaded and the device on which it can be found are
specified in one of the following ways, where
pathname is a standard UNIX system pathname,
given relative to the filesystem's root directory,
and all numbers are in decimal:
Load the file from the default device (as shown by the ``?''
Load the file from the device with internal name xnamex,
corresponding to the first field of
and the given minor device number.
An optional filesystem offset may also be specified;
the default is 0.
For example, hd(40) specifies the
boot filesystem on the primary hard disk;
fd(64) specifies the boot
filesystem on the first floppy drive.
Note that the system can only load a file from floppy and hard disk devices
(fd and hd).
for details of the minor device numbering schemes for these devices.
Load a file across a TCP/IP network. The host is specified by
its dotted IP address consisting of four decimal numbers.
For example, net(127.6.8.45)/unix specifies the file
/unix on the host with IP address 127.6.8.45.
Boot media options
The bootstrap process is defined by the system BIOS. The
BIOS lives in the memory range 640KB to 1024KB, and is the first
code executed when the machine is powered up. It goes through the following
sequence of steps:
Additional BIOS code is held on cards such as SCSI
disk controllers and network boot PROMs, as well as the
video controller. These typically emulate existing BIOS
functions (such as the floppy disk services) by intercepting the
call to the system BIOS for peripherals attached via these
Executes a Power-On Self-Test (POST).
Sets up internal variables, determines the available memory.
Scans for add-on card BIOS ROM and executes
the add-on BIOS routines.
Executes the code located in the software bootstrap vector.
The code in the bootstrap vector searches for an executable boot sector.
When it finds one, it copies the sector into memory and executes it.
Devices are generally searched in the following order:
At this point, the operating system comes into operation.
Three different boot sectors are used
to support booting from the three different media.
Each of them has the same aim; to load boot.
Active partition of primary hard disk
The bootstrap programs are as follows:
The floppy boot program is called fdboot0. It occupies two
sectors. The first sector is located on sector 0, and is the only part
loaded by the BIOS boot process; the first thing it does
on loading is to locate and load the second sector from the floppy.
The location of the second sector varies depending on the filesystem
type. For XENIX filesystems, it lives at physical sector 1. For S51K
family filesystems (S51K, AFS, EAFS) it lives at physical sector 2.
The sector to be loaded is determined by a magic number in the second
boot sector. Physical sector 1 is loaded and checked; if it does not
contain the magic number, physical sector 2 is loaded and checked.
fdboot0 understands the XENIX and S51K filesystem types. It
loads inode 2 from the media, which contains the root directory. This
is parsed to locate the inode for boot. boot is
then loaded into memory, the default device is written into the start of
boot, and control is passed to the program.
Different versions of fdboot0 exist for each different
floppy type supported. This is because the drive geometry is hard-coded
into fdboot0 (to permit it to search the boot device). The
master copies of the different floppy boot programs are stored in
/etc, and are named fdboot, where
stands for the geometry of the disk they support. (For example,
fd135ds18boot is the fdboot0 for high density,
3.5 inch floppy disk drives.)
On diskless systems, boot runs off a ramdisk and loads the system
over a network.
The ramdisk bootstrap process is a variant on the floppy boostrap. The
network boot PROM BIOS redirects the system bootstrap
vector and the floppy vectors of the system BIOS to point to
code within the PROM. A RAM disk image is loaded into
memory by the boot PROM using tftp. Control is
then passed to the system BIOS. It goes through the same process
to locate boot, but calls are redirected from the primary floppy
device to the RAM disk.
The hard disk can be split into up to four partitions, each of which
can contain an operating system. The BIOS is not aware of
partitioning, and loads sector 0 of the disk. This contains the
masterboot software, which scans the disk partition table for the
active partition. The masterboot then loads logical sector 0 from the
active partition, and passes control to it.
The masterboot software can boot arbitrary partitions,
unlike some other operating systems.
It also contains the geometry information
for hard disks which are too large
for the BIOS to access properly.
Masterboot loads a program called hdboot0. This loads the next
stage, hdboot1, which resides at logical block 3 of the same
partition. It then loads 20KB of contiguous data.
hdboot1 recognizes the XENIX
and S51K-family filesystem layouts
sufficiently well to handle bad blocks, division tables, and the filesystem.
It locates boot and loads it from the root filesystem.
On systems configured to use HTFS or DTFS
boot resides on a special small filesystem, the boot
filesystem, along with /etc/default/boot, .bootrc,
the loadable kernel images, and a few other ancillary files. When
the system is running, the boot filesystem is mounted on /stand.
locate files stored on this filesystem, or on any of the standard
UNIX filesystems (but not on DTFS or HTFS
filesystems). boot can also load files from other
devices and over a TCP/IP network.
Boot memory management
boot attempts to automatically determine how much RAM
is in the machine, and where it is located.
On most systems this automatic search succeeds in finding the memory.
However, on some machines the search does not find all the available memory,
or ``finds'' memory which does not actually exist (or which should
not or cannot actually be used).
It is possible to control where, and how, boot searches for
RAM by using either the mem=standalone
command or bootstring argument:
mem= [ range ] [ flag ] ... [ , ... ]
The (optional) range is either:
All ranges must be specified so that the start and end addresses of each
range are aligned on 4KB (page) boundaries.
start - end
The memory begins at address start and ends prior to address
If the end is prior to the start,
the two addresses are exchanged and the /d flag
start + size
The memory begins at address start and continues for at most
size bytes. (So end is equivalent to
start + size.)
The start and end addresses, and the size,
are specified in either kilobytes (1024 bytes per kilobyte)
or megabytes (1024 kilobytes per megabyte); a suffix of k
is kilobytes, and m is megabytes.
For example, all of the following mean the 2MB
starting at address 1MB:
The k or m suffix is required.
The (optional) flags are:
All memory below 640k is automatically determined by the machine,
and there is never any memory in the range 640k-1m.
All mem= descriptions of this ``base memory'' below
1m are silently ignored.
should only be used to specify the extended memory configuration at and above
This memory range is not DMAable. All memory
above 16m is automatically marked
non-DMAable. Only the standalone
program's text is placed in non-DMAable memory by
This memory should be scanned downwards (from the
end towards the start address);
normally boot verifies the memory range
by scanning from the start towards the
end. Specifying /d is equivalent to
giving an end address lower than the
This memory range is reserved; boot must not load
any part of the standalone program into it. However, the
memory is available for use by the UNIX system. (To hide
memory from both boot and the UNIX system, do
not include it in any range.)
This memory is ``special'' and is best used to load the
standalone program's text (not data) section. ``Shadow
RAM'' usually should be so marked, but shadowing
RAM can only be used if the shadowing feature is
disabled: that is, if the shadow RAM is hidden
by a ``shadowed'' copy of the machine's startup
ROM, then the underlying RAM is
inaccessible to both boot and the UNIX kernel
and must not be used. Only the standalone program's text
is placed in ``special'' memory by boot.
The UNIX kernel's text must be loaded below 16m;
this flag is recommended when booting earlier releases (that is,
versions earlier than Release 3.2 Version 4.0) of SCO UNIX.
Print a concise summary of the RAM found.
This summary can be written down and used as the
mem=input on a later attempt to force boot
to find the same memory it found on this boot
(provided none of the described RAM
was removed in the meantime).
boot may also display /p as part of the concise
summary to indicate private memory reserved by the BIOS.
The default mem= specification is equivalent to:
on most machines (plus up to 640KB of base memory).
boot scans each range and 16m-256m
by default, stopping its scan as soon as no memory can be found.
Thus, if there is a ``hole'' in the specified memory range,
all RAM above the first hole in the range will not be found by
Consider a machine with:
By default, boot would only find:
512KB of base memory,
extended RAM from one to 3MB,
some additional RAM from 10 to 20MB,
50KB of shadow RAM
ending at 32MB (shadowing disabled).
Most of the RAM -- the 6MB starting
at address 10MB -- is not found (due to the
hole starting at address 3MB). On such a
machine, it is advisable to define the memory which really
512KB of base memory,
extended RAM from 1 to 3MB, and
additional RAM from 16 to 20MB.
This machine can be specified as:
Note that 32720k is the address starting
48k before 32m (since memory ranges
must be aligned on 4KB boundaries). Since all
memory above 16m is automatically marked as
non-DMAable, the above is equivalent to:
A simple mem=/p will print out the memory found
automatically. For the example machine, this is:
Memory found: 0k-512k,1m-3m,16m-20m/n
To print out the memory found for a specific configuration,
/p must be included in the mem=
specification. Thus, adding /p to the first
would print out the equivalent of the second definition (on
the described machine):
On most machines boot scans the defined memory
ranges and deletes from the definition any RAM
not actually found. Thus, if the following is specified on
the described machine:
the printed result would be:
Note that the RAM from 10 to 12MB,
despite existing, was not found by boot, because
it was excluded from the mem= definition.
On most machines, shadowing must be disabled using the
machine's setup procedures. boot automatically
disables startup ROM shadowing only on a few
machines. The RAM hidden by shadowing the
startup ROM cannot be used by boot or
the UNIX kernel unless the shadowing is disabled.
If your machine has extended memory,
you will see the following message on booting:
boot then outputs a series of dots as it sizes memory.
Memory sizing may take considerable time
if boot has to check a large amount of memory.
If you specified mem=/p at the Boot
prompt or in the file /etc/default/boot,
a summary of the memory found is printed
when sizing has finished.
boot loads the kernel after it has successfully determined
the amount of memory available, as shown in this example:
Memory found: 0k-640k,1m-16m,16m-20m/n
Loading kernel hd(40)unix .text
Loading kernel hd(40)unix .data
Loading kernel hd(40)unix .bss
System loaded, press <Return> to start:
The following lists contain the most common messages and their meanings.
An error occurred when masterboot
tried to read in the partition boot
of the active operating system.
The operating system lies on a cylinder greater than 1024;
masterboot cannot load it.
The bootable partition indicator of at least
one of the operating systems in the fdisk table
contains an unrecognizable code.
There was an unrecoverable error that prevented the
active operating system's partition boot from executing, or there
was no active partition.
hdboot0 was unable to load and execute /boot.
Some component of /boot (indicated by param) caused
an error while hdboot0 was loading it.
Stage 1 boot failure
The bootstrap loader cannot find or read the boot file.
You must restart the computer and supply a filesystem disk
with the boot file in the root directory.
hdboot1 and boot errors
displays error messages, it returns to the ``Boot:'' prompt.
The following is a list of the most common messages
and their meanings:
bad magic number
The given file is not an executable program.
can't open <pathname
The supplied pathname does not correspond to an existing file,
or the device is unknown.
COFF files not supported as standalone programs
The given file is executable only on a running system, not by boot.
Command line too long - aborting
boot attempted to process a line more than 256 characters long.
Error: request outside range of BIOS (1023 cylinders)
The low level hard disk transfer routine was unable to load a file because
it lay on or beyond the 1024th cylinder of the boot device. This message
is usually followed by another error message indicating the file
which was being read when the failure occurred. The boot prompt is then
The problem occurs when the kernel or /etc/default/boot
are inaccessible to the BIOS disk transfer routine which is
used to read the hard disk.
This problem only occurs on large disk systems.
The solution is to move the file so that it lies within
the first 1024 cylinders on the boot device.
Failed to reopen .bootrc
An error occurred while reading .bootrc.
Failed to reposition filepointer
An error occurred while processing .bootrc.
An attempted read of x bytes of the file returned only
This is probably due to a premature end-of-file.
It could also be caused by a corrupted file, or incorrect word
ordering in the header.
Header read error:
boot failed to identify an external binary program as
being one suitable for execution.
not a directory
The specified area on the device does not contain a valid
UNIX filesystem, or the given pathname tries to pass through a file
(for example, /bin/sh/foo).
zero length directory
Although an otherwise valid filesystem was found, it
contains a directory of apparently zero length. This most
often occurs when a pre-System V UNIX filesystem (with
incorrect, or incompatible word ordering) is in the
The following files are images of boot sectors or blocks
used on different media types:
The following are standalone programs executable by boot:
Information about developing device drivers
is available at the
Consolidated Hardware Development (HDK) Web Page
boot is not part of any currently supported
standard; it is an extension provided for SCO OpenServer.
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003