[system-administrators-guide/21] Grub2, apply reviewers feedback
stephenw
stephenw at fedoraproject.org
Sun Jan 25 08:55:01 UTC 2015
commit 45cc9a3d8fecbaa9afdbae2b2b730d7cd3801eca
Author: Stephen Wadeley <swadeley at 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"></ulink> </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">
More information about the docs-commits
mailing list