boot(HW)

boot -- UNIX system loader

Description

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 UNIX kernel.

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 /etc/default/boot.

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

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

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

Boot aliases

Aliases are defined in the defaults file (see boot(F) ). Definitions take the form:

command [ = ] definition

or

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:

ALTDEF: Specifies an alternative file from /etc/default/boot. The alternate file is loaded and scanned for keywords.
AUTOBOOT: 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.
SERIAL: Specifies the communication parameters to use when the console in use is a serial terminal. The values accepted are a subset of the values in gettydefs(F) and allow the speed and line characteristics (start, stop, data bits, and parity) to be set.
SYSTTY: 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.
TIMEOUT: 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 in length.

Options

The command line options below allow the user to change the default behavior of boot:

btld

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 link(HW) manual page for details.

biosgeom[=(cylinders,heads,sectors)]

Override the primary hard disk geometry stored in the BIOS. With no arguments, biosgeom reports the geometry.

cache=[/e|/d][/i|/o][/y|/n]

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:

/e: Flush the L1 and L2 caches (default).
/d: 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.
/i: 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.
/o: 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 of WBINVD. If /o is specified, /d should normally also be specified to disable cache flushing.
/y: Enable the L1 cache before loading the kernel (default). Machine performance is enhanced if caching is enabled.
/n: 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).

mcheck.disable

Disables reporting of Machine Check exceptions.

mcheck.soft

Report Machine Check exceptions but take no action in response.

mem

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'' for details.

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

pci.bios32

Uses PCI BIOS ROM 32-bit routines, if the BIOS supports them, instead of accessing the hardware directly.

phoenix486

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

ramdisk=path

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.
debug: Enters the boot debugger. See debug(HW) for details.
dir [ directory ]: Lists the files in directory; the default is the root of the filesystem from which boot was loaded.
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 link(HW) 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.
systty=digit: Specifies the system console used by the UNIX kernel.
version: 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 special programs:

unix: The system kernel, /unix, the arguments for which are specified on bootstring(HW). This is usually the default file specified by the alias defbootstr.
bootos(HW): 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.
sfmt: 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.

Command line arguments that boot does not recognize are passed to the external program as parameters.

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:

pathname: Load the file from the default device (as shown by the ``?'' command).
xnamex(minor[,offset])pathname: Load the file from the device with internal name xnamex, corresponding to the first field of mdevice(F), 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). See hd(HW) and fd(HW) for details of the minor device numbering schemes for these devices.
net(IP_address)pathname: 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:

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.

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

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:

Network card
Primary floppy
Active partition of primary hard disk

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.

The bootstrap programs are as follows:

floppy

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

ramdisk

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.

hard 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 (TM) or DTFS (TM) filesystems, 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. Boot can 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:

start - end: The memory begins at address start and ends prior to address end. If the end is prior to the start, the two addresses are exchanged and the /d flag is assumed.
start + size: The memory begins at address start and continues for at most size bytes. (So end is equivalent to start + size.)

All ranges must be specified so that the start and end addresses of each range are aligned on 4KB (page) boundaries.

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:

   1m-3m
   1m+2m
   1024k-3m
   1m+2048k

The k or m suffix is required.

The (optional) flags are:

/n: 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 boot.
/d: 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 start address.
/r: 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.)
/s: 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.
/L: 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.
/p: 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.

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. Hence, mem= should only be used to specify the extended memory configuration at and above 1m.

The default mem= specification is equivalent to:

   mem=1m-16m,16m-256m/n

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

Consider a machine with:

512KB of base memory,
extended RAM from one to 3MB,
some additional RAM from 10 to 20MB, and
50KB of shadow RAM ending at 32MB (shadowing disabled).

By default, boot would only find:

512KB of base memory,
extended RAM from 1 to 3MB, and
additional RAM from 16 to 20MB.

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

This machine can be specified as:

   mem=1m-3m,10m-20m,32720k-32m/d/s

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:

   mem=1m-3m,10m-16m,16m-20m/n,32720k-32m/d/s

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 specification above:

mem=1m-3m,10m-20m,32720k-32m/d/s,/p

would print out the equivalent of the second definition (on the described machine):

   Memory found:
   0k-512k,1m-3m,10m-16m,16m-20m/n,32720k-32m/d/s

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:

mem=1m-5m,12m-25m,31m+1m/d/s,/p

the printed result would be:

   Memory found:
   0k-512k,1m-3m,12m-16m,16m-20m/n,32720k-32m/d/s

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:

Memory sizing

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:

Boot :unix mem=/p

Memory sizing ................... 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:

Diagnostics

The following lists contain the most common messages and their meanings.

masterboot errors

IO ERR: An error occurred when masterboot tried to read in the partition boot of the active operating system.
CYL OVF: The operating system lies on a cylinder greater than 1024; masterboot cannot load it.
BAD TBL: The bootable partition indicator of at least one of the operating systems in the fdisk table contains an unrecognizable code.
NO OS: There was an unrecoverable error that prevented the active operating system's partition boot from executing, or there was no active partition.

hdboot0 errors

cannot open: hdboot0 was unable to load and execute /boot.
Bad param: 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

When boot 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 displayed. 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.
fload:read(x)=y: An attempted read of x bytes of the file returned only y bytes. 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 specified area.

Files

The following files are images of boot sectors or blocks used on different media types:

/etc/default/boot
/etc/hdboot0
/etc/hdboot1
/etc/fd135ds18boot0
/etc/fd135ds9boot0
/etc/fd48ds9boot0
/etc/fd96ds15boot0
/etc/fd96ds18boot0
/etc/fd96ds9boot0
/etc/masterboot

The following are standalone programs executable by boot:

/link
/bootos
/dos
/unix

Standards conformance

boot is not part of any currently supported standard; it is an extension provided for SCO OpenServer.