linux-from-scratch/glfs
1
0
Fork 0
mirror of https://github.com/Zeckmathederg/glfs.git synced 2025-01-24 23:32:12 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Editorial changes to new evi pages.

Browse Source 
git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@24395 af4574ff-66df-0310-9fd7-8a98e5e911e0
This commit is contained in:
Bruce Dubbs 2021-03-23 19:24:51 +00:00
parent a2c3f1d361
commit d5cc78ad74
4 changed files with 56 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
postlfs/filesystems/uefi-bootloaders/efibootmgr.xml
View File

@ -117,16 +117,16 @@
<para>
<parameter>EFIDIR=LFS</parameter>:
This option specify the distro's subdirectory name under
This option specifies the distro's subdirectory name under
<filename class="directory">/boot/efi/EFI</filename>.
The building system of this package needs it to be set explicitly.
</para>
<para>
<parameter>EFI_LOADER=grubx64.efi</parameter>:
This option specify the name of the default EFI boot loader. It is
set to match the EFI boot loader provided by
GRUB<!--xref linkend="grub-efi"/-->.
This option specifies the name of the default EFI boot loader. It is
set to match the EFI boot loader provided by GRUB
<!--xref linkend="grub-efi"/-->.
</para>
<para>
@ -155,7 +155,7 @@
<?dbhtml list-presentation="table"?>
<varlistentry id="efibootdump">
<term><command>efibootmgr</command></term>
<term><command>efibootdump</command></term>
<listitem>
<para>
is a tool to display individual UEFI boot options, from a file

9
postlfs/filesystems/uefi-bootloaders/efivar.xml
View File

@ -89,15 +89,13 @@
<title>Installation of efivar</title>
<para>
At first, apply a patch to fix an issue breaking the build with GCC 9
or later:
First, apply a patch to fix an issue building with GCC 9 or later:
</para>
<screen><userinput>patch -Np1 -i ../efivar-37-gcc_9-1.patch</userinput></screen>
<para>
Build <application>efivar</application> with the following
commands:
Build <application>efivar</application> with the following commands:
</para>
<screen><userinput>make CFLAGS="-O2 -Wno-stringop-truncation"</userinput></screen>
@ -131,8 +129,7 @@ ln -sfv ../../lib/$(readlink /usr/lib/libefivar.so) /usr/lib/libefivar.so
<para>
<parameter>CFLAGS="-O2 -Wno-stringop-truncation"</parameter>:
This option overrides the compiler flags defaulted by this package,
to avoid build failure.
This option overrides the default compiler flags to avoid a build failure.
</para>
<para>

25
postlfs/filesystems/uefi-bootloaders/grub-efi.xml
View File

@ -122,7 +122,7 @@
<title>Installation of GRUB</title>
<para>
At first, install font data as the
First, install font data as the
<systemitem class="username">root</systemitem> user:
</para>
@ -151,11 +151,10 @@ gunzip -c unifont-&unifont-version;.pcf.gz > /usr/share/fonts/unifont/unifont.pc
--enable-grub-mkfont \
--with-platform=efi \
--disable-werror &amp;&amp;
make</userinput></screen>
<para>
This package does not have a test suite providing meaningful result.
This package does not have a test suite providing meaningful results.
</para>
<para>
@ -171,27 +170,27 @@ mv -v /etc/bash_completion.d/grub /usr/share/bash-completion/completions</userin
<title>Command Explanations</title>
<para>
<parameter>--enable-grub-mkfont</parameter>: Built the tool named
<command>grub-mkfont</command> to generate font file for the boot
loader, from the font data we've installed.
<parameter>--enable-grub-mkfont</parameter>: Build the tool named
<command>grub-mkfont</command> to generate the font file for the boot
loader from the font data we've installed.
</para>
<warning>
<para>If the recommended dependency <xref linkend="freetype2"/> is not
installed, it's possible to omit this option and build GRUB. However,
installed, it is possible to omit this option and build GRUB. However,
if <command>grub-mkfont</command> is not built, or the unicode font
data is not avaliable at the time GRUB is built, GRUB won't install
any font for the boot loader. The GRUB boot menu will be displayed
in an ugly way, and the early stage of kernel initialization will be
in <quote>blind mode</quote> - you can't see any kernel message before
using a coarse font and the early stage of kernel initialization will be
in <quote>blind mode</quote> &mdash; you can't see any kernel messages before
the graphics card driver is initialized. It will be very difficult to
diagnostic some boot issue (especially, if the graphics driver is
built as module).</para>
diagnose some boot issues, especially if the graphics driver is
built as module.</para>
</warning>
<para>
<parameter>--with-platform=efi</parameter>: Ensures to build GRUB with
for EFI.
<parameter>--with-platform=efi</parameter>: Ensures building GRUB with
EFI enabled.
</para>
</sect2>

72
postlfs/filesystems/uefi-bootloaders/grub-setup.xml
View File

@ -19,7 +19,7 @@
<title>Turn Off Secure Boot</title>
<para>
BLFS doesn't have the essential packages to support Secure Boot. To
BLFS does not have the essential packages to support Secure Boot. To
set up the boot process with GRUB for UEFI installed in BLFS, Secure
Boot must be turned off from the configuration interface of the
firmware. Read the documentation provided by the manufacturer of your
@ -32,8 +32,8 @@
<para>
Ensure that an emergency boot disk is ready to <quote>rescue</quote>
the system, in case the system becomes un-bootable. To make a
emergency boot disk with GRUB for EFI platform, at first find a spare
the system in case the system becomes un-bootable. To make an
emergency boot disk with GRUB for an EFI based system, find a spare
USB flash drive and create a
<systemitem class="filesystem">vfat</systemitem> file system on it.
Install <xref linkend="dosfstools"/> first, then
@ -54,7 +54,7 @@
<para>
Still as the <systemitem class="username">root</systemitem> user, use
the CLI of <command>fdisk</command> utility to set the first parition
the <command>fdisk</command> utility to set the first parition
of the USB flash drive to be an <quote>EFI system</quote> partition
(change <userinput>sdx</userinput> to the device node corresponding
to your USB flash drive):
@ -100,9 +100,9 @@ mount -v -t vfat /dev/sdx1 /mnt/rescue</userinput></screen>
<para>
Now the USB flash drive can be used as a emergency boot disk on x86-64
UEFI platform. It will boot the system and show GRUB shell. Then you
can type commands to boot your operation systems on the hard drive.
To get how to select the boot device, read the manual of your
UEFI platform. It will boot the system and show the GRUB shell. Then you
can type commands to boot your operating systems on the hard drive.
To learn how to select the boot device, read the manual of your
motherboard or laptop.
</para>
@ -144,9 +144,9 @@ File systems ---&gt;
<varlistentry>
<term><parameter>CONFIG_EFI_STUB</parameter></term>
<listitem>
<para>Though EFI stub is designed to boot a kernel directly from
the UEFI firmware (without bootloaders like GRUB), GRUB needs the
kernel being loaded to support EFI handover protocol enabled by
<para>Although the EFI stub is designed to boot a kernel directly from
the UEFI firmware (without a bootloader like GRUB), GRUB needs the
kernel to be loaded to support the EFI handover protocol enabled by
this option.</para>
</listitem>
</varlistentry>
@ -154,7 +154,7 @@ File systems ---&gt;
<varlistentry>
<term><parameter>CONFIG_EFI_VARS</parameter></term>
<listitem>
<para>Don't use this option deprecated because of an 1024-byte
<para>Don't use this deprecated option because of a 1024-byte
variable size limit. Its function is replaced by
<parameter>CONFIG_EFIVAR_FS</parameter>.</para>
</listitem>
@ -164,8 +164,8 @@ File systems ---&gt;
<term><parameter>CONFIG_FB_EFI</parameter> and <parameter>CONFIG_FRAMEBUFFER_CONSOLE</parameter></term>
<listitem>
<para>The combination of these two options allows the kernel to
print debug messages (along with Tux logos) on early stage of boot
process with UEFI.</para>
print debug messages (along with Tux logos) at the early stage of boot
the process with UEFI.</para>
</listitem>
</varlistentry>
@ -178,13 +178,13 @@ File systems ---&gt;
<para>
On EFI based system, the bootloaders are installed in a special FAT32
partition called <emphasis>EFI System Partition</emphasis> (ESP).
partition called an <emphasis>EFI System Partition</emphasis> (ESP).
If your system supports EFI, and a recent version of Linux
distribution or Windows is pre-installed, it's likely that the ESP
is already created. As the
<systemitem class="username">root</systemitem> user, list all the
partitions on your hard drive (replace <userinput>sda</userinput>
with the device node corresponding to the hard drive):
with the device corresponding to the appropriate hard drive):
</para>
<screen role="nodump"><userinput>fdisk -l /dev/sda</userinput></screen>
@ -195,11 +195,11 @@ File systems ---&gt;
</para>
<para>
If the system or the hard drive is new, or it's the first time to
install an UEFI booted OS on the system, the ESP may be nonexistent.
Then create a new partition, make a
If the system or the hard drive is new, or it's a first time
install an UEFI booted OS on the system, the ESP may not exist.
In that case, create a new partition, make a
<systemitem class="filesystem">vfat</systemitem> file system on it,
and set the partition type to <quote>EFI system</quote>. Read the
and set the partition type to <quote>EFI system</quote>. See the
instructions for the emergency boot device above as a reference.
</para>
@ -221,7 +221,7 @@ File systems ---&gt;
mount -v -t vfat /dev/sda1 /boot/efi</userinput></screen>
<para>
It's recommended to add an entry for the ESP in
Add an entry for the ESP in
<filename>/etc/fstab</filename>, so it will be mounted automatically
during system boot:
</para>
@ -236,8 +236,8 @@ mount -v -t vfat /dev/sda1 /boot/efi</userinput></screen>
<title>Mount the EFI Variable File System</title>
<para>
The installation of GRUB on UEFI platform requires the EFI Variable
file system (<systemitem class="filesystem">efivarfs</systemitem>)
The installation of GRUB on a UEFI platform requires that the EFI Variable
file system, <systemitem class="filesystem">efivarfs</systemitem>, to be
mounted. As the <systemitem class="username">root</systemitem> user:
</para>
@ -247,15 +247,15 @@ mount -v -t vfat /dev/sda1 /boot/efi</userinput></screen>
<para>
If the system is booted with UEFI and systemd,
<systemitem class="filesystem">efivarfs</systemitem> will be mounted
automatically. However in LFS chroot environment it still needs to
automatically. However in the LFS chroot environment it still needs to
be mounted manually.
</para>
</note>
<para revision="sysv">
It's recommended to add an entry for the
Now add an entry for the
<systemitem class="filesystem">efivarfs</systemitem> in
<filename>/etc/fstab</filename>, so it will be mounted automatically
<filename>/etc/fstab</filename> so it will be mounted automatically
during system boot:
</para>
@ -278,20 +278,20 @@ mount -v -t vfat /dev/sda1 /boot/efi</userinput></screen>
<para>
On UEFI based systems, GRUB works by installing an EFI application
(a special kind of PE executable) into
(a special kind of executable) into
<filename class="directory">/boot/efi/EFI/[id]/grubx64.efi</filename>,
where <filename class="directory">/boot/efi</filename> is the mount
point of the ESP, and <literal>[id]</literal> is replaced with an
identifier specified in the <command>grub-install</command> command
line. Then GRUB will create an entry in the EFI variables containing
the path <literal>EFI/[id]/grubx64.efi</literal>, so the EFI firmware
line. GRUB will create an entry in the EFI variables containing
the path <literal>EFI/[id]/grubx64.efi</literal> so the EFI firmware
can find <filename>grubx64.efi</filename> and load it.
</para>
<para>
<filename>grubx64.efi</filename> is very lightweight (136 KB with
GRUB-2.06~rc1) so it won't cost much space in the ESP. A typical ESP
size is 100 MB (for Windows boot manager, which cost about 50 MB in
GRUB-2.06~rc1) so it will not use much space in the ESP. A typical ESP
size is 100 MB (for Windows boot manager, which uses about 50 MB in
the ESP). Once <filename>grubx64.efi</filename> loaded by the
firmware, it will load GRUB modules in the boot partition.
The default location is
@ -301,7 +301,7 @@ mount -v -t vfat /dev/sda1 /boot/efi</userinput></screen>
<para>
As the <systemitem class="username">root</systemitem> user, install
the GRUB files into <filename>/boot/efi/EFI/LFS/grubx64.efi</filename>
and <filename class="directory">/boot/grub</filename>, and set up the
and <filename class="directory">/boot/grub</filename>. Then set up the
boot entry in the EFI variables:
</para>
@ -330,10 +330,10 @@ Boot0004* UEFI:Network Device
Boot0005* LFS</literal></screen>
<para>
Note that <literal>0005</literal> is the first in
Note that <literal>0005</literal> is the first in the
<literal>BootOrder</literal>, and <literal>Boot0005</literal>
is <literal>LFS</literal>. So on the next boot, GRUB installed
by LFS will be used to boot the system.
is <literal>LFS</literal>. This means that on the next boot, the
version of GRUB installed by LFS will be used to boot the system.
</para>
</sect2>
@ -383,7 +383,7 @@ menuentry "Firmware Setup" {
<note>
<para>
From GRUB's perspective, the files are relative to the partition
used. If you used a separate /boot partition, remove /boot from the
are used. If you used a separate /boot partition, remove /boot from the
above paths (to kernel and to <filename>unicode.pf2</filename>). You
will also need to change the set root line to point to the boot
partition.
@ -417,7 +417,7 @@ menuentry "Windows 10" {
<para>
<literal>(hd0,1)</literal> should be replaced with the GRUB
designated name for the ESP. <literal>chainloader</literal>
designated name for the ESP. The <literal>chainloader</literal>
directive can be used to tell GRUB to run another EFI executable,
in this case the Windows Boot Manager. You may put more usable tools
in EFI executable format (for example, an EFI shell) into the ESP and