diff --git a/en_US.ISO8859-1/books/handbook/boot/chapter.sgml b/en_US.ISO8859-1/books/handbook/boot/chapter.sgml
new file mode 100644
index 0000000000..f913be8845
--- /dev/null
+++ b/en_US.ISO8859-1/books/handbook/boot/chapter.sgml
@@ -0,0 +1,524 @@
+
+
+
+ The FreeBSD Booting Process
+
+
+ Introduction
+
+ Bootstrapping 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.
+
+
+
+ Overview of the boot process
+
+ FreeBSD uses a three-stage bootstrap by default, which
+ basically entails three programs which basically call each
+ other in order (the two boot
+ blocks, and the loader), and which build on the
+ previous programs understanding and provide increasing amounts
+ of sophistication.
+
+ The kernel is then started, during which devices are
+ probed for and initialized for use. Once the kernel boot
+ process is finished, it passes control to the user process
+ init, which then makes sure the disks are in a usable state,
+ and 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 2
+
+ 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.
+
+
+ boot0
+
+ There 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: F2
+
+
+
+
+ boot1
+
+ boot1 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.
+
+
+
+ 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:wd(0,a)/kernel
+boot:
+
+
+
+
+
+ loader: Bootstrap stage three
+
+ The 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 flow
+
+ During 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 commands
+
+ The easy-to-use command set comprises of:
+
+
+
+ autoboot seconds
+
+
+ Proceeds 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
+ -options
+ kernelname
+
+
+ Immediately proceeds to boot the kernel, with the
+ given options, if any, and with the kernel name given,
+ if it is.
+
+
+
+
+ help
+ topic
+
+
+ Shows 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
+ type
+ filename
+
+
+ Loads the kernel, kernel module, or file of the
+ type given, with the filename given. Any arguments
+ after filename are passed to the file.
+
+
+
+ ls
+ path
+
+
+ Displays 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 filename
+
+
+ Display the files specified, with a pause at each
+ LINES displayed.
+
+
+
+
+ reboot
+
+
+ Immediately reboots the system.
+
+
+
+
+ set variable
+ set
+ variable=value
+
+
+ Set loader's environment variables.
+
+
+
+
+
+
+ loader examples
+
+ Here are some practical examples of loader usage.
+
+
+
+ To simply boot your usual kernel, but in single-user
+ mode:
+
+ boot -s
+
+
+
+ To unload your usual kernel and modules, and then
+ load your old (or another) kernel:
+
+ unload
+ load kernel.old
+
+ You 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).
+
+
+
+ To 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.conf
+
+
+
+
+
+
+ Kernel interaction during boot
+
+ Once 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 bootflags
+
+ Here 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
+ configurator
+
+
+
+
+
+
+
+ boot into single-user mode
+
+
+
+
+
+
+
+ be more verbose during kernel startup
+
+
+
+
+
+ There 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
+ /sbin/init, or the program path specified
+ in the init_path variable in
+ loader.
+
+
+ Automatic reboot sequence
+
+ The 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 mode
+
+ This 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 insecure
+
+
+
+ An 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 mode
+
+ If 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 sequence
+
+ Upon 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
new file mode 100644
index 0000000000..f913be8845
--- /dev/null
+++ b/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml
@@ -0,0 +1,524 @@
+
+
+
+ The FreeBSD Booting Process
+
+
+ Introduction
+
+ Bootstrapping 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.
+
+
+
+ Overview of the boot process
+
+ FreeBSD uses a three-stage bootstrap by default, which
+ basically entails three programs which basically call each
+ other in order (the two boot
+ blocks, and the loader), and which build on the
+ previous programs understanding and provide increasing amounts
+ of sophistication.
+
+ The kernel is then started, during which devices are
+ probed for and initialized for use. Once the kernel boot
+ process is finished, it passes control to the user process
+ init, which then makes sure the disks are in a usable state,
+ and 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 2
+
+ 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.
+
+
+ boot0
+
+ There 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: F2
+
+
+
+
+ boot1
+
+ boot1 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.
+
+
+
+ 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:wd(0,a)/kernel
+boot:
+
+
+
+
+
+ loader: Bootstrap stage three
+
+ The 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 flow
+
+ During 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 commands
+
+ The easy-to-use command set comprises of:
+
+
+
+ autoboot seconds
+
+
+ Proceeds 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
+ -options
+ kernelname
+
+
+ Immediately proceeds to boot the kernel, with the
+ given options, if any, and with the kernel name given,
+ if it is.
+
+
+
+
+ help
+ topic
+
+
+ Shows 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
+ type
+ filename
+
+
+ Loads the kernel, kernel module, or file of the
+ type given, with the filename given. Any arguments
+ after filename are passed to the file.
+
+
+
+ ls
+ path
+
+
+ Displays 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 filename
+
+
+ Display the files specified, with a pause at each
+ LINES displayed.
+
+
+
+
+ reboot
+
+
+ Immediately reboots the system.
+
+
+
+
+ set variable
+ set
+ variable=value
+
+
+ Set loader's environment variables.
+
+
+
+
+
+
+ loader examples
+
+ Here are some practical examples of loader usage.
+
+
+
+ To simply boot your usual kernel, but in single-user
+ mode:
+
+ boot -s
+
+
+
+ To unload your usual kernel and modules, and then
+ load your old (or another) kernel:
+
+ unload
+ load kernel.old
+
+ You 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).
+
+
+
+ To 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.conf
+
+
+
+
+
+
+ Kernel interaction during boot
+
+ Once 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 bootflags
+
+ Here 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
+ configurator
+
+
+
+
+
+
+
+ boot into single-user mode
+
+
+
+
+
+
+
+ be more verbose during kernel startup
+
+
+
+
+
+ There 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
+ /sbin/init, or the program path specified
+ in the init_path variable in
+ loader.
+
+
+ Automatic reboot sequence
+
+ The 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 mode
+
+ This 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 insecure
+
+
+
+ An 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 mode
+
+ If 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 sequence
+
+ Upon 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.
+
+
+
+
+