This patch addresses the following:
- replaces FreeBSD with &os; - rewording to replace "you" - updated the F1 example - general tightening and grammar fixes Approved by: bcr (mentor)
This commit is contained in:
Dru Lavigne
parent
26ad361dd2
commit
347ca9efc9
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=40887
1 changed files with 250 additions and 303 deletions
|
|
@ -6,7 +6,7 @@
|
|||
-->
|
||||
|
||||
<chapter id="boot">
|
||||
<title>The FreeBSD Booting Process</title>
|
||||
<title>The &os; Booting Process</title>
|
||||
|
||||
<sect1 id="boot-synopsis">
|
||||
<title>Synopsis</title>
|
||||
|
|
@ -16,31 +16,31 @@
|
|||
|
||||
<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>. FreeBSD's boot process
|
||||
or simply <quote>booting</quote>. &os;'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.</para>
|
||||
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 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.</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 know:</para>
|
||||
<para>After reading this chapter, you will recognize:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>What the components of the FreeBSD bootstrap system are,
|
||||
and how they interact.</para>
|
||||
<para>The components of the &os; bootstrap system and how they
|
||||
interact.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The options you can give to the components in the
|
||||
FreeBSD bootstrap to control the boot process.</para>
|
||||
<para>The options that can be passed to the components in the
|
||||
&os; bootstrap in order to control the boot process.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -49,9 +49,7 @@
|
|||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<title>x86 Only</title>
|
||||
|
||||
<para>This chapter only describes the boot process for FreeBSD
|
||||
<para>This chapter only describes the boot process for &os;
|
||||
running on Intel x86 systems.</para>
|
||||
</note>
|
||||
</sect1>
|
||||
|
|
@ -62,7 +60,7 @@
|
|||
<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. So if
|
||||
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>
|
||||
|
|
@ -102,7 +100,7 @@
|
|||
with the user. In this case the boot manager usually has more
|
||||
code in the first <emphasis>track</emphasis> of the disk or
|
||||
within some OS's file system. (A boot manager is sometimes also
|
||||
called a <emphasis>boot loader</emphasis>, but FreeBSD uses that
|
||||
called a <emphasis>boot loader</emphasis>, but &os; uses that
|
||||
term for a later stage of booting.) Popular boot managers
|
||||
include <application>boot0</application> (aka
|
||||
<application>Boot Easy</application>, the standard &os; boot
|
||||
|
|
@ -111,30 +109,28 @@
|
|||
<application>LILO</application>. (Only
|
||||
<application>boot0</application> fits within the MBR.)</para>
|
||||
|
||||
<para>If you have only one operating system installed on your
|
||||
disks then a standard PC MBR will suffice. This MBR searches
|
||||
for the first bootable (aka active) slice on the disk, and
|
||||
then runs the code on that slice to load the remainder of the
|
||||
operating system. The MBR installed by &man.fdisk.8;, by
|
||||
default, is such an MBR. It is based on
|
||||
<para>If only one operating system is installed, a standard PC MBR
|
||||
will suffice. This MBR 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 MBR
|
||||
installed by &man.fdisk.8; is such an MBR and is based on
|
||||
<filename>/boot/mbr</filename>.</para>
|
||||
|
||||
<para>If you have installed multiple operating systems on your
|
||||
disks then you can install a different boot manager, one that
|
||||
can display a list of different operating systems, and allows
|
||||
you to choose the one to boot from. Two of these are discussed
|
||||
in the next subsection.</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 FreeBSD bootstrap system is divided
|
||||
<para>The remainder of the &os; 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.</para>
|
||||
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><command>init</command></primary></indexterm>
|
||||
|
|
@ -145,9 +141,8 @@
|
|||
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 generally starts all the
|
||||
processes that usually are run on a FreeBSD system at
|
||||
startup.</para>
|
||||
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">
|
||||
|
|
@ -163,60 +158,54 @@
|
|||
|
||||
<para>The code in the MBR or boot manager is sometimes referred
|
||||
to as <emphasis>stage zero</emphasis> of the boot process.
|
||||
This subsection discusses two of the boot managers previously
|
||||
mentioned: <application>boot0</application> and
|
||||
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 MBR installed by FreeBSD's installer or
|
||||
&man.boot0cfg.8;, by default, is based on
|
||||
<filename>/boot/boot0</filename>. (The
|
||||
<application>boot0</application> program is very simple,
|
||||
since the program in the <abbrev>MBR</abbrev> can only be
|
||||
446 bytes long because of the slice table and
|
||||
<literal>0x55AA</literal> identifier at the end of the MBR.)
|
||||
If you have installed <application>boot0</application> and
|
||||
multiple operating systems on your hard disks, then you will
|
||||
see a display similar to this one at boot
|
||||
time:</para>
|
||||
<para>The MBR 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 MBR. 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 DOS
|
||||
<screen>F1 Windows
|
||||
F2 FreeBSD
|
||||
F3 Linux
|
||||
F4 ??
|
||||
F5 Drive 1
|
||||
|
||||
Default: F2</screen>
|
||||
</example>
|
||||
|
||||
<para>Other operating systems, in particular &windows;, 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:</para>
|
||||
<para>Other operating systems, in particular &windows;, will
|
||||
overwrite an existing MBR if they are installed after &os;.
|
||||
If this happens, or you want to replace the existing MBR
|
||||
with the &os; MBR, 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 device that
|
||||
you boot from, such as <devicename>ad0</devicename> for the
|
||||
first IDE disk, <devicename>ad2</devicename> for the first IDE
|
||||
disk on a second IDE controller, <devicename>da0</devicename>
|
||||
for the first SCSI disk, and so on. Or, if you want a custom
|
||||
configuration of the MBR, use &man.boot0cfg.8;.</para>
|
||||
<para>where <replaceable>device</replaceable> is the boot disk,
|
||||
such as <devicename>ad0</devicename> for the first IDE disk,
|
||||
<devicename>ad2</devicename> for the first IDE disk on a
|
||||
second IDE controller, or <devicename>da0</devicename>
|
||||
for the first SCSI disk. To create a custom configuration of
|
||||
the MBR, refer to &man.boot0cfg.8;.</para>
|
||||
|
||||
<formalpara>
|
||||
<title>The LILO Boot Manager:</title>
|
||||
|
||||
<para>To install this boot manager so it will also boot
|
||||
FreeBSD, first start Linux and add the following to your
|
||||
existing <filename>/etc/lilo.conf</filename> configuration
|
||||
file:</para>
|
||||
&os;, boot into Linux and add the following to the existing
|
||||
<filename>/etc/lilo.conf</filename> configuration:</para>
|
||||
</formalpara>
|
||||
|
||||
<programlisting>other=/dev/hdXY
|
||||
|
|
@ -224,30 +213,29 @@ table=/dev/hdX
|
|||
loader=/boot/chain.b
|
||||
label=FreeBSD</programlisting>
|
||||
|
||||
<para>In the above, specify FreeBSD'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. If you are using a <acronym>SCSI</acronym> drive, you
|
||||
will need to change <replaceable>/dev/hd</replaceable> to read
|
||||
something similar to <replaceable>/dev/sd</replaceable>. The
|
||||
<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
|
||||
you have both operating systems on the same drive. Now run
|
||||
<command>/sbin/lilo -v</command> to commit your new
|
||||
changes to the system; this should be verified by checking its
|
||||
screen messages.</para>
|
||||
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
|
||||
<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 you would
|
||||
always install them together. They are copied from the
|
||||
combined file <filename>/boot/boot</filename> by the installer
|
||||
or <application>bsdlabel</application> (see below).</para>
|
||||
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
|
||||
<application>bsdlabel</application>.</para>
|
||||
|
||||
<para>They are located outside file systems, in the first track
|
||||
of the boot slice, starting with the first sector. This is
|
||||
|
|
@ -259,20 +247,18 @@ label=FreeBSD</programlisting>
|
|||
|
||||
<para><filename>boot1</filename> is very simple, since it can
|
||||
only be 512 bytes in size, and knows just enough about the
|
||||
FreeBSD <firstterm>bsdlabel</firstterm>, which stores
|
||||
&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 FreeBSD file system enough to find files
|
||||
on it, and can provide a simple interface to choose the kernel
|
||||
or loader to run.</para>
|
||||
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>Since the <link linkend="boot-loader">loader</link> is
|
||||
much more sophisticated, and provides a nice easy-to-use
|
||||
boot configuration, <filename>boot2</filename> usually runs
|
||||
it, but previously it
|
||||
was tasked to run the kernel directly.</para>
|
||||
<para><link linkend="boot-loader">loader</link> 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>
|
||||
|
|
@ -282,25 +268,26 @@ Default: 0:ad(0,a)/boot/loader
|
|||
boot:</screen>
|
||||
</example>
|
||||
|
||||
<para>If you ever need to replace the installed
|
||||
<filename>boot1</filename> and <filename>boot2</filename> use
|
||||
&man.bsdlabel.8;:</para>
|
||||
<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 you boot from, such as <devicename>ad0s1</devicename>
|
||||
slice to boot from, such as <devicename>ad0s1</devicename>
|
||||
for the first slice on the first IDE disk.</para>
|
||||
|
||||
<warning>
|
||||
<title>Dangerously Dedicated Mode</title>
|
||||
|
||||
<para>If you use just the disk name, such as
|
||||
<devicename>ad0</devicename>, in the &man.bsdlabel.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.bsdlabel.8;
|
||||
command before you press <keycap>Return</keycap>.</para>
|
||||
<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>
|
||||
|
||||
|
|
@ -313,16 +300,16 @@ boot:</screen>
|
|||
bootstrap, and is located on the file system, usually as
|
||||
<filename>/boot/loader</filename>.</para>
|
||||
|
||||
<para>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.</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 what disk it is
|
||||
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>
|
||||
|
|
@ -342,16 +329,16 @@ boot:</screen>
|
|||
<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 easy-to-use command set, where
|
||||
the user may adjust variables, unload all modules, load
|
||||
modules, and then finally boot or reboot.</para>
|
||||
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, please see
|
||||
complete discussion of all available commands, refer to
|
||||
&man.loader.8;.</para>
|
||||
|
||||
<variablelist>
|
||||
|
|
@ -372,11 +359,10 @@ boot:</screen>
|
|||
<optional><replaceable>kernelname</replaceable></optional></term>
|
||||
|
||||
<listitem>
|
||||
<para>Immediately proceeds to boot the kernel, with the
|
||||
given options, if any, and with the kernel name given,
|
||||
if it is. Providing a kernel name on the command-line
|
||||
is only applicable after an
|
||||
<emphasis>unload</emphasis> command has been issued,
|
||||
<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>
|
||||
|
|
@ -387,10 +373,10 @@ boot:</screen>
|
|||
|
||||
<listitem>
|
||||
<para>Goes through the same automatic configuration of
|
||||
modules based on variables as what happens at boot.
|
||||
This only makes sense if you use
|
||||
<command>unload</command> first, and change some
|
||||
variables, most commonly <envar>kernel</envar>.</para>
|
||||
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>
|
||||
|
||||
|
|
@ -401,8 +387,8 @@ boot:</screen>
|
|||
<listitem>
|
||||
<para>Shows help messages read from
|
||||
<filename>/boot/loader.help</filename>. If the topic
|
||||
given is <literal>index</literal>, then the list of
|
||||
available topics is given.</para>
|
||||
given is <literal>index</literal>, the list of
|
||||
available topics is displayed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -412,7 +398,7 @@ boot:</screen>
|
|||
|
||||
<listitem>
|
||||
<para>Processes the file with the given filename. The
|
||||
file is read in, and interpreted line by line. An
|
||||
file is read in and interpreted line by line. An
|
||||
error immediately stops the include command.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -424,8 +410,9 @@ boot:</screen>
|
|||
|
||||
<listitem>
|
||||
<para>Loads the kernel, kernel module, or file of the
|
||||
type given, with the filename given. Any arguments
|
||||
after filename are passed to the file.</para>
|
||||
type given, with the specified filename. Any
|
||||
arguments after <replaceable>filename</replaceable>
|
||||
are passed to the file.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -436,8 +423,8 @@ boot:</screen>
|
|||
<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 be
|
||||
shown too.</para>
|
||||
<option>-l</option> is specified, file sizes will
|
||||
also be shown.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -508,15 +495,14 @@ boot:</screen>
|
|||
<indexterm><primary>single-user mode</primary></indexterm>
|
||||
|
||||
<listitem>
|
||||
<para>To boot your usual kernel, but in single-user
|
||||
mode:</para>
|
||||
<para>To boot the usual kernel in single-user mode:</para>
|
||||
|
||||
<screen><userinput>boot -s</userinput></screen>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>To unload your usual kernel and modules, and then
|
||||
load just your old (or another) kernel:</para>
|
||||
<para>To unload the usual kernel and modules, and then
|
||||
load the previous or another kernel:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary><filename>kernel.old</filename></primary>
|
||||
|
|
@ -525,14 +511,14 @@ boot:</screen>
|
|||
<screen><userinput>unload</userinput>
|
||||
<userinput>load <replaceable>kernel.old</replaceable></userinput></screen>
|
||||
|
||||
<para>You can use <filename>kernel.GENERIC</filename> to
|
||||
refer to the generic kernel that comes on the install
|
||||
disk, or <filename>kernel.old</filename> to refer to
|
||||
your previously installed kernel (when you have upgraded
|
||||
or configured your own kernel, for example).</para>
|
||||
<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 your usual modules with
|
||||
<para>Use the following to load the usual modules with
|
||||
another kernel:</para>
|
||||
|
||||
<screen><userinput>unload</userinput>
|
||||
|
|
@ -541,9 +527,8 @@ boot:</screen>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>To load a kernel configuration script (an automated
|
||||
script which does the things you would normally do in
|
||||
the kernel boot-time configurator):</para>
|
||||
<para>To load an automated kernel configuration
|
||||
script:</para>
|
||||
|
||||
<screen><userinput>load -t userconfig_script <replaceable>/boot/kernel.conf</replaceable></userinput></screen>
|
||||
</listitem>
|
||||
|
|
@ -563,89 +548,58 @@ boot:</screen>
|
|||
|
||||
<title>Boot Time Splash Screens</title>
|
||||
|
||||
<para>The splash screen creates a more visually appealing boot
|
||||
screen compared to the original boot messages. This screen
|
||||
will be displayed until a console login prompt or an X
|
||||
display manager offers a login prompt.</para>
|
||||
<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
|
||||
X11 Desktop graphical environment. After
|
||||
<link linkend="x-install">X11</link> and one of the
|
||||
graphical
|
||||
<link linkend="x11-wm">desktop environments</link>, such as
|
||||
<application>GNOME</application>,
|
||||
<application>KDE</application>, or
|
||||
<application>XFce</application> are installed, the X11
|
||||
desktop can be launched by using
|
||||
<command>startx</command>.</para>
|
||||
|
||||
<para>Some users prefer the X11 graphical login screen over
|
||||
the traditional text based login prompt. Display managers
|
||||
like <application>XDM</application> for &xorg;,
|
||||
<application>gdm</application> for
|
||||
<application>GNOME</application>, and
|
||||
<application>kdm</application> for
|
||||
<application>KDE</application> (and any other from the Ports
|
||||
Collection) provide a graphical login screen in
|
||||
place of the console login prompt. After a successful
|
||||
login, they present the user with a graphical
|
||||
desktop.</para>
|
||||
|
||||
<para>In the command line environment, the splash screen would
|
||||
hide all the boot probe messages and task startup messages
|
||||
before displaying the login prompt. In X11 environment, the
|
||||
users would get a visually clearer system start up
|
||||
experience resembling something closer to what a
|
||||
(µsoft; &windows; or non-unix type system) user would
|
||||
experience.</para>
|
||||
graphical environment provided by
|
||||
<link linkend="x11">Xorg</link>. 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-color
|
||||
<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>) files.
|
||||
In addition, the splash image files must have a resolution
|
||||
of 320 by 200 pixels or less to work on standard VGA
|
||||
adapters.</para>
|
||||
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, activate the <acronym>VESA</acronym>
|
||||
support included in &os;. This can be enabled by loading
|
||||
the <acronym>VESA</acronym> module during system boot, or
|
||||
adding a <literal>VESA</literal> kernel configuration
|
||||
option and building a custom kernel (see <xref
|
||||
linkend="kernelconfig"/>). The <acronym>VESA</acronym>
|
||||
support gives users the ability to display a splash screen
|
||||
image that fills the whole display screen.</para>
|
||||
1024 by 768 pixels, load the <acronym>VESA</acronym>
|
||||
module during system boot. For a <xref
|
||||
linkend="kernelconfig">custom kernel</xref>, 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 of X11. After a time period of non-use the
|
||||
screen will change to the splash screen and cycle through
|
||||
steps of changing intensity of the image, from bright to a
|
||||
very dark and over again. This default splash screen
|
||||
(screen saver) behavior could be overridden by adding a
|
||||
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>. Option
|
||||
<literal>saver=</literal> has several built-in screen
|
||||
savers to choose from, the full list can be found in the
|
||||
&man.splash.4; manual page. The default screen saver is
|
||||
called <quote>warp</quote>. Note that the
|
||||
<literal>saver=</literal> option specified in
|
||||
<filename>/etc/rc.conf</filename> only applies to virtual
|
||||
consoles. It has no effect on X11 display
|
||||
managers.</para>
|
||||
<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
|
||||
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
|
||||
|
|
@ -660,15 +614,14 @@ boot:</screen>
|
|||
<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>)
|
||||
file has to be placed on the root partition, for example
|
||||
in the <filename class="directory">/boot</filename>
|
||||
directory.</para>
|
||||
<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 default boot display resolution (256-color, 320 by
|
||||
200 pixels, or less), edit
|
||||
<filename>/boot/loader.conf</filename>, so it contains the
|
||||
<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"
|
||||
|
|
@ -685,19 +638,19 @@ splash_bmp_load="YES"
|
|||
bitmap_load="YES"
|
||||
bitmap_name="<replaceable>/boot/splash.bmp</replaceable>"</programlisting>
|
||||
|
||||
<para>The above assumes that
|
||||
<para>This example assumes that
|
||||
<filename><replaceable>/boot/splash.bmp</replaceable></filename>
|
||||
is used for splash screen. When a <acronym>PCX</acronym>
|
||||
file is desired, use the following statements, plus the
|
||||
<literal>vesa_load="YES"</literal> line depending on the
|
||||
resolution.</para>
|
||||
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>In version 8.3 another option is to use ascii art in
|
||||
<ulink
|
||||
<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>
|
||||
|
||||
|
|
@ -707,14 +660,14 @@ 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 above types
|
||||
such as,
|
||||
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>Some other interesting
|
||||
<filename>loader.conf</filename> options:</para>
|
||||
<para>Other interesting
|
||||
<filename>loader.conf</filename> options include:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
|
|
@ -737,13 +690,13 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<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 like releases in the past had.</para>
|
||||
beastie logo.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>For more information, please see the &man.splash.4;,
|
||||
&man.loader.conf.5;, and &man.vga.4; manual pages.</para>
|
||||
<para>For more information, refer to &man.splash.4;,
|
||||
&man.loader.conf.5;, and &man.vga.4;.</para>
|
||||
</sect4>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
|
@ -757,10 +710,10 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<secondary>boot interaction</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Once the kernel is loaded by either <link
|
||||
linkend="boot-loader">loader</link> (as usual) or <link
|
||||
linkend="boot-boot1">boot2</link> (bypassing the loader), it
|
||||
examines its boot flags, if any, and adjusts its behavior as
|
||||
<para>Once the kernel is loaded by either the default <link
|
||||
linkend="boot-loader">loader</link> or by <link
|
||||
linkend="boot-boot1">boot2</link> which bypasses the loader,
|
||||
it examines its boot flags, if any, and adjusts its behavior as
|
||||
necessary.</para>
|
||||
|
||||
<sect2 id="boot-kernel-bootflags">
|
||||
|
|
@ -778,7 +731,7 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<term><option>-a</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>during kernel initialization, ask for the device
|
||||
<para>During kernel initialization, ask for the device
|
||||
to mount as the root file system.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -787,7 +740,7 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<term><option>-C</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>boot from CDROM.</para>
|
||||
<para>Boot from CDROM.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -795,8 +748,8 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<term><option>-c</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>run UserConfig, the boot-time kernel
|
||||
configurator</para>
|
||||
<para>Run UserConfig, the boot-time kernel
|
||||
configurator.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -804,7 +757,7 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<term><option>-s</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>boot into single-user mode</para>
|
||||
<para>Boot into single-user mode.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -812,14 +765,14 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<term><option>-v</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>be more verbose during kernel startup</para>
|
||||
<para>Be more verbose during kernel startup.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<note>
|
||||
<para>There are other boot flags, read &man.boot.8; for more
|
||||
information on them.</para>
|
||||
<para>Refer to &man.boot.8; for more information on the other
|
||||
boot flags.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
||||
|
|
@ -848,27 +801,26 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<primary>device.hints</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>During initial system startup, the boot &man.loader.8; will
|
||||
read the &man.device.hints.5; file. This file stores kernel
|
||||
boot information known as variables, sometimes referred to as
|
||||
<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
|
||||
<link linkend="boot-loader">
|
||||
Stage 3 boot loader</link> prompt. Variables can be added using
|
||||
<command>set</command>, removed with <command>unset</command>,
|
||||
and viewed with the <command>show</command> commands. Variables
|
||||
set in <filename>/boot/device.hints</filename> can be
|
||||
overridden here also. Device hints entered at the boot loader
|
||||
are not permanent and will be forgotten on the next
|
||||
reboot.</para>
|
||||
<para>Device hints may also be specified at the <link
|
||||
linkend="boot-loader"> Stage 3 boot loader</link> prompt.
|
||||
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, the &man.kenv.1; command can be
|
||||
used to dump all of the variables.</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 standard hash
|
||||
is one variable per line, using the hash
|
||||
<quote>#</quote> as comment markers. Lines are constructed as
|
||||
follows:</para>
|
||||
|
||||
|
|
@ -878,7 +830,7 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
|
||||
<screen><userinput>set hint.driver.unit.keyword=<replaceable>value</replaceable></userinput></screen>
|
||||
|
||||
<para><literal>driver</literal> is the device driver name,
|
||||
<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>
|
||||
|
|
@ -920,10 +872,10 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Device drivers may accept (or require) more hints not listed
|
||||
here, viewing their manual page is recommended. For more
|
||||
information, consult the &man.device.hints.5;, &man.kenv.1;,
|
||||
&man.loader.conf.5;, and &man.loader.8; manual pages.</para>
|
||||
<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">
|
||||
|
|
@ -944,10 +896,10 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
|
||||
<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,
|
||||
&man.init.8; drops the system into
|
||||
<link linkend="boot-singleuser">single-user mode</link> for
|
||||
the system administrator to take care of the problems
|
||||
not, and &man.fsck.8; cannot fix the inconsistencies of a UFS
|
||||
file system, &man.init.8; drops the system into
|
||||
<link linkend="boot-singleuser">single-user mode</link> so
|
||||
that the system administrator can resolve the problem
|
||||
directly.</para>
|
||||
</sect2>
|
||||
|
||||
|
|
@ -957,21 +909,19 @@ bitmap_name="<replaceable>/boot/splash.bin</replaceable>"</programlisting>
|
|||
<indexterm><primary>single-user mode</primary></indexterm>
|
||||
<indexterm><primary>console</primary></indexterm>
|
||||
|
||||
<para>This mode can be reached through the
|
||||
<link linkend="boot-autoreboot">automatic reboot
|
||||
sequence</link>, or by the user booting with the
|
||||
<option>-s</option> option or setting the
|
||||
<envar>boot_single</envar> variable in
|
||||
<para>This mode can be reached through the <link
|
||||
linkend="boot-autoreboot">automatic reboot sequence</link>,
|
||||
the user booting with <option>-s</option>, or by setting
|
||||
the <envar>boot_single</envar> variable in
|
||||
<command>loader</command>.</para>
|
||||
|
||||
<para>It can also be reached by calling &man.shutdown.8; without
|
||||
the reboot (<option>-r</option>) or halt (<option>-h</option>)
|
||||
options, from <link linkend="boot-multiuser">multi-user
|
||||
mode</link>.</para>
|
||||
<para>It can also be reached by calling &man.shutdown.8; from
|
||||
<link linkend="boot-multiuser">multi-user mode</link> 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>,
|
||||
then the system prompts for the <username>root</username>
|
||||
the system will prompt for the <username>root</username>
|
||||
password before initiating single-user mode.</para>
|
||||
|
||||
<example id="boot-insecure-console">
|
||||
|
|
@ -986,13 +936,12 @@ console none unknown off insecure</programlisting>
|
|||
</example>
|
||||
|
||||
<note>
|
||||
<para>An <literal>insecure</literal> console means that you
|
||||
consider your physical security to the console to be
|
||||
insecure, and want to make sure only someone who knows the
|
||||
<username>root</username> 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
|
||||
<literal>insecure</literal>, not
|
||||
<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>
|
||||
|
|
@ -1002,8 +951,8 @@ console none unknown off insecure</programlisting>
|
|||
|
||||
<indexterm><primary>multi-user mode</primary></indexterm>
|
||||
|
||||
<para>If &man.init.8; finds your file systems to be in order, or
|
||||
once the user has finished in <link
|
||||
<para>If &man.init.8; finds the file systems to be in order, or
|
||||
once the user has finished their commands in <link
|
||||
linkend="boot-singleuser">single-user mode</link>, the
|
||||
system enters multi-user mode, in which it starts the
|
||||
resource configuration of the system.</para>
|
||||
|
|
@ -1018,14 +967,13 @@ console none unknown off insecure</programlisting>
|
|||
<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 mentioned in
|
||||
<filename>/etc/fstab</filename>, start up networking
|
||||
services, start up miscellaneous system daemons, and
|
||||
finally runs the startup scripts of locally installed
|
||||
packages.</para>
|
||||
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>The &man.rc.8; manual page is a good reference to the
|
||||
resource configuration system, as is examining the scripts
|
||||
<para>To learn more about the resource configuration system,
|
||||
refer to &man.rc.8; and examine the scripts
|
||||
themselves.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
|
@ -1038,27 +986,26 @@ console none unknown off insecure</programlisting>
|
|||
<primary><command>shutdown</command></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Upon controlled shutdown, via &man.shutdown.8;,
|
||||
<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 timely.</para>
|
||||
not terminate in a timely manner.</para>
|
||||
|
||||
<para>To power down a FreeBSD machine on architectures and systems
|
||||
that support power management, use the command
|
||||
<command>shutdown -p now</command> to turn the power off
|
||||
immediately. To just reboot a FreeBSD system, just use
|
||||
<command>shutdown -r now</command>. You need to be
|
||||
<username>root</username> or a member of
|
||||
<groupname>operator</groupname> group to run &man.shutdown.8;.
|
||||
The &man.halt.8; and &man.reboot.8; commands can also be used,
|
||||
please refer to their manual pages and to &man.shutdown.8;'s one
|
||||
for more information.</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 the
|
||||
<groupname>operator</groupname> group 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; support in the
|
||||
kernel or loaded as module for.</para>
|
||||
<para>Power management requires &man.acpi.4; to be loaded as
|
||||
a module or staticly compiled into a custom kernel.</para>
|
||||
</note>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
Loading…
Reference in a new issue