The FreeBSD Booting ProcessSynopsisbootingbootstrapThe process of starting a computer and loading the operating system
is referred to as the bootstrap process, or simply
booting. FreeBSD's boot process provides a great deal of
flexibility in customizing what happens when you start the system,
allowing you to select from different operating systems installed on the
same computer, or even different versions of the same operating system
or installed kernel.This chapter details the configuration options you can set and how
to customize the FreeBSD boot process. This includes everything that
happens until the FreeBSD kernel has started, probed for devices, and
started &man.init.8;. If you are not quite sure when this happens, it
occurs when the text color changes from bright white to grey.After reading this chapter, you will know:What the components of the FreeBSD bootstrap system are, and how
they interact.The options you can give to the components in the FreeBSD
bootstrap to control the boot process.x86 onlyThis chapter only describes the boot process for FreeBSD running
on Intel x86 systems.The Booting ProblemTurning on a computer and starting the operating system poses an
interesting dilemma. By definition, the computer does not know how to
do anything until the operating system is started. This includes
running programs from the disk. So if the computer can not run a
program from the disk without the operating system, and the operating
system programs are on the disk, how is the operating system
started?This problem parallels one in the book The Adventures of
Baron Munchausen. A character had fallen part way down a
manhole, and pulled himself out by grabbing his bootstraps, and
lifting. In the early days of computing the term
bootstrap was applied to the mechanism used to
load the operating system, which has become shortened to
booting.On x86 hardware the Basic Input/Output System (BIOS) is responsible
for loading the operating system. To do this, the BIOS looks on the
hard disk for the Master Boot Record (MBR), which must be located on a
specific place on the disk. The BIOS has enough knowledge to load and
run the MBR, and assumes that the MBR can then carry out the rest of the
tasks involved in loading the operating system.BIOSBasic Input/Output SystemIf you only have one operating system installed on your disks then
the standard MBR will suffice. This MBR searches for the first bootable
slice on the disk, and then runs the code on that slice to load the
remainder of the operating system.If you have installed multiple operating systems on your disks then
you can install a different MBR, one that can display a list of
different operating systems, and allows you to choose the one to boot
from. FreeBSD comes with one such MBR which can be installed, and other
operating system vendors also provide alternative MBRs.The remainder of the FreeBSD bootstrap system is divided into three
stages. The first stage is run by the MBR, which knows just enough to
get the computer into a specific state and run the second stage. The
second stage can do a little bit more, before running the third stage.
The third stage finishes the task of loading the operating system. The
work is split into these three stages because the PC standards put
limits on the size of the programs that can be run at stages one and
two. Chaining the tasks together allows FreeBSD to provide a more
flexible loader.kernelinitThe kernel is then started and it begins to probe for devices
and initialize them for use. Once the kernel boot
process is finished, the kernel passes control to the user process
&man.init.8;, which then makes sure the disks are in a usable state.
&man.init.8; then starts the user-level resource configuration which
mounts filesystems, sets up network cards to communicate on the
network, and generally starts all the processes that usually
are run on a FreeBSD system at startup.The MBR, and Boot Stages One, Two, and ThreeMBR, /boot/boot0Master Boot Record (MBR)The FreeBSD MBR is located in /boot/boot0.
This is a copy of the MBR, as the real MBR must
be placed on a special part of the disk, outside the FreeBSD
area.boot0 is very simple, since the
program in the MBR can only be 512 bytes in
size. If you have installed the FreeBSD MBR and have installed
multiple operating systems on your hard disks then you will see a
display similar to this one at boot time.boot0 ScreenshotF1 DOS
F2 FreeBSD
F3 Linux
F4 ??
F5 Drive 1
Default: F2Other operating systems, in particular Windows 95, have been known
to overwrite an existing MBR with their own. If this happens to you,
or you want to replace your existing MBR with the FreeBSD MBR then use
the following command.&prompt.root; fdisk -B -b /boot/boot0 deviceWhere device is the device that you
boot from, such as ad0 for the first IDE
disk, ad2 for the first IDE disk on a second
IDE controller, da0 for the first SCSI disk,
and so on.If you are a Linux user, however, and prefer that
LILO control the boot process, you can
edit the /etc/lilo.conf file for FreeBSD, or
select
during the FreeBSD installation process. If you have installed the
the FreeBSD boot manager, you can boot back into Linux and modify the
LILO configuration file
/etc/lilo.conf and add the following
option:other=/dev/hdXY
table=/dev/hdb
loader=/boot/chain.b
label=FreeBSDwhich will permit the booting of FreeBSD and Linux via
LILO. In our example, we use
XY to determine drive number and
partition. If you are using a SCSI drive, you
will want to change /dev/hdXY to read
something similar to /dev/sdXY, which
again uses the XY syntax. The
can be omitted if you have
both operating systems on the same drive. You can now run
/sbin/lilo -v to commit your new changes to the
system, this should be verified with screen messages.Stage One, /boot/boot1, and Stage Two,
/boot/boot2Conceptually the first and second stages are part of the same
program, on the same area of the disk. Because of space constraints
they have been split into two, but you would always install them
together.They are found on the boot sector of
the boot slice, which is where boot0, or any other program on the
MBR expects to find the program to run to
continue the boot process. The files in the
/boot directory are copies of the real files,
which are stored outside of the FreeBSD filesystem.boot1 is very simple, since it too
can only be 512 bytes
in size, and knows just enough about the FreeBSD
disklabel, which stores information
about the slice, to find and execute boot2.boot2 is slightly more sophisticated, and understands
the FreeBSD filesystem enough to find files on it, and can
provide a simple interface to choose the kernel or loader to
run.Since the loader is
much more sophisticated, and provides a nice easy-to-use
boot configuration, boot2 usually runs
it, but previously it
was tasked to run the kernel directly.boot2 Screenshot>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/kernel
boot:If you ever need to replace the installed
boot1 and boot2 use
&man.disklabel.8;.&prompt.root; disklabel -B disksliceWhere diskslice is the disk and slice
you boot from, such as ad0s1 for the first
slice on the first IDE disk.Dangerously Dedicated ModeIf you use just the disk name, such as
ad0, in the &man.disklabel.8; command you
will create a dangerously dedicated disk, without slices. This is
almost certainly not what you want to do, so make sure you double
check the &man.disklabel.8; command before you press
Return.Stage Three, /boot/loaderboot-loaderThe loader is the final stage of the three-stage
bootstrap, and is located on the filesystem, usually as
/boot/loader.The loader is intended as a user-friendly method for
configuration, using an easy-to-use built-in command set,
backed up by a more powerful interpreter, with a more complex
command set.Loader Program FlowDuring initialization, the loader will probe for a
console and for disks, and figure out what disk it is
booting from. It will set variables accordingly, and an
interpreter is started where user commands can be passed from
a script or interactively.loaderloader configurationThe loader will then read
/boot/loader.rc, which by default reads
in /boot/defaults/loader.conf which
sets reasonable defaults for variables and reads
/boot/loader.conf for local changes to
those variables. loader.rc then acts
on these variables, loading whichever modules and kernel are
selected.Finally, by default, the loader issues a 10 second wait
for key presses, and boots the kernel if it is not interrupted.
If interrupted, the user is presented with a prompt which
understands the easy-to-use command set, where the user may
adjust variables, unload all modules, load modules, and then
finally boot or reboot.Loader Built-In CommandsThese are the most commonly used loader commands. For a
complete discussion of all available commands, please see
&man.loader.8;autoboot secondsProceeds to boot the kernel if not interrupted
within the time span given, in seconds. It displays a
countdown, and the default time span is 10
seconds.boot
-optionskernelnameImmediately proceeds to boot the kernel, with the
given options, if any, and with the kernel name given,
if it is.boot-confGoes through the same automatic configuration of
modules based on variables as what happens at boot.
This only makes sense if you use
unload first, and change some
variables, most commonly kernel.help
topicShows help messages read from
/boot/loader.help. If the topic
given is index, then the list of
available topics is given.include filename
…Processes the file with the given filename. The
file is read in, and interpreted line by line. An
error immediately stops the include command.load typefilenameLoads the kernel, kernel module, or file of the
type given, with the filename given. Any arguments
after filename are passed to the file.ls pathDisplays a listing of files in the given path, or
the root directory, if the path is not specified. If
is specified, file sizes will be
shown too.lsdev Lists all of the devices from which it may be
possible to load modules. If is
specified, more details are printed.lsmod Displays loaded modules. If is
specified, more details are shown.more filenameDisplays the files specified, with a pause at each
LINES displayed.rebootImmediately reboots the system.set variableset
variable=valueSets the loader's environment variables.unloadRemoves all loaded modules.Loader ExamplesHere are some practical examples of loader usage.single-user modeTo simply boot your usual kernel, but in single-user
mode:boot -sTo unload your usual kernel and modules, and then
load just your old (or another) kernel:kernel.oldunloadload kernel.oldYou can use kernel.GENERIC to
refer to the generic kernel that comes on the install
disk, or kernel.old to refer to
your previously installed kernel (when you have upgraded
or configured your own kernel, for example).Use the following to load your usual modules with
another kernel:unloadset kernel="kernel.old"boot-confTo load a kernel configuration script (an automated
script which does the things you would normally do in the
kernel boot-time configurator):load -t userconfig_script /boot/kernel.confKernel Interaction During Bootkernelboot interactionOnce the kernel is loaded by either loader (as usual) or boot2 (bypassing the loader), it
examines its boot flags, if any, and adjusts its behavior as
necessary.kernelbootflagsKernel Boot FlagsHere are the more common boot flags:during kernel initialization, ask for the device
to mount as the root file system.boot from CDROM.run UserConfig, the boot-time kernel
configuratorboot into single-user modebe more verbose during kernel startupThere are other boot flags, read &man.boot.8; for more
information on them.initInit: Process Control InitializationOnce the kernel has finished booting, it passes control to
the user process init, which is located at
/sbin/init, or the program path specified
in the init_path variable in
loader.Automatic Reboot SequenceThe automatic reboot sequence makes sure that the
filesystems available on the system are consistent. If they
are not, and fsck cannot fix the
inconsistencies, init drops the system
into single-user mode
for the system administrator to take care of the problems
directly.Single-User Modesingle-user modeconsoleThis mode can be reached through the automatic reboot
sequence, or by the user booting with the
option or setting the
boot_single variable in
loader.It can also be reached by calling
shutdown without the reboot
() or halt () options,
from multi-user
mode.If the system console is set
to insecure in
/etc/ttys, then the system prompts for
the root password before initiating single-user mode.An Insecure Console in /etc/ttys# name getty type status comments
#
# If console is marked "insecure", then init will ask for the root password
# when going to single-user mode.
console none unknown off insecureAn insecure console means that you
consider your physical security to the console to be
insecure, and want to make sure only someone who knows the
root password may use single-user mode, and it does not
mean that you want to run your console insecurely. Thus,
if you want security, choose insecure,
not secure.Multi-User Modemulti-user modeIf init finds your filesystems to be
in order, or once the user has finished in single-user mode, the
system enters multi-user mode, in which it starts the
resource configuration of the system.rc filesResource Configuration (rc)The resource configuration system reads in
configuration defaults from
/etc/defaults/rc.conf, and
system-specific details from
/etc/rc.conf, and then proceeds to
mount the system filesystems mentioned in
/etc/fstab, start up networking
services, start up miscellaneous system daemons, and
finally runs the startup scripts of locally installed
packages.The &man.rc.8; manual page is a good reference to the resource
configuration system, as is examining the scripts
themselves.Shutdown SequenceshutdownUpon controlled shutdown, via shutdown,
init will attempt to run the script
/etc/rc.shutdown, and then proceed to send
all processes the TERM signal, and subsequently
the KILL signal to any that do not terminate
timely.