Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
BOOT(8)		       BSD/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
     multi-user	operations.

     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, ei-
     ther 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) be-
     fore 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:

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

     The automatic boot	will attempt to	load /kernel from partition `a'	of ei-
     ther 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 fol-
     lowing 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,[slice,]part) filename [-aCcDdghmnPprsv]
	     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[2367]	or
			   lookalike controller
		     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.

		     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 (1	for the	first slice, 2 for the
		     second slice, etc.) can be	booted from, with the default
		     (if not specified)	being the active 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.

		     The pathname of the file to boot (relative	to the root
		     directory on the specified	partition).  Defaults to
		     /kernel.  Symbolic	links are not supported	(hard links

		     Boot flags:

		     -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
			   VISUAL_USERCONFIG options, remain in	UserConfig re-
			   gardless of any quit	commands present in the
		     -D	   toggle single and dual console configurations.  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 internal display
			   and the serial port will become the console at the
			   same	time, regardless of the	state of the -h	op-
			   tion.  However, the dual console configuration
			   takes effect	only during the	boot prompt.  Once the
			   kernel is loaded, the console specified by the -h
			   option becomes the only console.
		     -d	   enter the DDB kernel	debugger (see ddb(4)) as early
			   as possible in kernel initialization.
		     -g	   use the GDB remote debugging	protocol.
		     -h	   toggle internal and serial consoles.	 You can use
			   this	to switch console devices.  For	instance, 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.	Alternatively, if you
			   boot	from the serial	port, you can use this option
			   to force the	kernel to use the internal display as
			   the console instead.	 The serial port driver	sio(4)
			   has a flag 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 de-
		     -m	   mute	the console.
		     -n	   ignore key press to interrupt boot before 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 during the device
			   probing phase.
		     -r	   use the statically configured default for the de-
			   vice	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	pass-
			   word	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
     /kernel	   default kernel
     /kernel.old   typical non-default kernel (optional)

     ddb(4), ttys(5), boot0cfg(8), btxld(8), config(8),	disklabel(8), halt(8),
     loader(8),	reboot(8), shutdown(8)

     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

     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 in-
     terface 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 under-
     stands 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.

     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.

BSD				April 19, 1994				   BSD


Want to link to this manual page? Use this URL:

home | help