commit b2c7b0bd1d378c7152d9ef28b6a34a1fb03c0e34
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 25 09:44:10 2015 +0100
Grub2, apply reviewers feedback
en-US/Working_with_the_GRUB_2_Boot_Loader.xml | 49 +++++++++++++++----------
1 files changed, 29 insertions(+), 20 deletions(-)
---
diff --git a/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
b/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
index f6454b8..30d7ed4 100644
--- a/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
+++ b/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
@@ -67,7 +67,7 @@ menuentry 'Fedora, with Linux 3.17.4-301.fc21.x86_64' --class
fedora --class gnu
</programlisting>
<para>
- Each <literal>menuentry</literal> block that represents an installed
Linux kernel contains <literal>linux</literal> on 64-bit IBM POWER Series,
<literal>linux16</literal> on x86_64 BIOS-based systems, and
<literal>linuxefi</literal> on UEFI-based systems. Then the
<literal>initrd</literal> directives followed by the path to the kernel and
the <systemitem>initramfs</systemitem> image respectively. If a separate
<filename>/boot</filename> partition was created, the paths to the kernel and
the <systemitem>initramfs</systemitem> image are relative to
<filename>/boot</filename>. In the example above, the <literal>initrd
/initramfs-3.8.0-0.40.el7.x86_64.img</literal> line means that the
<systemitem>initramfs</systemitem> image is actually located at
<filename>/boot/initramfs-3.8.0-0.40.el7.x86_64.img</filename> when the root
file system is mounted, and likewise for the kernel path.
+ Each <literal>menuentry</literal> block that represents an installed
Linux kernel contains <literal>linux</literal> on 64-bit IBM POWER Series,
<literal>linux16</literal> on x86_64 BIOS-based systems, and
<literal>linuxefi</literal> on UEFI-based systems. Then the
<literal>initrd</literal> directives followed by the path to the kernel and
the <systemitem>initramfs</systemitem> image respectively. If a separate
<filename>/boot</filename> partition was created, the paths to the kernel and
the <systemitem>initramfs</systemitem> image are relative to
<filename>/boot</filename>. In the example above, the <literal>initrd
/initramfs-3.8.0-0.40.el7.x86_64.img</literal> line means that the
<systemitem>initramfs</systemitem> image is actually located at
<filename>/boot/initramfs-3.8.0-0.40.el7.x86_64.img</filename> when the
<systemitem class="username">root</systemitem> file system is
mounted, and likewise for the kernel path.
</para>
<para>
The kernel version number as given on the <literal>linux16
/vmlinuz-kernel_version</literal> line must match the version number of the
<systemitem>initramfs</systemitem> image given on the <literal>initrd
/initramfs-kernel_version.img</literal> line of each
<literal>menuentry</literal> block. For more information on how to verify the
initial RAM disk image, see <xref
@@ -104,7 +104,7 @@ menuentry 'Fedora, with Linux 3.17.4-301.fc21.x86_64' --class
fedora --class gnu
</listitem>
<listitem>
<para>
- <filename>01_users</filename>, which is created only when a boot
loader password is assigned in <application>kickstart</application>.
+ <filename>01_users</filename>, which is created only when a boot
loader password is assigned in a <application>kickstart</application> file.
</para>
</listitem>
<listitem>
@@ -152,7 +152,7 @@ The <literal>DEFAULTKERNEL</literal> directive specifies
what package type will
</para>
<screen>~]# <command>grub2-set-default</command>
<literal>2</literal></screen>
<para>
- Note that the position of a menu entry in the list is denoted by a number
starting with zero; therefore, in the example above, the third entry will be loaded. This
value will be over-written by the name of the next kernel to be installed.
+ Note that the position of a menu entry in the list is denoted by a number
starting with zero; therefore, in the example above, the third entry will be loaded. This
value will be overwritten by the name of the next kernel to be installed.
</para>
<para>
To force a system to always use a particular menu entry, use the menu
entry name as the key to the <literal>GRUB_DEFAULT</literal> directive in the
<filename>/etc/default/grub</filename> file. To list the available menu
entries, run the following command as <systemitem
class="username">root</systemitem>:
@@ -352,6 +352,13 @@ menuentry 'Second custom entry' --class red --class gnu-linux
--class gnu --clas
<title>GRUB 2 Password Protection</title>
<para>
GRUB 2 supports both plain-text and encrypted passwords in the GRUB 2 template files.
To enable the use of passwords, specify a superuser who can reach the protected entries.
Other users can be specified to access these entries as well. Menu entries can be
password-protected for booting by adding one or more users to the menu entry as described
in <xref
linkend="sec-Setting_Up_Users_and_Password_Protection_Specifying_Menu_Entries"
/>. To use encrypted passwords, see <xref
linkend="sec-Password_Encryption" />.</para>
+
+ <warning>
+ <para>
+ If you do not use the correct format for the menu, or modify the configuration in an
incorrect way, you might be unable to boot your system.
+ </para>
+ </warning>
+
<para>
All menu entries can be password-protected against changes by setting superusers,
which can be done in the <filename>/etc/grub.d/00_header</filename> or the
<filename>/etc/grub.d/01_users</filename> file. The
<filename>00_header</filename> file is very complicated and, if possible,
avoid making modifications in this file. Menu entries should be placed in the
<filename>/etc/grub.d/40_custom</filename> and users in the
<filename>/etc/grub.d/01_users</filename> file. The
<filename>01_users</filename> file is generated by the installation
application <application>anaconda</application> when a grub boot loader
password is used in a <application>kickstart</application> template (but it
should be created and used it if it does not exist). Examples in this section adopt this
policy.
</para>
@@ -486,18 +493,14 @@ password_pbkdf2 john
grub.pbkdf2.sha512.10000.19074739ED80F115963D984BDCB35AA671
</para>
</step>
</procedure>
- <warning>
- <para>
- If you do not use the correct format, or modify the configuration in an incorrect
way, you might be unable to boot your system.
- </para>
- </warning>
+
</section>
</section>
<section id="sec-Reinstalling_GRUB_2">
<title>Reinstalling GRUB 2</title>
<para>
- Reinstalling GRUB 2 might be a useful and easier way to fix certain problems usually
caused by an incorrect installation of GRUB 2, missing files, or a broken system. Other
reasons to reinstall GRUB 2 include the following:
+ Reinstalling GRUB 2 is a convenient way to fix certain problems usually caused by an
incorrect installation of GRUB 2, missing files, or a broken system. Other reasons to
reinstall GRUB 2 include the following:
</para>
<itemizedlist>
<listitem>
@@ -535,7 +538,7 @@ password_pbkdf2 john
grub.pbkdf2.sha512.10000.19074739ED80F115963D984BDCB35AA671
<section id="sec-Resetting_and_Reinstalling_GRUB_2">
<title>Resetting and Reinstalling GRUB 2</title>
<para>
- This method completely removes all GRUB 2 configuration files and system settings, and
is therefore used when the user wants to reset all configuration setting to the default
values. Removing of the configuration files and subsequent reinstalling of GRUB 2 fixes
failures caused by corrupted files and incorrect configuration. To do so, as
<systemitem class="username">root</systemitem>, follow these steps:
+ This method completely removes all GRUB 2 configuration files and system settings.
Apply this method to reset all configuration settings to their default values. Removing of
the configuration files and subsequent reinstalling of GRUB 2 fixes failures caused by
corrupted files and incorrect configuration. To do so, as <systemitem
class="username">root</systemitem>, follow these steps:
</para>
<procedure>
@@ -551,7 +554,8 @@ password_pbkdf2 john
grub.pbkdf2.sha512.10000.19074739ED80F115963D984BDCB35AA671
</step>
<step>
<para>
- Run the <command>yum reinstall grub2-tools</command> command;
+ For EFI systems <emphasis role="bold">only</emphasis>,
run the following command:
+ <screen>~]# <command>yum reinstall grub2-efi
shim</command></screen>
</para>
</step>
<step>
@@ -615,9 +619,9 @@ GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8
--parity=no --stop=1"
</listitem>
</itemizedlist>
<note><para>
- This section explains configuring the grub terminal for access over a serial
connection but an additional option must be added to the kernel definition to make that
kernel monitor a serial connection. For example:
- <synopsis>console=ttyS0,9600n8</synopsis>
-Where <option>console=ttyS0</option> is the serial terminal to be used,
<option>9600</option> is the baud rate, <option>n</option> is for
no party, and <option>8</option> is the word length in bits.
+ In order to access the grub terminal over a serial connection an additional
option must be added to a kernel definition to make that particular kernel monitor a
serial connection. For example:
+
<synopsis>console=<replaceable>ttyS0,9600n8</replaceable></synopsis>
+Where <option>console=ttyS0</option> is the serial terminal to be used,
<option>9600</option> is the baud rate, <option>n</option> is for
no parity, and <option>8</option> is the word length in bits.
For more information on adding kernel options, see <xref
linkend="sec-Editing_an_Entry" />. For more information on serial console
settings, see <ulink
url="https://www.kernel.org/doc/Documentation/serial-console.txt&quo...
</para>
</note>
@@ -657,7 +661,7 @@ For more information on adding kernel options, see <xref
linkend="sec-Editing_an
<section id="sec-Booting_to_Rescue_Mode">
<title>Booting to Rescue Mode</title>
<para>
- Rescue mode provides a convenient single-user environment and allows you to repair
your system in situations when it is unable to complete a regular booting process. In
rescue mode, the system attempts to mount all local file systems and start some important
system services, but it does not activate network interfaces or allow more users to be
logged into the system at the same time. In Fedora, rescue mode is equivalent to single
user mode and requires the root password.
+ Rescue mode provides a convenient single-user environment and allows you to repair
your system in situations when it is unable to complete a normal booting process. In
rescue mode, the system attempts to mount all local file systems and start some important
system services, but it does not activate network interfaces or allow more users to be
logged into the system at the same time. In Fedora, rescue mode is equivalent to single
user mode and requires the <systemitem
class="username">root</systemitem> password.
</para>
<procedure>
<step>
@@ -688,7 +692,7 @@ For more information on adding kernel options, see <xref
linkend="sec-Editing_an
<section id="sec-Booting_to_Emergency_Mode">
<title>Booting to Emergency Mode</title>
<para>
- Emergency mode provides the most minimal environment possible and allows you to
repair your system even in situations when the system is unable to enter rescue mode. In
emergency mode, the system mounts the root file system only for reading, does not attempt
to mount any other local file systems, does not activate network interfaces, and only
starts few essential services. In Fedora, emergency mode requires the root password.
+ Emergency mode provides the most minimal environment possible and allows you to
repair your system even in situations when the system is unable to enter rescue mode. In
emergency mode, the system mounts the <systemitem
class="username">root</systemitem> file system only for reading, does
not attempt to mount any other local file systems, does not activate network interfaces,
and only starts few essential services. In Fedora, emergency mode requires the root
password.
</para>
<procedure>
<step>
@@ -726,7 +730,7 @@ For more information on adding kernel options, see <xref
linkend="sec-Editing_an
Note that in GRUB 2, resetting the password is no longer performed in single-user mode
as it was in GRUB included in Fedora 15 and Red Hat
Enterprise Linux 6. The <systemitem
class="username">root</systemitem> password is now required to operate
in <literal>single-user</literal> mode as well as in
<literal>emergency</literal> mode.
</para>
<para>
- Two procedures for changing the <systemitem
class="username">root</systemitem> password are shown here. The
<xref linkend="proc-Resetting_the_Root_Password_Using_bin_sh" /> procedure
creates a chrooted shell using <command>init=/bin/sh</command>. It is the
shorter of the two procedures and does not require an SELinux relabel. But this procedure
will not work if you have a USB keyboard, encrypted file systems, and does not work in
certain virtual machines or systems. The <xref
linkend="proc-Resetting_the_Root_Password_Using_rd.break" /> procedure makes
use of <command>rd.break</command> to interrupt the boot process before
control is passed from <systemitem>initramfs</systemitem> to <systemitem
class="service">systemd</systemitem>. The disadvantage of this method
is that you have to then change <systemitem
class="username">root</systemitem> using the
<command>sysroot</command> command.</para>
+ Two procedures for changing the <systemitem
class="username">root</systemitem> password are shown here. The
<xref linkend="proc-Resetting_the_Root_Password_Using_bin_sh" /> procedure
creates a shell, in a changed root environment, using
<command>init=/bin/sh</command>. It is the shorter of the two procedures and
does not require an SELinux relabel, which can be time consuming. But this procedure will
not work if you have a USB keyboard, encrypted file systems, and does not work in certain
virtual machines or systems. The <xref
linkend="proc-Resetting_the_Root_Password_Using_rd.break" /> procedure makes
use of <command>rd.break</command> to interrupt the boot process before
control is passed from <systemitem>initramfs</systemitem> to <systemitem
class="service">systemd</systemitem>. The disadvantage of this method
is that you have to then change <systemitem
class="username">root</systemitem> using the
<command>sysroot</command> command.</para>
<procedure id="proc-Resetting_the_Root_Password_Using_bin_sh">
<title>Resetting the Root Password Using /bin/sh</title>
<step>
@@ -903,11 +907,16 @@ Updating the password file results in a file with the incorrect
SELinux security
<step>
<para>
- Enter the <command>exit</command> command again to resume the
initialization and finish the system boot. Note that the SELinux relabeling process can
take a long time and a system reboot will occur when complete.
+ Enter the <command>exit</command> command again to resume the
initialization and finish the system boot.
</para>
<para>
- With an encrypted system file system, a pass word or phrase is required at this
point. However the password prompt might not appear as it is obscured by logging messages.
You can press and hold the <keycap>Backspace</keycap> key to see the prompt.
Release the key and enter the password for the encrypted file system, while ignoring the
logging messages.
+ With an encrypted file system, a pass word or phrase is required at this point.
However the password prompt might not appear as it is obscured by logging messages. You
can press and hold the <keycap>Backspace</keycap> key to see the prompt.
Release the key and enter the password for the encrypted file system, while ignoring the
logging messages.
+ </para>
+ <note>
+ <para>
+ Note that the SELinux relabeling process can take a long time. A system reboot
will occur automatically when the process is complete.
</para>
+ </note>
</step>
</procedure>
@@ -947,7 +956,7 @@ Updating the password file results in a file with the incorrect
SELinux security
</listitem>
</itemizedlist>
<para>
- UEFI Secure Boot does not prevent the installation or removal of second-stage boot
loaders, nor require explicit user confirmation of such changes. Signatures are verified
during booting, not when the boot loader is installed or updated. Therefore, UEFI Secure
Boot does not stop boot path manipulations. It only prevents the system from executing a
modified boot path once such a modification has occurred, and simplifies their detection.
+ UEFI Secure Boot does not prevent the installation or removal of second-stage boot
loaders, nor require explicit user confirmation of such changes. Signatures are verified
during booting, not when the boot loader is installed or updated. Therefore, UEFI Secure
Boot does not stop boot path manipulations, it simplifies the detection of changes and
prevents the system from executing a modified boot path once such a modification has
occurred.
</para>
<section id="sec-UEFI_Secure_Boot_Support_in_Fedora">