White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
975448b637
commit
6304abcc62
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44628
1 changed files with 411 additions and 415 deletions
|
|
@ -19,12 +19,12 @@
|
|||
|
||||
<para>The process of starting a computer and loading the operating
|
||||
system is referred to as <quote>the bootstrap process</quote>,
|
||||
or <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>
|
||||
or <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,
|
||||
|
|
@ -77,13 +77,13 @@
|
|||
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>
|
||||
<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>
|
||||
|
||||
|
|
@ -92,14 +92,14 @@
|
|||
|
||||
<para>On x86 hardware, the Basic Input/Output System
|
||||
(<acronym>BIOS</acronym>) is responsible for loading the
|
||||
operating system. 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>
|
||||
operating system. 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>
|
||||
|
||||
<note>
|
||||
<para>amd64 hardware is backward compatible as it understands
|
||||
|
|
@ -123,22 +123,21 @@
|
|||
|
||||
<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. The boot
|
||||
manager usually has more code in the first
|
||||
track of the disk or within the file
|
||||
system. Examples of boot managers
|
||||
include the standard &os; boot
|
||||
manager <application>boot0</application>, also called
|
||||
<application>Boot Easy</application>, and <application>Grub</application>,
|
||||
which is used by many &linux; distributions.</para>
|
||||
when it interacts with the user. The boot manager usually has
|
||||
more code in the first track of the disk or within the file
|
||||
system. Examples of boot managers include the standard &os;
|
||||
boot manager <application>boot0</application>, also called
|
||||
<application>Boot Easy</application>, and
|
||||
<application>Grub</application>, which is used by many &linux;
|
||||
distributions.</para>
|
||||
|
||||
<para>If only one operating system is installed, the
|
||||
<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. 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.</para>
|
||||
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.</para>
|
||||
|
||||
<para>The remainder of the &os; bootstrap system is divided into
|
||||
three stages. The first stage knows just enough to get the
|
||||
|
|
@ -146,21 +145,22 @@
|
|||
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
|
||||
the <acronym>MBR</acronym> puts 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>
|
||||
the <acronym>MBR</acronym> puts 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 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 makes sure the disks are in a
|
||||
usable state, 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 at startup.</para>
|
||||
<para>The kernel is then started and 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 makes sure the disks are in a usable state,
|
||||
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 at
|
||||
startup.</para>
|
||||
|
||||
<para>This section describes these stages in more detail and
|
||||
demonstrates how to interact with the &os; boot process.</para>
|
||||
|
|
@ -174,19 +174,18 @@
|
|||
(<acronym>MBR</acronym>)</primary></indexterm>
|
||||
|
||||
<para>The boot manager code in the <acronym>MBR</acronym> is
|
||||
sometimes referred to as <emphasis>stage zero</emphasis> of the
|
||||
boot process. By default, &os; uses the
|
||||
sometimes referred to as <emphasis>stage zero</emphasis> of
|
||||
the boot process. By default, &os; uses the
|
||||
<application>boot0</application> boot manager.</para>
|
||||
|
||||
<para>The <acronym>MBR</acronym> installed by the &os; installer
|
||||
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>
|
||||
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>
|
||||
|
||||
<example xml:id="boot-boot0-example">
|
||||
<title><filename>boot0</filename> Screenshot</title>
|
||||
|
|
@ -197,11 +196,11 @@ F2 FreeBSD
|
|||
Default: F2</screen>
|
||||
</example>
|
||||
|
||||
<para>Other operating systems 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>
|
||||
<para>Other operating systems 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>
|
||||
|
||||
|
|
@ -225,25 +224,26 @@ Default: F2</screen>
|
|||
<filename>/boot/boot</filename> by the &os; installer or
|
||||
<command>bsdlabel</command>.</para>
|
||||
|
||||
<para>These two stages are located outside file systems, in the first track
|
||||
of the boot slice, starting with the first sector. This is
|
||||
where <application>boot0</application>, or any other
|
||||
<para>These two stages are located outside file systems, in the
|
||||
first track of the boot slice, starting with the first sector.
|
||||
This is where <application>boot0</application>, or any other
|
||||
boot manager, expects to find a program to run which will
|
||||
continue the boot process.</para>
|
||||
|
||||
<para>The first stage, <filename>boot1</filename>, is very simple, since it can
|
||||
only be 512 bytes in size. It knows just enough about the
|
||||
&os; <firstterm>bsdlabel</firstterm>, which stores
|
||||
information about the slice, to find and execute
|
||||
<para>The first stage, <filename>boot1</filename>, is very
|
||||
simple, since it can only be 512 bytes in size. It knows just
|
||||
enough about the &os; <firstterm>bsdlabel</firstterm>, which
|
||||
stores information about the slice, to find and execute
|
||||
<filename>boot2</filename>.</para>
|
||||
|
||||
<para>Stage two, <filename>boot2</filename>, is slightly more sophisticated,
|
||||
and understands the &os; file system enough to find files. It
|
||||
can provide a simple interface to choose the kernel or loader
|
||||
to run. It runs <application>loader</application>, which is much more sophisticated and
|
||||
provides a boot configuration file. If the boot process is
|
||||
interrupted at stage two, the following interactive screen is
|
||||
displayed:</para>
|
||||
<para>Stage two, <filename>boot2</filename>, is slightly more
|
||||
sophisticated, and understands the &os; file system enough to
|
||||
find files. It can provide a simple interface to choose the
|
||||
kernel or loader to run. It runs
|
||||
<application>loader</application>, which is much more
|
||||
sophisticated and provides a boot configuration file. If the
|
||||
boot process is interrupted at stage two, the following
|
||||
interactive screen is displayed:</para>
|
||||
|
||||
<example xml:id="boot-boot2-example">
|
||||
<title><filename>boot2</filename> Screenshot</title>
|
||||
|
|
@ -253,23 +253,21 @@ Default: 0:ad(0,a)/boot/loader
|
|||
boot:</screen>
|
||||
</example>
|
||||
|
||||
<para>To replace the installed
|
||||
<filename>boot1</filename> and
|
||||
<para>To replace the installed <filename>boot1</filename> and
|
||||
<filename>boot2</filename>, use <command>bsdlabel</command>,
|
||||
where <replaceable>diskslice</replaceable> is the disk and
|
||||
slice to boot from, such as <filename>ad0s1</filename>
|
||||
for the first slice on the first <acronym>IDE</acronym>
|
||||
disk:</para>
|
||||
slice to boot from, such as <filename>ad0s1</filename> for the
|
||||
first slice on the first <acronym>IDE</acronym> disk:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>bsdlabel -B <replaceable>diskslice</replaceable></userinput></screen>
|
||||
|
||||
<warning>
|
||||
<para>If just the disk name is used, such as
|
||||
<filename>ad0</filename>, <command>bsdlabel</command> will create the disk in
|
||||
<quote>dangerously dedicated mode</quote>, without slices.
|
||||
This is probably not the desired action, so double check the
|
||||
<replaceable>diskslice</replaceable>
|
||||
before pressing
|
||||
<filename>ad0</filename>, <command>bsdlabel</command> will
|
||||
create the disk in <quote>dangerously dedicated
|
||||
mode</quote>, without slices. This is probably not the
|
||||
desired action, so double check the
|
||||
<replaceable>diskslice</replaceable> before pressing
|
||||
<keycap>Return</keycap>.</para>
|
||||
</warning>
|
||||
</sect2>
|
||||
|
|
@ -279,20 +277,21 @@ boot:</screen>
|
|||
|
||||
<indexterm><primary>boot-loader</primary></indexterm>
|
||||
|
||||
<para>The <application>loader</application> is the final stage of the three-stage
|
||||
bootstrap process. It is located on the file system, usually as
|
||||
<para>The <application>loader</application> is the final stage
|
||||
of the three-stage bootstrap process. It is located on the
|
||||
file system, usually as
|
||||
<filename>/boot/loader</filename>.</para>
|
||||
|
||||
<para>The <application>loader</application> 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>
|
||||
<para>The <application>loader</application> 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>
|
||||
|
||||
<para>During initialization, <application>loader</application> 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>
|
||||
<para>During initialization, <application>loader</application>
|
||||
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>
|
||||
|
|
@ -306,15 +305,15 @@ boot:</screen>
|
|||
these variables, loading whichever modules and kernel are
|
||||
selected.</para>
|
||||
|
||||
<para>Finally, by default, <application>loader</application> 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. <xref
|
||||
linkend="boot-loader-commands"/> lists the most
|
||||
commonly used <application>loader</application> commands. For
|
||||
a complete discussion of all available commands, refer to
|
||||
<para>Finally, by default, <application>loader</application>
|
||||
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. <xref
|
||||
linkend="boot-loader-commands"/> lists the most commonly
|
||||
used <application>loader</application> commands. For a
|
||||
complete discussion of all available commands, refer to
|
||||
&man.loader.8;.</para>
|
||||
|
||||
<table xml:id="boot-loader-commands" frame="none" pgwide="1">
|
||||
|
|
@ -330,7 +329,8 @@ boot:</screen>
|
|||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>autoboot <replaceable>seconds</replaceable></entry>
|
||||
<entry>autoboot
|
||||
<replaceable>seconds</replaceable></entry>
|
||||
<entry>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
|
||||
|
|
@ -341,10 +341,10 @@ boot:</screen>
|
|||
<entry>boot
|
||||
<optional><replaceable>-options</replaceable></optional>
|
||||
<optional><replaceable>kernelname</replaceable></optional></entry>
|
||||
<entry>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
|
||||
<command>unload</command> has been issued.
|
||||
<entry>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 <command>unload</command> has been issued.
|
||||
Otherwise, the previously-loaded kernel will be
|
||||
used.</entry>
|
||||
</row>
|
||||
|
|
@ -370,8 +370,9 @@ boot:</screen>
|
|||
<row>
|
||||
<entry>include <replaceable>filename</replaceable>
|
||||
…</entry>
|
||||
<entry>Reads the specified file and interprets it line by line. An
|
||||
error immediately stops the <command>include</command>.</entry>
|
||||
<entry>Reads the specified file and interprets it line
|
||||
by line. An error immediately stops the
|
||||
<command>include</command>.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
|
@ -394,24 +395,22 @@ boot:</screen>
|
|||
</row>
|
||||
|
||||
<row>
|
||||
<entry>lsdev
|
||||
<optional>-v</optional></entry>
|
||||
<entry>lsdev <optional>-v</optional></entry>
|
||||
<entry>Lists all of the devices from which it may be
|
||||
possible to load modules. If <option>-v</option> is
|
||||
specified, more details are printed.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>lsmod
|
||||
<optional>-v</optional></entry>
|
||||
<entry>lsmod <optional>-v</optional></entry>
|
||||
<entry>Displays loaded modules. If <option>-v</option>
|
||||
is specified, more details are shown.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>more <replaceable>filename</replaceable></entry>
|
||||
<entry>Displays the files specified, with a pause at each
|
||||
<varname>LINES</varname> displayed.</entry>
|
||||
<entry>Displays the files specified, with a pause at
|
||||
each <varname>LINES</varname> displayed.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
|
@ -433,36 +432,33 @@ boot:</screen>
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>Here are some practical examples of
|
||||
loader usage. To boot the usual kernel in single-user
|
||||
mode<indexterm><primary>single-user
|
||||
<para>Here are some practical examples of loader usage. To boot
|
||||
the usual kernel in single-user mode
|
||||
<indexterm><primary>single-user
|
||||
mode</primary></indexterm>:</para>
|
||||
|
||||
<screen><userinput>boot -s</userinput></screen>
|
||||
|
||||
<para>To unload the usual kernel and modules and then
|
||||
load the previous or another, specified kernel:</para>
|
||||
<para>To unload the usual kernel and modules and then load the
|
||||
previous or another, specified kernel:</para>
|
||||
|
||||
<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><indexterm>
|
||||
<primary><filename>kernel.old</filename></primary></indexterm>
|
||||
to refer to the previously installed kernel before a
|
||||
system upgrade or before configuring a custom
|
||||
kernel.</para>
|
||||
<para>Use <filename>kernel.GENERIC</filename> to refer to the
|
||||
default kernel that comes with an installation, or
|
||||
<filename>kernel.old</filename><indexterm><primary><filename>kernel.old</filename></primary></indexterm>
|
||||
to refer to the previously installed kernel before a system
|
||||
upgrade or before configuring a custom kernel.</para>
|
||||
|
||||
<para>Use the following to load the usual modules with
|
||||
another kernel:</para>
|
||||
<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>
|
||||
|
||||
<para>To load an automated kernel configuration
|
||||
script:</para>
|
||||
<para>To load an automated kernel configuration script:</para>
|
||||
|
||||
<screen><userinput>load -t userconfig_script <replaceable>/boot/kernel.conf</replaceable></userinput></screen>
|
||||
|
||||
|
|
@ -478,13 +474,15 @@ boot:</screen>
|
|||
<indexterm>
|
||||
<primary>&man.init.8;</primary>
|
||||
</indexterm>
|
||||
<para>Once the kernel is loaded by either <application>loader</application> or
|
||||
by <application>boot2</application>, which bypasses
|
||||
<application>loader</application>, it examines any boot
|
||||
flags and adjusts its behavior as necessary. <xref
|
||||
|
||||
<para>Once the kernel is loaded by either
|
||||
<application>loader</application> or by
|
||||
<application>boot2</application>, which bypasses
|
||||
<application>loader</application>, it examines any boot flags
|
||||
and adjusts its behavior as necessary. <xref
|
||||
linkend="boot-kernel"/> lists the commonly used boot flags.
|
||||
Refer to &man.boot.8; for more information on the other
|
||||
boot flags.</para>
|
||||
Refer to &man.boot.8; for more information on the other boot
|
||||
flags.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel</primary>
|
||||
|
|
@ -511,7 +509,8 @@ boot:</screen>
|
|||
|
||||
<row>
|
||||
<entry><option>-C</option></entry>
|
||||
<entry>Boot the root file system from a <acronym>CDROM</acronym>.</entry>
|
||||
<entry>Boot the root file system from a
|
||||
<acronym>CDROM</acronym>.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
|
@ -534,13 +533,14 @@ boot:</screen>
|
|||
<command>loader</command>. This is the last stage of the boot
|
||||
process.</para>
|
||||
|
||||
<para>The boot sequence makes sure that the file systems available
|
||||
on the system are consistent. If a <acronym>UFS</acronym> file
|
||||
system is not, and <command>fsck</command>
|
||||
cannot fix the inconsistencies,
|
||||
<application>init</application> drops the system into single-user mode so that the
|
||||
system administrator can resolve the problem directly. Otherwise,
|
||||
the system boots into multi-user mode.</para>
|
||||
<para>The boot sequence makes sure that the file systems
|
||||
available on the system are consistent. If a
|
||||
<acronym>UFS</acronym> file system is not, and
|
||||
<command>fsck</command> cannot fix the inconsistencies,
|
||||
<application>init</application> drops the system into
|
||||
single-user mode so that the system administrator can resolve
|
||||
the problem directly. Otherwise, the system boots into
|
||||
multi-user mode.</para>
|
||||
|
||||
<sect3 xml:id="boot-singleuser">
|
||||
<title>Single-User Mode</title>
|
||||
|
|
@ -548,12 +548,12 @@ boot:</screen>
|
|||
<indexterm><primary>single-user mode</primary></indexterm>
|
||||
<indexterm><primary>console</primary></indexterm>
|
||||
|
||||
<para>A user can specify this mode by
|
||||
booting with <option>-s</option>, or by
|
||||
setting the <envar>boot_ single</envar> variable in
|
||||
<application>loader</application>. It can also be reached by
|
||||
running <command>shutdown now</command> from
|
||||
multi-user mode. Single-user mode begins with this message:</para>
|
||||
<para>A user can specify this mode by booting with
|
||||
<option>-s</option>, or by setting the <envar>boot
|
||||
_ single</envar> variable in
|
||||
<application>loader</application>. It can also be reached
|
||||
by running <command>shutdown now</command> from multi-user
|
||||
mode. Single-user mode begins with this message:</para>
|
||||
|
||||
<programlisting>Enter full pathname of shell or RETURN for /bin/sh:</programlisting>
|
||||
|
||||
|
|
@ -561,28 +561,29 @@ boot:</screen>
|
|||
will enter the default Bourne shell. To specify a different
|
||||
shell, input the full path to the shell.</para>
|
||||
|
||||
<para>Single-user mode is usually used to repair a system that will not
|
||||
boot due to an inconsistent file system or an error in a boot
|
||||
configuration file. It can also be used to reset the
|
||||
<systemitem class="username">root</systemitem> password when
|
||||
it is unknown. These actions are possible as the single-user
|
||||
mode prompt gives full, local access to the system and its
|
||||
configuration files. There is no networking in this mode.</para>
|
||||
<para>Single-user mode is usually used to repair a system that
|
||||
will not boot due to an inconsistent file system or an error
|
||||
in a boot configuration file. It can also be used to reset
|
||||
the <systemitem class="username">root</systemitem> password
|
||||
when it is unknown. These actions are possible as the
|
||||
single-user mode prompt gives full, local access to the
|
||||
system and its configuration files. There is no networking
|
||||
in this mode.</para>
|
||||
|
||||
<para>While single-user mode is useful for repairing a system,
|
||||
it poses a security risk unless the system is in a physically
|
||||
secure location. By default, any user who can gain physical
|
||||
access to a system will have full control of that system after
|
||||
booting into single-user mode.</para>
|
||||
it poses a security risk unless the system is in a
|
||||
physically secure location. By default, any user who can
|
||||
gain physical access to a system will have full control of
|
||||
that system after booting into single-user mode.</para>
|
||||
|
||||
<para>If the system <literal>console</literal> is changed to
|
||||
<literal>insecure</literal> in <filename>/etc/ttys</filename>,
|
||||
the system will first prompt for the <systemitem
|
||||
class="username">root</systemitem> password before
|
||||
initiating single-user mode. This adds a measure of security
|
||||
while removing the ability to reset the <systemitem
|
||||
class="username">root</systemitem> password when it is
|
||||
unknown.</para>
|
||||
<literal>insecure</literal> in
|
||||
<filename>/etc/ttys</filename>, the system will first prompt
|
||||
for the <systemitem class="username">root</systemitem>
|
||||
password before initiating single-user mode. This adds a
|
||||
measure of security while removing the ability to reset the
|
||||
<systemitem class="username">root</systemitem> password when
|
||||
it is unknown.</para>
|
||||
|
||||
<example xml:id="boot-insecure-console">
|
||||
<title>Configuring an Insecure Console in
|
||||
|
|
@ -607,20 +608,20 @@ console none unknown off <replaceable>insecure</repla
|
|||
|
||||
<indexterm><primary>multi-user mode</primary></indexterm>
|
||||
|
||||
<para>If <application>init</application> finds the file systems to be in order, or
|
||||
once the user has finished their commands in single-user mode
|
||||
and has typed <command>exit</command> to leave single-user mode,
|
||||
the system enters
|
||||
multi-user mode, in which it starts the resource configuration
|
||||
of the system.</para>
|
||||
<para>If <application>init</application> finds the file
|
||||
systems to be in order, or once the user has finished their
|
||||
commands in single-user mode and has typed
|
||||
<command>exit</command> to leave single-user mode, the
|
||||
system enters multi-user mode, in which it starts the
|
||||
resource configuration of the system.</para>
|
||||
|
||||
<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>. It then proceeds to mount
|
||||
the system file systems listed in
|
||||
<filename>/etc/rc.conf</filename>. It 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>
|
||||
|
|
@ -653,73 +654,69 @@ console none unknown off <replaceable>insecure</repla
|
|||
</authorgroup>
|
||||
</info>
|
||||
|
||||
<para>Typically when a &os; system boots, it displays its
|
||||
progress as a series of messages at the console. A boot splash
|
||||
screen creates an alternate boot screen that
|
||||
hides all of the boot probe and service
|
||||
startup messages. A few boot loader messages, including the boot options
|
||||
menu and a timed wait countdown prompt, are displayed at
|
||||
boot time, even when the splash screen is enabled. The display of the splash screen
|
||||
can be turned off by hitting any
|
||||
key on the keyboard during the boot process.</para>
|
||||
<para>Typically when a &os; system boots, it displays its progress
|
||||
as a series of messages at the console. A boot splash screen
|
||||
creates an alternate boot screen that hides all of the boot
|
||||
probe and service startup messages. A few boot loader messages,
|
||||
including the boot options menu and a timed wait countdown
|
||||
prompt, are displayed at boot time, even when the splash screen
|
||||
is enabled. The display of the splash screen can be turned off
|
||||
by hitting any key on the keyboard during the boot
|
||||
process.</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 a configured
|
||||
graphical environment. Refer to <xref linkend="x11"/>
|
||||
for more information on how to install
|
||||
and configure a graphical display manager and a graphical
|
||||
login manager.</para>
|
||||
environment. After the system finishes booting, a console login
|
||||
prompt is presented. The second environment is a configured
|
||||
graphical environment. Refer to <xref linkend="x11"/> for more
|
||||
information on how to install and configure a graphical display
|
||||
manager and a graphical login manager.</para>
|
||||
|
||||
<para>Once the system has booted, the splash screen defaults to being a screen saver.
|
||||
After a time period of non-use, the splash screen
|
||||
will display 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
|
||||
<para>Once the system has booted, the splash screen defaults to
|
||||
being a screen saver. After a time period of non-use, the
|
||||
splash screen will display 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>
|
||||
consoles and has no effect on graphical display managers.</para>
|
||||
|
||||
<para>Sample splash screen files can be downloaded from the
|
||||
gallery at <link
|
||||
xlink:href="http://artwork.freebsdgr.org/node/3/">http://artwork.freebsdgr.org</link>.
|
||||
By installing the
|
||||
<package>sysutils/bsd-splash-changer</package> package or port, a random splash
|
||||
image from a collection will display at
|
||||
boot.</para>
|
||||
By installing the <package>sysutils/bsd-splash-changer</package>
|
||||
package or port, a random splash image from a collection will
|
||||
display at boot.</para>
|
||||
|
||||
<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 <filename>.bmp</filename>,
|
||||
<filename>.pcx</filename>, or <filename>.bin</filename> image
|
||||
has to be placed on the root partition, for example in
|
||||
<filename>/boot</filename>. The splash image
|
||||
files must have a resolution of 320 by 200 pixels or less in
|
||||
order to work on standard <acronym>VGA</acronym> adapters.
|
||||
For the default boot display resolution of 256-colors and
|
||||
320 by 200 pixels or less, add the following lines to
|
||||
<filename>/boot/loader.conf</filename>.
|
||||
Replace <replaceable>splash.bmp</replaceable> with the name of
|
||||
the bitmap file to use:</para>
|
||||
TheDraw (<filename>.bin</filename>) formats. The
|
||||
<filename>.bmp</filename>, <filename>.pcx</filename>, or
|
||||
<filename>.bin</filename> image has to be placed on the root
|
||||
partition, for example in <filename>/boot</filename>. The
|
||||
splash image files must have a resolution of 320 by 200 pixels
|
||||
or less in order to work on standard <acronym>VGA</acronym>
|
||||
adapters. For the default boot display resolution of 256-colors
|
||||
and 320 by 200 pixels or less, add the following lines to
|
||||
<filename>/boot/loader.conf</filename>. Replace
|
||||
<replaceable>splash.bmp</replaceable> with the name of the
|
||||
bitmap file to use:</para>
|
||||
|
||||
<programlisting>splash_bmp_load="YES"
|
||||
bitmap_load="YES"
|
||||
bitmap_name="/boot/<replaceable>splash.bmp</replaceable>"</programlisting>
|
||||
|
||||
<para>To use a
|
||||
<acronym>PCX</acronym> file instead of a bitmap file:</para>
|
||||
<para>To use a <acronym>PCX</acronym> file instead of a bitmap
|
||||
file:</para>
|
||||
|
||||
<programlisting>splash_pcx_load="YES"
|
||||
bitmap_load="YES"
|
||||
bitmap_name="/boot/<replaceable>splash.pcx</replaceable>"</programlisting>
|
||||
|
||||
<para>To instead use
|
||||
ASCII art in the <link
|
||||
<para>To instead use ASCII art in the <link
|
||||
xlink:href="https://en.wikipedia.org/wiki/TheDraw">https://en.wikipedia.org/wiki/TheDraw</link>
|
||||
format:</para>
|
||||
|
||||
|
|
@ -727,15 +724,15 @@ bitmap_name="/boot/<replaceable>splash.pcx</replaceable>"</programlisting>
|
|||
bitmap_load="YES"
|
||||
bitmap_name="/boot/<replaceable>splash.bin</replaceable>"</programlisting>
|
||||
|
||||
<para>To use larger images that fill the whole display
|
||||
screen, up to the maximum resolution of
|
||||
1024 by 768 pixels, the <acronym>VESA</acronym> module
|
||||
must also be loaded during system boot. If using a custom kernel, ensure
|
||||
that the custom kernel configuration file includes the
|
||||
<literal>VESA</literal> kernel configuration option. To load
|
||||
the <acronym>VESA</acronym> module for the splash screen, add
|
||||
this line to <filename>/boot/loader.conf</filename> before the
|
||||
three lines mentioned in the above examples:</para>
|
||||
<para>To use larger images that fill the whole display screen, up
|
||||
to the maximum resolution of 1024 by 768 pixels, the
|
||||
<acronym>VESA</acronym> module must also be loaded during system
|
||||
boot. If using a custom kernel, ensure that the custom kernel
|
||||
configuration file includes the <literal>VESA</literal> kernel
|
||||
configuration option. To load the <acronym>VESA</acronym>
|
||||
module for the splash screen, add this line to
|
||||
<filename>/boot/loader.conf</filename> before the three lines
|
||||
mentioned in the above examples:</para>
|
||||
|
||||
<programlisting>vesa_load="YES"</programlisting>
|
||||
|
||||
|
|
@ -747,16 +744,15 @@ bitmap_name="/boot/<replaceable>splash.bin</replaceable>"</programlisting>
|
|||
|
||||
<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>
|
||||
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>
|
||||
<varlistentry><term><literal>loader_logo="beastie"</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>This will replace the default words
|
||||
|
|
|
|||
Loading…
Reference in a new issue