boot(8)

NAME

boot - system bootstrapping procedures

DESCRIPTION

Power fail and crash recovery. Normally, the system will

reboot itself
at power-up or after crashes. An automatic consistency

check of the file
systems will be performed, and unless this fails, the system

will resume
multi-user operations.

Cold starts. Most i386 PCs attempt to boot first from flop

py disk drive
0 (sometimes known as drive A:) and, failing that, from hard

disk drive 0
(sometimes known as drive C:, or as drive 0x80 to the BIOS).

Some BIOSes
allow you to change this default sequence, and may also in

clude a CD-ROM
drive as a boot device.

By default, a three-stage bootstrap is employed, and control

is automatically passed from the boot blocks (bootstrap stages one and

two) to a
separate third-stage bootstrap program, loader(8). This

third stage provides more sophisticated control over the booting process

than it is possible to achieve in the boot blocks, which are constrained

by occupying
limited fixed space on a given disk or slice.

However, it is possible to dispense with the third stage al

together,
either by specifying a kernel name in the boot block parame

ter file,
/boot.config, or, unless option -n is set, by hitting a key

during a
brief pause (while one of the characters -, |, or / is dis

played)
before loader(8) is invoked. Booting will also be attempted

at stage
two, if the third stage cannot be loaded.

Make note of the fact that /boot.config is read only from

the `a' partition. As a result, slices which are missing an `a' parti

tion require
user intervention during the boot process.

The remainder of this subsection deals only with the boot

blocks. The
loader(8) program is documented separately.

After the boot blocks have been loaded, you should see a

prompt similar
to the following:

>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/boot/loader
boot:

The automatic boot will attempt to load /boot/loader from

partition `a'
of either the floppy or the hard disk. This boot may be

aborted by typing any character on the keyboard at the `boot:' prompt. At

this time,
the following input will be accepted:

? Give a short listing of the files in the root direc

tory of the

default boot device, as a hint about available boot

files. (A ?
may also be specified as the last segment of a path,

in which
case the listing will be of the relevant subdirecto

ry.)

bios_drive:interface(unit,[slice,]part)filename

[-aCcDdghmnPprsv]

[-Sspeed]
Specify boot file and flags.

bios_drive

The drive number as recognized by the BIOS.

0 for the
first drive, 1 for the second drive, etc.

interface

The type of controller to boot from. Note

that the controller is required to have BIOS support

since the BIOS
services are used to load the boot file im

age.

The supported interfaces are:

ad ST506, IDE, ESDI, RLL disks on a

WD100[2367] or

lookalike controller

fd 5 1/4" or 3 1/2" High density floppies
da SCSI disk on any supported SCSI con

troller

unit The unit number of the drive on the inter

face being used.

0 for the first drive, 1 for the second

drive, etc.

[slice,]part

The partition letter inside the BSD portion

of the disk.
See bsdlabel(8). By convention, only parti

tion `a' contains a bootable image. If sliced disks are

used
(``fdisk partitions''), any slice (1 for the

first slice,
2 for the second slice, etc.) can be booted

from, with
the default (if not specified) being the ac

tive slice or,
otherwise, the first FreeBSD slice. If

slice is specified as 0, the first FreeBSD slice (also

known as
``compatibility'' slice) is booted from.

filename

The pathname of the file to boot (relative

to the root
directory on the specified partition). De

faults to
/boot/kernel/kernel. Symbolic links are not

supported
(hard links are).

[-aCcDdghmnPpqrsv] [-Sspeed]

Boot flags:

-a during kernel initialization, ask for

the device to

mount as the root file system.

-C try to mount root file system from a

CD-ROM.
-c this flag is currently a no-op.
-D boot with the dual console configura

tion. In the

single configuration, the console will

be either
the internal display or the serial

port, depending
on the state of the -h option below.

In the dual
console configuration, both the inter

nal display
and the serial port will become the

console at the
same time, regardless of the state of

the -h
option.

-d enter the DDB kernel debugger (see

ddb(4)) as early

as possible in kernel initialization.

-g use the GDB remote debugging protocol.
-h force the serial console. For in

stance, if you

boot from the internal console, you

can use the -h
option to force the kernel to use the

serial port
as its console device. The serial

port driver
sio(4) has a flag (0x20) to override

this option.
If that flag is set, the serial port

will always be
used as the console, regardless of the

-h option
described here. See the man page for

sio(4) for
more details.

-m mute the console to suppress all con

sole input and

output during the boot.

-n ignore key press to interrupt boot be

fore loader(8)

is invoked.

-P probe the keyboard. If no keyboard is

found, the

-D and -h options are automatically

set.

-p pause after each attached device dur

ing the device

probing phase.

-q be quiet, do not write anything to the

console

unless automatic boot fails or is dis

abled. This
option only affects second-stage boot

strap, to prevent next stages from writing to the

console use in
combination with the -m option.

-r use the statically configured default

for the

device containing the root file system

(see
config(8)). Normally, the root file

system is on
the device that the kernel was loaded

from.

-s boot into single-user mode; if the

console is

marked as ``insecure'' (see ttys(5)),

the root
password must be entered.

-Sspeed

set the speed of the serial console to

speed. The
default is 9600 unless it has been

overridden by
setting BOOT_COMCONSOLE_SPEED in

make.conf(5) and
recompiling and reinstalling the boot

blocks.

-v be verbose during device probing (and

later).

You may put a BIOS drive number, a controller type, a unit

number, a partition, a kernel file name, and any valid option in

/boot.config to set
defaults. Enter them in one line just as you type at the

`boot:' prompt.

FILES

/boot.config parameters for the boot blocks (optional)
/boot/boot1 first stage bootstrap file
/boot/boot2 second stage bootstrap file
/boot/loader third stage bootstrap
/boot/kernel/kernel

default kernel

/boot/kernel.old/kernel

typical non-default kernel (optional)

DIAGNOSTICS

When disk-related errors occur, these are reported by the

second-stage
bootstrap using the same error codes returned by the BIOS,

for example
``Disk error 0x1 (lba=0x12345678)''. Here is a partial list

of these
error codes:

0x1 Invalid argument
0x2 Address mark not found
0x4 Sector not found
0x8 DMA overrun
0x9 DMA attempt across 64K boundary
0xc Invalid media
0x10 Uncorrectable CRC/ECC error
0x20 Controller failure
0x40 Seek failed
0x80 Timeout

NOTE: On older machines, or otherwise where EDD support

(disk packet
interface support) is not available, all boot-related files

and structures (including the kernel) that need to be accessed during

the boot
phase must reside on the disk at or below cylinder 1023 (as

the BIOS
understands the geometry). When a ``Disk error 0x1'' is re

ported by the
second-stage bootstrap, it generally means that this re

quirement has not
been adhered to.

SEE ALSO

ddb(4), make.conf(5), ttys(5), boot0cfg(8), bsdlabel(8),

btxld(8),
config(8), halt(8), loader(8), reboot(8), shutdown(8)

BUGS

The bsdlabel(5) format used by this version of BSD is quite

different
from that of other architectures.

Due to space constraints, the keyboard probe initiated by

the -P option
is simply a test that the BIOS has detected an ``extended''

keyboard. If
an ``XT/AT'' keyboard (with no F11 and F12 keys, etc.) is

attached, the
probe will fail.

BSD August 18, 2005

BSD