Wording and clarity improvements.
This commit is contained in:
parent
24e878d92a
commit
a0c3451706
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=45588
1 changed files with 15 additions and 17 deletions
|
@ -102,26 +102,25 @@
|
|||
of the <acronym>BIOS</acronym>.</para>
|
||||
|
||||
<note>
|
||||
<para>amd64 hardware is backward compatible as it understands
|
||||
<acronym>BIOS</acronym> instructions. Newer hardware uses
|
||||
a GUID Partition Table (<acronym>GPT</acronym>) instead of a
|
||||
<acronym>MBR</acronym>. &os; can boot from a
|
||||
<acronym>MBR</acronym> or <acronym>GPT</acronym> partition.
|
||||
When booting from <acronym>GPT</acronym>, &os; can boot from
|
||||
either a legacy <acronym>BIOS</acronym> or an Extensible
|
||||
Firmware Interface (<acronym>EFI</acronym>). Work is in
|
||||
progress to provide Unified Extensible Firmware Interface
|
||||
(<acronym>UEFI</acronym>) support.</para>
|
||||
<para>&os; provides for booting from both the older
|
||||
<acronym>MBR</acronym> standard, and the newer GUID Partition
|
||||
Table (<acronym>GPT</acronym>). <acronym>GPT</acronym>
|
||||
partitioning is often found on computers with the Unified
|
||||
Extensible Firmware Interface (<acronym>UEFI</acronym>).
|
||||
However, &os; can boot from <acronym>GPT</acronym> partitions
|
||||
even on machines with only a legacy <acronym>BIOS</acronym>
|
||||
with &man.gptboot.8;. Work is under way to provide direct
|
||||
<acronym>UEFI</acronym> booting.</para>
|
||||
</note>
|
||||
|
||||
<indexterm><primary>Master Boot Record
|
||||
<acronym>MBR</acronym>)</primary></indexterm>
|
||||
(<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
|
||||
<para>The code within the <acronym>MBR</acronym> is typically
|
||||
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
|
||||
|
@ -134,10 +133,10 @@
|
|||
<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
|
||||
the remainder of the operating system. When 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>
|
||||
to display a list of operating systems so the user
|
||||
can select 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
|
||||
|
@ -556,8 +555,7 @@ boot:</screen>
|
|||
<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
|
||||
<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>
|
||||
|
|
Loading…
Reference in a new issue