diff --git a/en_US.ISO8859-1/books/handbook/boot/chapter.sgml b/en_US.ISO8859-1/books/handbook/boot/chapter.sgml
index 5909e9cffc..dd1afca153 100644
--- a/en_US.ISO8859-1/books/handbook/boot/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/boot/chapter.sgml
@@ -1,549 +1,549 @@
The FreeBSD Booting ProcessSynopsisFreeBSD uses a three-stage bootstrap by default, which
basically entails three programs which call each
other in order (the two boot
blocks, and the loader). Each of these three build on the
previous program's understanding and provide increasing amounts
of sophistication.The kernel is then started, at which time devices are
probed for and initialized 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
then mounts filesystems, sets up network cards to act on the
network, and generally starts all the processes that usually
are run on a FreeBSD system at startup.The boot blocks: Bootstrap stages 1 and 2Bootstrapping is the process
whereby a computer probes and initializes its devices, and
works out what programs it is supposed to run.This involves the use of special Read Only Memory chips,
which determine what further operations to do, and these
usually pass control to other chips that do consistency and
memory tests, configure devices, and provide a mechanism for
programs to determine what configuration details were
determined.In standard personal computers, this involves the BIOS,
which oversees the bootstrap, and CMOS, which stores
configuration; and these understand disks, and they also
understand where on the disk to find a program that will know
how to load up an operating system.This chapter will not deal with this first part of the
bootstrap process, and focuses on what happens after control
is passed to the program on the disk.The boot blocks are responsible for finding (usually) the
loader, and running it, and thus need to understand how to
find that program on the filesystem, how to run the program,
and also allow minor configuration of how they work.boot0There is actually a preceding bootblock, named boot0,
which lives on the Master Boot
Record, the special part of the disk that the
system bootstrap looks for and runs, and it simply shows a
list of possible slices to boot from.boot0 is very simple, since the program in the
MBR can only be 512 bytes large.It displays something like this:boot0 screenshot
F1 DOS
F2 FreeBSD
F3 Linux
F4 ??
F5 Drive 1
Default: F2boot1boot1 is 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.boot1 is very simple, since it too can only be 512 bytes
large, and knows just enough about the FreeBSD
disklabel, which stores information
about the slice, to find and execute boot2.boot2boot2 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:wd(0,a)/kernel
boot:loader: Bootstrap stage threeThe loader is the final stage of the three-stage
bootstrap, and is located on the filesystem, usually as
/boot/loader.While /boot/boot0,
/boot/boot1, and
/boot/boot2 are files there, they are
not the actual copies in the MBR, the boot
sector, or the disklabel respectively.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 then
the interpreter is started, and the easy-to-use commands are
explained to it.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 keypresses, and boots the kernel if it is 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.A more technical discussion of the process is available
in &man.loader.8;loader built-in commandsThe easy-to-use command set comprises of:autoboot secondsProceeds to boot the kernel if not interrupted
within the time span given, in seconds. It displays a
countdown, and the default timespan 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 filenameDisplay the files specified, with a pause at each
LINES displayed.rebootImmediately reboots the system.set variableset
variable=valueSet loader's environment variables.unloadRemoves all loaded modules.loader examplesHere are some practical examples of loader usage.To 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:unloadload 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've 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'd normally do in the
kernel boot-time configurator):load -t userconfig_script
/boot/kernel.confKernel interaction during bootOnce the kernel is loaded by either loader (as usual) or boot2 (bypassing the loader), it
examines its boot flags, if any, and adjusts its behaviour as
necessary.Kernel bootflagsHere are the more common boot flags:during kernel initialization, ask for the device
to mount as 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.Init: Process control initialization
- Onqe the kernel has finished booting, it passes control to
- the usqr process init, which is located at
+ Once 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 can not fix the
inconsistencies, init drops the system
into single-user mode
for the system administrator to take care of the problems
directly.Single-user modeThis mode can be reached through the automatic reboot
sequence, or by the user booting with the
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 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
#
# This entry needed for asking password when init goes to single-user mode
# If you want to be asked for password, change "secure" to "insecure" here
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 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.Resource 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, starts up miscellaneous system daemons, and
finally runs the startup scripts of locally installed
packages.&man.rc.8; is a good reference to the resource
configuaration system, as is examining the scripts
themselves.Shutdown sequenceUpon controlled shutdown, via shutdown,
init will attempt to run the script
/etc/rc.shutdown, and then proceed to send
all processes the terminate signal, and subsequently the kill
signal to any that don't terminate timely.
diff --git a/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml b/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml
index 5909e9cffc..dd1afca153 100644
--- a/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml
@@ -1,549 +1,549 @@
The FreeBSD Booting ProcessSynopsisFreeBSD uses a three-stage bootstrap by default, which
basically entails three programs which call each
other in order (the two boot
blocks, and the loader). Each of these three build on the
previous program's understanding and provide increasing amounts
of sophistication.The kernel is then started, at which time devices are
probed for and initialized 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
then mounts filesystems, sets up network cards to act on the
network, and generally starts all the processes that usually
are run on a FreeBSD system at startup.The boot blocks: Bootstrap stages 1 and 2Bootstrapping is the process
whereby a computer probes and initializes its devices, and
works out what programs it is supposed to run.This involves the use of special Read Only Memory chips,
which determine what further operations to do, and these
usually pass control to other chips that do consistency and
memory tests, configure devices, and provide a mechanism for
programs to determine what configuration details were
determined.In standard personal computers, this involves the BIOS,
which oversees the bootstrap, and CMOS, which stores
configuration; and these understand disks, and they also
understand where on the disk to find a program that will know
how to load up an operating system.This chapter will not deal with this first part of the
bootstrap process, and focuses on what happens after control
is passed to the program on the disk.The boot blocks are responsible for finding (usually) the
loader, and running it, and thus need to understand how to
find that program on the filesystem, how to run the program,
and also allow minor configuration of how they work.boot0There is actually a preceding bootblock, named boot0,
which lives on the Master Boot
Record, the special part of the disk that the
system bootstrap looks for and runs, and it simply shows a
list of possible slices to boot from.boot0 is very simple, since the program in the
MBR can only be 512 bytes large.It displays something like this:boot0 screenshot
F1 DOS
F2 FreeBSD
F3 Linux
F4 ??
F5 Drive 1
Default: F2boot1boot1 is 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.boot1 is very simple, since it too can only be 512 bytes
large, and knows just enough about the FreeBSD
disklabel, which stores information
about the slice, to find and execute boot2.boot2boot2 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:wd(0,a)/kernel
boot:loader: Bootstrap stage threeThe loader is the final stage of the three-stage
bootstrap, and is located on the filesystem, usually as
/boot/loader.While /boot/boot0,
/boot/boot1, and
/boot/boot2 are files there, they are
not the actual copies in the MBR, the boot
sector, or the disklabel respectively.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 then
the interpreter is started, and the easy-to-use commands are
explained to it.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 keypresses, and boots the kernel if it is 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.A more technical discussion of the process is available
in &man.loader.8;loader built-in commandsThe easy-to-use command set comprises of:autoboot secondsProceeds to boot the kernel if not interrupted
within the time span given, in seconds. It displays a
countdown, and the default timespan 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 filenameDisplay the files specified, with a pause at each
LINES displayed.rebootImmediately reboots the system.set variableset
variable=valueSet loader's environment variables.unloadRemoves all loaded modules.loader examplesHere are some practical examples of loader usage.To 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:unloadload 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've 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'd normally do in the
kernel boot-time configurator):load -t userconfig_script
/boot/kernel.confKernel interaction during bootOnce the kernel is loaded by either loader (as usual) or boot2 (bypassing the loader), it
examines its boot flags, if any, and adjusts its behaviour as
necessary.Kernel bootflagsHere are the more common boot flags:during kernel initialization, ask for the device
to mount as 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.Init: Process control initialization
- Onqe the kernel has finished booting, it passes control to
- the usqr process init, which is located at
+ Once 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 can not fix the
inconsistencies, init drops the system
into single-user mode
for the system administrator to take care of the problems
directly.Single-user modeThis mode can be reached through the automatic reboot
sequence, or by the user booting with the
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 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
#
# This entry needed for asking password when init goes to single-user mode
# If you want to be asked for password, change "secure" to "insecure" here
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 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.Resource 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, starts up miscellaneous system daemons, and
finally runs the startup scripts of locally installed
packages.&man.rc.8; is a good reference to the resource
configuaration system, as is examining the scripts
themselves.Shutdown sequenceUpon controlled shutdown, via shutdown,
init will attempt to run the script
/etc/rc.shutdown, and then proceed to send
all processes the terminate signal, and subsequently the kill
signal to any that don't terminate timely.