DragonFly On-Line Manual Pages
BOOT(8) DragonFly/i386 System Manager's Manual BOOT(8)
boot -- system bootstrapping procedures
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
Cold starts. Most i386 PCs attempt to boot first from floppy 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 include a CD-ROM
drive as a boot device.
By default, a three-stage bootstrap is employed, and control is automati-
cally passed from the boot blocks (bootstrap stages one and two) to a
separate third-stage bootstrap program, loader(8). This third stage pro-
vides more sophisticated control over the booting process than it is pos-
sible 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 altogether,
either by specifying a kernel name in the boot block parameter file,
/boot.config, or, unless option -n is set, by hitting a key during a
brief pause (while one of the characters -, \, |, or / is displayed)
before loader(8) is invoked. Booting will also be attempted at stage
two, if the third stage cannot be loaded.
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:
The automatic boot will attempt to load /boot/loader and if that fails
/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 directory 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 subdirectory.)
bios_drive:interface(unit,part) filename [-aCcDdghmnPprsVv]
Specify boot file and flags.
The drive number as recognized by the BIOS. 0 for the
first drive, 1 for the second drive, etc.
The type of controller to boot from. Note that the con-
troller is required to have BIOS support since the BIOS
services are used to load the boot file image.
The supported interfaces are:
ad ST506, IDE, ESDI, RLL disks on a WD100 or
fd 5 1/4" or 3 1/2" High density floppies
da SCSI disk on any supported SCSI controller
unit The unit number of the drive on the interface being used.
0 for the first drive, 1 for the second drive, etc.
part The partition letter inside the BSD portion of the disk.
See disklabel(8). By convention, only partition `a' con-
tains a bootable image. If sliced disks are used
(``fdisk partitions''), any slice can be booted from,
with the default being the active slice or, otherwise,
the first DragonFly slice.
The pathname of the file to boot (relative to the root
directory on the specified partition). Defaults to
/boot/kernel. Symbolic links are not supported (hard
-a during kernel initialization, ask for the device to
mount as the root file system.
-C boot from CDROM.
-c run UserConfig to modify hardware parameters for
the loaded kernel. If the kernel was built with
one of USERCONFIG, INTRO_USERCONFIG,
VISUAL_USERCONFIG options, remain in UserConfig
regardless of any quit commands present in the
-D Use all available consoles as the system console.
Input will be accepted on any console and output
will be routed to all of them. This is the
-h Use the serial console as the system console.
-V Use the video console as the system console.
-m Mute the system console. None of the console
devices will be used for the system console.
-d enter the DDB kernel debugger (see ddb(4)) as early
as possible in kernel initialization.
-g use the GDB remote debugging protocol.
-n ignore key press to interrupt boot before loader(8)
-P probe the keyboard. If no keyboard is found, the
-D and -h options are automatically set.
-p pause after each attached device during the device
-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.
-v be verbose during device probing (and later).
You may put a BIOS drive number, a controller type, a unit number, a par-
tition, 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.
/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 default kernel
typical non-default kernel (optional)
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
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
NOTE: On older machines, or otherwise where EDD support (disk packet
interface support) is not available, all boot-related files and struc-
tures (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 reported by the
second-stage bootstrap, it generally means that this requirement has not
been adhered to.
ddb(4), ttys(5), boot0cfg(8), btxld(8), config(8), disklabel(8), halt(8),
loader(8), reboot(8), shutdown(8)
The disklabel(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.
Some features are not yet documented.
DragonFly 3.7 September 2, 2008 DragonFly 3.7