e05926f374
Merged /projects/print2013/en_US.ISO8859-1:r40693-40726 Merged /projects/ISBN_1-57176-407-0/en_US.ISO8859-1:r40727-41455, 41457-41469,41472-41477,41479-41513,41515-41521,41523-41577, 41579-41581,41583-42013 Notes: This merge entirely excludes the en_US/books/handbook/ppp-and-slip/ changes. They will need to be looked at a bit more closely. Note to translators: I am very, very sorry. There was no *clean* way to merge this as separate commits. Trust me, I tried. The revision logs for the ISBN branch should provide some insight to what content has changed. I am more than happy to help out here. Sorry :( Approved by: doceng (implicit)
1022 lines
36 KiB
XML
1022 lines
36 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
|
|
$FreeBSD$
|
|
-->
|
|
|
|
<chapter id="boot">
|
|
<title>The &os; Booting Process</title>
|
|
|
|
<sect1 id="boot-synopsis">
|
|
<title>Synopsis</title>
|
|
|
|
<indexterm><primary>booting</primary></indexterm>
|
|
<indexterm><primary>bootstrap</primary></indexterm>
|
|
|
|
<para>The process of starting a computer and loading the operating
|
|
system is referred to as <quote>the bootstrap process</quote>,
|
|
or simply <quote>booting</quote>. &os;'s boot process provides
|
|
a great deal of flexibility in customizing what happens when
|
|
the system starts, including the ability to select from
|
|
different operating systems installed on the same computer,
|
|
different versions of the same operating system, or a different
|
|
installed kernel.</para>
|
|
|
|
<para>This chapter details the configuration options that can
|
|
be set. It demonstrates how to customize the &os; boot
|
|
process, including everything that happens until the &os; kernel
|
|
has started, probed for devices, and started &man.init.8;. This
|
|
occurs when the text color of the boot messages changes from
|
|
bright white to grey.</para>
|
|
|
|
<para>After reading this chapter, you will recognize:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The components of the &os; bootstrap system and how they
|
|
interact.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The options that can be passed to the components in the
|
|
&os; bootstrap in order to control the boot process.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The basics of &man.device.hints.5;.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>This chapter only describes the boot process for &os;
|
|
running on Intel x86 systems.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="boot-introduction">
|
|
<title>The Booting Problem</title>
|
|
|
|
<para>Turning 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. 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?</para>
|
|
|
|
<para>This problem parallels one in the book <citetitle>The
|
|
Adventures of Baron Munchausen</citetitle>. 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 <firstterm>bootstrap</firstterm> was applied
|
|
to the mechanism used to load the operating system, which has
|
|
become shortened to <quote>booting</quote>.</para>
|
|
|
|
<indexterm><primary><acronym>BIOS</acronym></primary></indexterm>
|
|
|
|
<indexterm>
|
|
<primary>Basic Input/Output System</primary>
|
|
<see><acronym>BIOS</acronym></see>
|
|
</indexterm>
|
|
|
|
<para>On x86 hardware the Basic Input/Output System
|
|
(<acronym>BIOS</acronym>) is responsible for loading the
|
|
operating system. To do this, the <acronym>BIOS</acronym>
|
|
looks on the hard disk for the Master Boot Record
|
|
(<acronym>MBR</acronym>), which must be located in a specific
|
|
place on the disk. The <acronym>BIOS</acronym> has enough
|
|
knowledge to load and run the <acronym>MBR</acronym>, and
|
|
assumes that the <acronym>MBR</acronym> can then carry out the
|
|
rest of the tasks involved in loading the operating system,
|
|
possibly with the help of the <acronym>BIOS</acronym>.</para>
|
|
|
|
<indexterm><primary>Master Boot Record
|
|
<acronym>MBR</acronym>)</primary></indexterm>
|
|
|
|
<indexterm><primary>Boot Manager</primary></indexterm>
|
|
|
|
<indexterm><primary>Boot Loader</primary></indexterm>
|
|
|
|
<para>The code within the <acronym>MBR</acronym> is usually
|
|
referred to as a <emphasis>boot manager</emphasis>, especially
|
|
when it interacts with the user. In this case, the boot
|
|
manager usually has more code in the first
|
|
<emphasis>track</emphasis> of the disk or within the file
|
|
system of some operating systems. A boot manager is sometimes
|
|
also called a <emphasis>boot loader</emphasis>, but &os; uses
|
|
that term for a later stage of booting. Popular boot managers
|
|
include <application>boot0</application>, also called
|
|
<application>Boot Easy</application>, the standard &os; boot
|
|
manager, <application>Grub</application>,
|
|
<application>GAG</application>, and
|
|
<application>LILO</application>. Only
|
|
<application>boot0</application> fits within the
|
|
<acronym>MBR</acronym>.</para>
|
|
|
|
<para>If only one operating system is installed, a standard PC
|
|
<acronym>MBR</acronym> will suffice. This
|
|
<acronym>MBR</acronym> searches for the first bootable (active)
|
|
slice on the disk, and then runs the code on that slice to load
|
|
the remainder of the operating system. By default, the
|
|
<acronym>MBR</acronym> installed by &man.fdisk.8; is such an
|
|
<acronym>MBR</acronym> and is based on
|
|
<filename>/boot/mbr</filename>.</para>
|
|
|
|
<para>If multiple operating systems are present, a different boot
|
|
manager can be installed which displays the list of operating
|
|
systems so that the user can choose which one to boot from. Two
|
|
boot managers are discussed in the next subsection.</para>
|
|
|
|
<para>The remainder of the &os; bootstrap system is divided
|
|
into three stages. The first stage is run by the
|
|
<acronym>MBR</acronym>, 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 three stages because
|
|
PC standards put limits on the size of the programs that can
|
|
be run at stages one and two. Chaining the tasks together
|
|
allows &os; to provide a more flexible loader.</para>
|
|
|
|
<indexterm><primary>kernel</primary></indexterm>
|
|
<indexterm><primary>&man.init.8;</primary></indexterm>
|
|
|
|
<para>The 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 file systems, sets up network cards
|
|
to communicate on the network, and starts the processes which
|
|
have been configured to run on a &os; system at startup.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="boot-blocks">
|
|
<title>The Boot Manager and Boot Stages</title>
|
|
|
|
<indexterm><primary>Boot Manager</primary></indexterm>
|
|
|
|
<sect2 id="boot-boot0">
|
|
<title>The Boot Manager</title>
|
|
|
|
<indexterm><primary>Master Boot Record
|
|
(<acronym>MBR</acronym>)</primary></indexterm>
|
|
|
|
<para>The code in the <acronym>MBR</acronym> or boot manager is
|
|
sometimes referred to as <emphasis>stage zero</emphasis> of
|
|
the boot process. This section discusses two boot managers:
|
|
<application>boot0</application> and
|
|
<application>LILO</application>.</para>
|
|
|
|
<formalpara>
|
|
<title>The <application>boot0</application> Boot
|
|
Manager:</title>
|
|
|
|
<para>The <acronym>MBR</acronym> installed by &os;'s installer
|
|
or &man.boot0cfg.8; is based on
|
|
<filename>/boot/boot0</filename>. The size and capability
|
|
of <application>boot0</application> is restricted to 446
|
|
bytes due to the slice table and <literal>0x55AA</literal>
|
|
identifier at the end of the <acronym>MBR</acronym>. If
|
|
<application>boot0</application> and multiple operating
|
|
systems are installed, a message similar to this example
|
|
will be displayed at boot time:</para>
|
|
</formalpara>
|
|
|
|
<example id="boot-boot0-example">
|
|
<title><filename>boot0</filename> Screenshot</title>
|
|
|
|
<screen>F1 Win
|
|
F2 FreeBSD
|
|
|
|
Default: F2</screen>
|
|
</example>
|
|
|
|
<para>Other operating systems, in particular &windows;, will
|
|
overwrite an existing <acronym>MBR</acronym> if they are
|
|
installed after &os;. If this happens, or to replace the
|
|
existing <acronym>MBR</acronym> with the &os;
|
|
<acronym>MBR</acronym>, use the following command:</para>
|
|
|
|
<screen>&prompt.root; <userinput>fdisk -B -b /boot/boot0 <replaceable>device</replaceable></userinput></screen>
|
|
|
|
<para>where <replaceable>device</replaceable> is the boot disk,
|
|
such as <devicename>ad0</devicename> for the first
|
|
<acronym>IDE</acronym> disk, <devicename>ad2</devicename>
|
|
for the first <acronym>IDE</acronym> disk on a second
|
|
<acronym>IDE</acronym> controller, or
|
|
<devicename>da0</devicename>
|
|
for the first <acronym>SCSI</acronym> disk. To create a
|
|
custom configuration of the <acronym>MBR</acronym>, refer to
|
|
&man.boot0cfg.8;.</para>
|
|
|
|
<formalpara>
|
|
<title>The LILO Boot Manager:</title>
|
|
|
|
<para>To install this boot manager so it will also boot
|
|
&os;, boot into Linux and add the following to the existing
|
|
<filename>/etc/lilo.conf</filename> configuration:</para>
|
|
</formalpara>
|
|
|
|
<programlisting>other=/dev/hdXY
|
|
table=/dev/hdX
|
|
loader=/boot/chain.b
|
|
label=FreeBSD</programlisting>
|
|
|
|
<para>Specify &os;'s primary partition and drive using Linux
|
|
specifiers, replacing <replaceable>X</replaceable> with the
|
|
Linux drive letter and <replaceable>Y</replaceable> with the
|
|
Linux primary partition number. For a <acronym>SCSI</acronym>
|
|
drive, change <replaceable>/dev/hd</replaceable> to
|
|
<replaceable>/dev/sd</replaceable>. The
|
|
<option>loader=/boot/chain.b</option> line can be omitted if
|
|
both operating systems are installed on the same drive. Next,
|
|
run <command>/sbin/lilo -v</command> to commit the new
|
|
changes. Verify these are correct by checking the screen
|
|
messages.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="boot-boot1">
|
|
<title>Stage One, <filename>/boot/boot1</filename>, and Stage
|
|
Two, <filename>/boot/boot2</filename></title>
|
|
|
|
<para>Conceptually, 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 are always
|
|
installed together. They are copied from the combined
|
|
<filename>/boot/boot</filename> by the installer or
|
|
&man.bsdlabel.8;.</para>
|
|
|
|
<para>They are located outside file systems, in the first track
|
|
of the boot slice, starting with the first sector. This is
|
|
where boot0 (<xref linkend="boot-boot0"/>), or any other
|
|
boot manager, expects to find a program to run which will
|
|
continue the boot process. The number of sectors used is
|
|
easily determined from the size of
|
|
<filename>/boot/boot</filename>.</para>
|
|
|
|
<para><filename>boot1</filename> is very simple, since it can
|
|
only be 512 bytes in size, and knows just enough about the
|
|
&os; <firstterm>bsdlabel</firstterm>, which stores
|
|
information about the slice, to find and execute
|
|
<filename>boot2</filename>.</para>
|
|
|
|
<para><filename>boot2</filename> is slightly more sophisticated,
|
|
and understands the &os; file system enough to find files, and
|
|
can provide a simple interface to choose the kernel or loader
|
|
to run.</para>
|
|
|
|
<para>However, &man.loader.8; is much more sophisticated and
|
|
provides a boot configuration which is run by
|
|
<filename>boot2</filename>.</para>
|
|
|
|
<example id="boot-boot2-example">
|
|
<title><filename>boot2</filename> Screenshot</title>
|
|
|
|
<screen>>> FreeBSD/i386 BOOT
|
|
Default: 0:ad(0,a)/boot/loader
|
|
boot:</screen>
|
|
</example>
|
|
|
|
<para>&man.bsdlabel.8; can be used to replace the installed
|
|
<filename>boot1</filename> and
|
|
<filename>boot2</filename>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>bsdlabel -B <replaceable>diskslice</replaceable></userinput></screen>
|
|
|
|
<para>where <replaceable>diskslice</replaceable> is the disk and
|
|
slice to boot from, such as <devicename>ad0s1</devicename>
|
|
for the first slice on the first <acronym>IDE</acronym>
|
|
disk.</para>
|
|
|
|
<warning>
|
|
<title>Dangerously Dedicated Mode</title>
|
|
|
|
<para>If just the disk name is used, such as
|
|
<devicename>ad0</devicename>, &man.bsdlabel.8; will create a
|
|
<quote>dangerously dedicated</quote> disk, without slices.
|
|
This is probably not the desired action, so double check the
|
|
<replaceable>diskslice</replaceable> passed to
|
|
&man.bsdlabel.8; before pressing
|
|
<keycap>Return</keycap>.</para>
|
|
</warning>
|
|
</sect2>
|
|
|
|
<sect2 id="boot-loader">
|
|
<title>Stage Three, <filename>/boot/loader</filename></title>
|
|
|
|
<indexterm><primary>boot-loader</primary></indexterm>
|
|
|
|
<para>The loader is the final stage of the three-stage
|
|
bootstrap, and is located on the file system, usually as
|
|
<filename>/boot/loader</filename>.</para>
|
|
|
|
<para>The loader is intended as an interactive method for
|
|
configuration, using a built-in command set, backed up by a
|
|
more powerful interpreter which has a more complex command
|
|
set.</para>
|
|
|
|
<sect3 id="boot-loader-flow">
|
|
<title>Loader Program Flow</title>
|
|
|
|
<para>During initialization, the loader will probe for a
|
|
console and for disks, and figure out which 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.</para>
|
|
|
|
<indexterm><primary>loader</primary></indexterm>
|
|
<indexterm><primary>loader configuration</primary></indexterm>
|
|
|
|
<para>The loader will then read
|
|
<filename>/boot/loader.rc</filename>, which by default reads
|
|
in <filename>/boot/defaults/loader.conf</filename> which
|
|
sets reasonable defaults for variables and reads
|
|
<filename>/boot/loader.conf</filename> for local changes to
|
|
those variables. <filename>loader.rc</filename> then acts
|
|
on these variables, loading whichever modules and kernel are
|
|
selected.</para>
|
|
|
|
<para>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 command set, where the user may
|
|
adjust variables, unload all modules, load modules, and then
|
|
finally boot or reboot.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="boot-loader-commands">
|
|
<title>Loader Built-In Commands</title>
|
|
|
|
<para>These are the most commonly used loader commands. For a
|
|
complete discussion of all available commands, refer to
|
|
&man.loader.8;.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>autoboot <replaceable>seconds</replaceable></term>
|
|
|
|
<listitem>
|
|
<para>Proceeds 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.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>boot
|
|
<optional><replaceable>-options</replaceable></optional>
|
|
<optional><replaceable>kernelname</replaceable></optional></term>
|
|
|
|
<listitem>
|
|
<para>Immediately proceeds to boot the kernel, with any
|
|
specified options or kernel name. Providing a kernel
|
|
name on the command-line is only applicable after an
|
|
<emphasis>unload</emphasis> command has been issued;
|
|
otherwise the previously-loaded kernel will be
|
|
used.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>boot-conf</term>
|
|
|
|
<listitem>
|
|
<para>Goes through the same automatic configuration of
|
|
modules based on specified variables, most commonly
|
|
<envar>kernel</envar>. This only makes sense if
|
|
<command>unload</command> is used first, before
|
|
changing some variables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>help
|
|
<optional><replaceable>topic</replaceable></optional></term>
|
|
|
|
<listitem>
|
|
<para>Shows help messages read from
|
|
<filename>/boot/loader.help</filename>. If the topic
|
|
given is <literal>index</literal>, the list of
|
|
available topics is displayed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>include <replaceable>filename</replaceable>
|
|
…</term>
|
|
|
|
<listitem>
|
|
<para>Processes the file with the given filename. The
|
|
file is read in and interpreted line by line. An
|
|
error immediately stops the include command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>load <optional><option>-t</option>
|
|
<replaceable>type</replaceable></optional>
|
|
<replaceable>filename</replaceable></term>
|
|
|
|
<listitem>
|
|
<para>Loads the kernel, kernel module, or file of the
|
|
type given, with the specified filename. Any
|
|
arguments after <replaceable>filename</replaceable>
|
|
are passed to the file.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>ls <optional><option>-l</option></optional>
|
|
<optional><replaceable>path</replaceable></optional></term>
|
|
|
|
<listitem>
|
|
<para>Displays a listing of files in the given path, or
|
|
the root directory, if the path is not specified. If
|
|
<option>-l</option> is specified, file sizes will
|
|
also be shown.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>lsdev
|
|
<optional><option>-v</option></optional></term>
|
|
|
|
<listitem>
|
|
<para>Lists all of the devices from which it may be
|
|
possible to load modules. If <option>-v</option> is
|
|
specified, more details are printed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>lsmod
|
|
<optional><option>-v</option></optional></term>
|
|
|
|
<listitem>
|
|
<para>Displays loaded modules. If <option>-v</option>
|
|
is specified, more details are shown.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>more <replaceable>filename</replaceable></term>
|
|
|
|
<listitem>
|
|
<para>Displays the files specified, with a pause at each
|
|
<varname>LINES</varname> displayed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>reboot</term>
|
|
|
|
<listitem>
|
|
<para>Immediately reboots the system.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>set <replaceable>variable</replaceable></term>
|
|
<term>set
|
|
<replaceable>variable</replaceable>=<replaceable>value</replaceable></term>
|
|
|
|
<listitem>
|
|
<para>Sets the loader's environment variables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>unload</term>
|
|
|
|
<listitem>
|
|
<para>Removes all loaded modules.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect3>
|
|
|
|
<sect3 id="boot-loader-examples">
|
|
<title>Loader Examples</title>
|
|
|
|
<para>Here are some practical examples of loader usage:</para>
|
|
|
|
<itemizedlist>
|
|
<indexterm><primary>single-user mode</primary></indexterm>
|
|
|
|
<listitem>
|
|
<para>To boot the usual kernel in single-user mode:</para>
|
|
|
|
<screen><userinput>boot -s</userinput></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>To unload the usual kernel and modules, and then
|
|
load the previous or another kernel:</para>
|
|
|
|
<indexterm>
|
|
<primary><filename>kernel.old</filename></primary>
|
|
</indexterm>
|
|
|
|
<screen><userinput>unload</userinput>
|
|
<userinput>load <replaceable>kernel.old</replaceable></userinput></screen>
|
|
|
|
<para>Use <filename>kernel.GENERIC</filename> to refer to
|
|
the default kernel that comes with an installation, or
|
|
<filename>kernel.old</filename> to refer to the
|
|
previously installed kernel before a system upgrade or
|
|
before configuring a custom kernel.</para>
|
|
|
|
<note>
|
|
<para>Use the following to load the usual modules with
|
|
another kernel:</para>
|
|
|
|
<screen><userinput>unload</userinput>
|
|
<userinput>set kernel="<replaceable>kernel.old</replaceable>"</userinput>
|
|
<userinput>boot-conf</userinput></screen></note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>To load an automated kernel configuration
|
|
script:</para>
|
|
|
|
<screen><userinput>load -t userconfig_script <replaceable>/boot/kernel.conf</replaceable></userinput></screen>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect3>
|
|
|
|
<sect3 id="boot-splash">
|
|
<sect3info>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Joseph J.</firstname>
|
|
<surname>Barbish</surname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
</sect3info>
|
|
|
|
<title>Boot Time Splash Screens</title>
|
|
|
|
<para>The splash screen creates an alternate boot screen. The
|
|
splash screen hides all the boot probe messages and service
|
|
startup messages before displaying either a command line or
|
|
graphical login prompt.</para>
|
|
|
|
<para>There are two basic environments available in &os;. The
|
|
first is the default legacy virtual console command line
|
|
environment. After the system finishes booting, a console
|
|
login prompt is presented. The second environment is the
|
|
graphical environment as described in <xref linkend="x11"/>.
|
|
Refer to that chapter for more information on how to install
|
|
and configure a graphical display manager and a graphical
|
|
login manager.</para>
|
|
|
|
<sect4 id="boot-splash-function">
|
|
<title>Splash Screen Function</title>
|
|
|
|
<para>The splash screen function supports 256-colors in the
|
|
bitmap (<filename>.bmp</filename>), ZSoft
|
|
<acronym>PCX</acronym> (<filename>.pcx</filename>), or
|
|
TheDraw (<filename>.bin</filename>) formats. The splash
|
|
image files must have a resolution of 320 by 200 pixels or
|
|
less in order to work on standard VGA adapters.</para>
|
|
|
|
<para>To use larger images, up to the maximum resolution of
|
|
1024 by 768 pixels, load the <acronym>VESA</acronym>
|
|
module during system boot. For a custom kernel, as
|
|
described in <xref linkend="kernelconfig"/>, include the
|
|
<literal>VESA</literal> kernel configuration option.
|
|
Loading <acronym>VESA</acronym> support provides the
|
|
ability to display a splash screen image that fills the
|
|
whole display screen.</para>
|
|
|
|
<para>While the splash screen is being displayed during the
|
|
booting process, it can be turned off any time by hitting
|
|
any key on the keyboard.</para>
|
|
|
|
<para>The splash screen also defaults to being a screen
|
|
saver outside. After a time period of non-use, the splash
|
|
screen will be displayed and will cycle through steps of
|
|
changing intensity of the image, from bright to very dark
|
|
and over again. The configuration of the splash screen
|
|
saver can be overridden by adding a
|
|
<literal>saver=</literal> line to
|
|
<filename>/etc/rc.conf</filename>. Several built-in
|
|
screen savers are available and described in
|
|
&man.splash.4;. The <literal>saver=</literal> option only
|
|
applies to virtual consoles and has no effect on graphical
|
|
display managers.</para>
|
|
|
|
<para>A few boot loader messages, including the boot options
|
|
menu and a timed wait count down prompt, are displayed at
|
|
boot time, even when the splash screen is enabled.</para>
|
|
|
|
<para>Sample splash screen files can be downloaded from the
|
|
gallery at <ulink
|
|
url="http://artwork.freebsdgr.org/node/3/">http://artwork.freebsdgr.org</ulink>.
|
|
By installing the <filename
|
|
role="package">sysutils/bsd-splash-changer</filename>
|
|
port, splash images can be chosen from a collection
|
|
randomly at each boot.</para>
|
|
</sect4>
|
|
|
|
<sect4 id="boot-splash-enable">
|
|
<title>Enabling the Splash Screen Function</title>
|
|
|
|
<para>The splash screen <filename>.bmp</filename>,
|
|
<filename>.pcx</filename>, or <filename>.bin</filename>
|
|
image has to be placed on the root partition, for example
|
|
in <filename class="directory">/boot</filename>.</para>
|
|
|
|
<para>For the default boot display resolution of 256-colors
|
|
and 320 by 200 pixels or less, edit
|
|
<filename>/boot/loader.conf</filename> so it contains the
|
|
following:</para>
|
|
|
|
<programlisting>splash_bmp_load="YES"
|
|
bitmap_load="YES"
|
|
bitmap_name="<replaceable>/boot/splash.bmp</replaceable>"</programlisting>
|
|
|
|
<para>For larger video resolutions up to the maximum of 1024
|
|
by 768 pixels, edit
|
|
<filename>/boot/loader.conf</filename>, so it contains the
|
|
following:</para>
|
|
|
|
<programlisting>vesa_load="YES"
|
|
splash_bmp_load="YES"
|
|
bitmap_load="YES"
|
|
bitmap_name="<replaceable>/boot/splash.bmp</replaceable>"</programlisting>
|
|
|
|
<para>This example assumes that
|
|
<filename><replaceable>/boot/splash.bmp</replaceable></filename>
|
|
is used for the splash screen. To use a
|
|
<acronym>PCX</acronym> file, use the following statements,
|
|
plus the <literal>vesa_load="YES"</literal> line,
|
|
depending on the resolution:</para>
|
|
|
|
<programlisting>splash_pcx_load="YES"
|
|
bitmap_load="YES"
|
|
bitmap_name="<replaceable>/boot/splash.pcx</replaceable>"</programlisting>
|
|
|
|
<para>Beginning with &os; 8.3, another option is to use
|
|
ASCII art in <ulink
|
|
url="https://en.wikipedia.org/wiki/TheDraw">TheDraw</ulink>
|
|
format.</para>
|
|
|
|
<programlisting>splash_txt="YES"
|
|
bitmap_load="YES"
|
|
bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|
|
|
<para>The file name is not restricted to
|
|
<quote>splash</quote> as shown in the above example. It
|
|
can be anything as long as it is one of the supported
|
|
types such as,
|
|
<filename><replaceable>splash_640x400</replaceable>.bmp</filename>
|
|
or
|
|
<filename><replaceable>bluewave</replaceable>.pcx</filename>.</para>
|
|
|
|
<para>Other interesting <filename>loader.conf</filename>
|
|
options include:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>beastie_disable="YES"</literal></term>
|
|
|
|
<listitem>
|
|
<para>This will stop the boot options menu from being
|
|
displayed, but the timed wait count down prompt will
|
|
still be present. Even with the display of the boot
|
|
options menu disabled, entering an option selection
|
|
at the timed wait count down prompt will enact the
|
|
corresponding boot option.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>loader_logo="beastie"</literal></term>
|
|
|
|
<listitem>
|
|
<para>This will replace the default words
|
|
<quote>&os;</quote>, which are displayed to the
|
|
right of the boot options menu with the colored
|
|
beastie logo.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>For more information, refer to &man.splash.4;,
|
|
&man.loader.conf.5;, and &man.vga.4;.</para>
|
|
</sect4>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="boot-kernel">
|
|
<title>Kernel Interaction During Boot</title>
|
|
|
|
<indexterm>
|
|
<primary>kernel</primary>
|
|
<secondary>boot interaction</secondary>
|
|
</indexterm>
|
|
|
|
<para>Once the kernel is loaded by either the default loader
|
|
(<xref linkend="boot-loader"/>) or by boot2 (<xref
|
|
linkend="boot-boot1"/>), which bypasses the loader, it
|
|
examines any boot flags and adjusts its behavior as
|
|
necessary.</para>
|
|
|
|
<sect2 id="boot-kernel-bootflags">
|
|
<title>Kernel Boot Flags</title>
|
|
|
|
<indexterm>
|
|
<primary>kernel</primary>
|
|
<secondary>bootflags</secondary>
|
|
</indexterm>
|
|
|
|
<para>Here are the more common boot flags:</para>
|
|
|
|
<variablelist id="boot-kernel-bootflags-list">
|
|
<varlistentry>
|
|
<term><option>-a</option></term>
|
|
|
|
<listitem>
|
|
<para>During kernel initialization, ask for the device
|
|
to mount as the root file system.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-C</option></term>
|
|
|
|
<listitem>
|
|
<para>Boot from CDROM.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-c</option></term>
|
|
|
|
<listitem>
|
|
<para>Run UserConfig, the boot-time kernel
|
|
configurator.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-s</option></term>
|
|
|
|
<listitem>
|
|
<para>Boot into single-user mode.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-v</option></term>
|
|
|
|
<listitem>
|
|
<para>Be more verbose during kernel startup.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<note>
|
|
<para>Refer to &man.boot.8; for more information on the other
|
|
boot flags.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<!-- <sect2 id="boot-kernel-userconfig">
|
|
<title>UserConfig: the Boot-time Kernel Configurator</title>
|
|
|
|
<para> </para>
|
|
</sect2> -->
|
|
</sect1>
|
|
|
|
<sect1 id="device-hints">
|
|
<sect1info>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
<surname>Rhodes</surname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
<!-- 18 OCT 2002 -->
|
|
</sect1info>
|
|
|
|
<title>Device Hints</title>
|
|
|
|
<indexterm>
|
|
<primary>device.hints</primary>
|
|
</indexterm>
|
|
|
|
<para>During initial system startup, the boot &man.loader.8; reads
|
|
&man.device.hints.5;. This file stores kernel boot information
|
|
known as variables, sometimes referred to as
|
|
<quote>device hints</quote>. These <quote>device hints</quote>
|
|
are used by device drivers for device configuration.</para>
|
|
|
|
<para>Device hints may also be specified at the Stage 3 boot
|
|
loader prompt, as demonstrated in <xref
|
|
linkend="boot-loader"/>.
|
|
Variables can be added using <command>set</command>, removed
|
|
with <command>unset</command>, and viewed
|
|
<command>show</command>. Variables set in
|
|
<filename>/boot/device.hints</filename> can also be overridden.
|
|
Device hints entered at the boot loader are not permanent and
|
|
will not be applied on the next reboot.</para>
|
|
|
|
<para>Once the system is booted, &man.kenv.1; can be used to dump
|
|
all of the variables.</para>
|
|
|
|
<para>The syntax for <filename>/boot/device.hints</filename>
|
|
is one variable per line, using the hash
|
|
<quote>#</quote> as comment markers. Lines are constructed as
|
|
follows:</para>
|
|
|
|
<screen><userinput>hint.driver.unit.keyword="<replaceable>value</replaceable>"</userinput></screen>
|
|
|
|
<para>The syntax for the Stage 3 boot loader is:</para>
|
|
|
|
<screen><userinput>set hint.driver.unit.keyword=<replaceable>value</replaceable></userinput></screen>
|
|
|
|
<para>where <literal>driver</literal> is the device driver name,
|
|
<literal>unit</literal> is the device driver unit number, and
|
|
<literal>keyword</literal> is the hint keyword. The keyword may
|
|
consist of the following options:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>at</literal>: specifies the bus which the
|
|
device is attached to.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>port</literal>: specifies the start address of
|
|
the <acronym>I/O</acronym> to be used.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>irq</literal>: specifies the interrupt request
|
|
number to be used.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>drq</literal>: specifies the DMA channel
|
|
number.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>maddr</literal>: specifies the physical memory
|
|
address occupied by the device.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>flags</literal>: sets various flag bits for the
|
|
device.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>disabled</literal>: if set to
|
|
<literal>1</literal> the device is disabled.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Since device drivers may accept or require more hints not
|
|
listed here, viewing a driver's manual page is recommended.
|
|
For more information, refer to &man.device.hints.5;,
|
|
&man.kenv.1;, &man.loader.conf.5;, and &man.loader.8;.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="boot-init">
|
|
<title>Init: Process Control Initialization</title>
|
|
|
|
<indexterm>
|
|
<primary>&man.init.8;</primary>
|
|
</indexterm>
|
|
|
|
<para>Once the kernel has finished booting, it passes control to
|
|
the user process &man.init.8;, which is located at
|
|
<filename>/sbin/init</filename>, or the program path specified
|
|
in the <envar>init_path</envar> variable in
|
|
<command>loader</command>.</para>
|
|
|
|
<sect2 id="boot-autoreboot">
|
|
<title>Automatic Reboot Sequence</title>
|
|
|
|
<para>The automatic reboot sequence makes sure that the file
|
|
systems available on the system are consistent. If they are
|
|
not, and &man.fsck.8; cannot fix the inconsistencies of a UFS
|
|
file system, &man.init.8; drops the system into single-user
|
|
mode (<xref linkend="boot-singleuser"/>) so that the system
|
|
administrator can resolve the problem directly.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="boot-singleuser">
|
|
<title>Single-User Mode</title>
|
|
|
|
<indexterm><primary>single-user mode</primary></indexterm>
|
|
<indexterm><primary>console</primary></indexterm>
|
|
|
|
<para>This mode can be reached through the automatic reboot
|
|
sequence (<xref linkend="boot-autoreboot"/>), the user booting
|
|
with <option>-s</option>, or by setting the <envar>boot_
|
|
single</envar> variable in &man.loader.8;.</para>
|
|
|
|
<para>It can also be reached by calling &man.shutdown.8; from
|
|
multi-user mode (<xref linkend="boot-multiuser"/>) without
|
|
including <option>-r</option> or <option>-h</option>.</para>
|
|
|
|
<para>If the system <literal>console</literal> is set to
|
|
<literal>insecure</literal> in <filename>/etc/ttys</filename>,
|
|
the system will prompt for the <username>root</username>
|
|
password before initiating single-user mode.</para>
|
|
|
|
<example id="boot-insecure-console">
|
|
<title>An Insecure Console in
|
|
<filename>/etc/ttys</filename></title>
|
|
|
|
<programlisting># 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 insecure</programlisting>
|
|
</example>
|
|
|
|
<note>
|
|
<para>An <literal>insecure</literal> console means that
|
|
physical security to the console is considered to be
|
|
insecure, so only someone who knows the
|
|
<username>root</username> password may use single-user mode.
|
|
Thus, to add this measure of security, choose
|
|
<literal>insecure</literal>, instead of the default of
|
|
<literal>secure</literal>.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 id="boot-multiuser">
|
|
<title>Multi-User Mode</title>
|
|
|
|
<indexterm><primary>multi-user mode</primary></indexterm>
|
|
|
|
<para>If &man.init.8; finds the file systems to be in order, or
|
|
once the user has finished their commands in single-user
|
|
mode (<xref linkend="boot-singleuser"/>), the system enters
|
|
multi-user mode, in which it starts the resource configuration
|
|
of the system.</para>
|
|
|
|
<sect3 id="boot-rc">
|
|
<title>Resource Configuration</title>
|
|
|
|
<indexterm><primary>rc files</primary></indexterm>
|
|
|
|
<para>The resource configuration system reads in
|
|
configuration defaults from
|
|
<filename>/etc/defaults/rc.conf</filename>, and
|
|
system-specific details from
|
|
<filename>/etc/rc.conf</filename>, and then proceeds to
|
|
mount the system file systems listed in
|
|
<filename>/etc/fstab</filename>. It starts up networking
|
|
services, miscellaneous system daemons, then the startup
|
|
scripts of locally installed packages.</para>
|
|
|
|
<para>To learn more about the resource configuration system,
|
|
refer to &man.rc.8; and examine the scripts
|
|
themselves.</para>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="boot-shutdown">
|
|
<title>Shutdown Sequence</title>
|
|
|
|
<indexterm>
|
|
<primary>&man.shutdown.8;</primary>
|
|
</indexterm>
|
|
|
|
<para>Upon controlled shutdown using &man.shutdown.8;,
|
|
&man.init.8; will attempt to run the script
|
|
<filename>/etc/rc.shutdown</filename>, and then proceed to send
|
|
all processes the <literal>TERM</literal> signal, and
|
|
subsequently the <literal>KILL</literal> signal to any that do
|
|
not terminate in a timely manner.</para>
|
|
|
|
<para>To power down a &os; machine on architectures and systems
|
|
that support power management, use <command>shutdown -p
|
|
now</command> to turn the power off immediately. To reboot a
|
|
&os; system, use <command>shutdown -r now</command>. One must
|
|
be <username>root</username> or a member of
|
|
<groupname>operator</groupname> in order to run
|
|
&man.shutdown.8;. One can also use &man.halt.8; and
|
|
&man.reboot.8;. Refer to their manual pages and to
|
|
&man.shutdown.8; for more information.</para>
|
|
|
|
<note>
|
|
<para>Power management requires &man.acpi.4; to be loaded as
|
|
a module or staticly compiled into a custom kernel.</para>
|
|
</note>
|
|
</sect1>
|
|
</chapter>
|