mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-06-18 19:29:21 +01:00
286 lines
14 KiB
XML
286 lines
14 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % general-entities SYSTEM "../general.ent">
|
|
%general-entities;
|
|
]>
|
|
|
|
<sect1 id="ch-bootable-grub" role="wrap">
|
|
<?dbhtml filename="grub.html"?>
|
|
|
|
<sect1info condition="script">
|
|
<productname>grub</productname>
|
|
<productnumber>&grub-version;</productnumber>
|
|
<address>&grub-url;</address>
|
|
</sect1info>
|
|
|
|
<title>Using GRUB to Set Up the Boot Process</title>
|
|
|
|
<note>
|
|
<para>
|
|
If your system has UEFI support and you wish to boot LFS with UEFI,
|
|
you should skip the instructions in this page but still learn the
|
|
syntax of <filename>grub.cfg</filename> and the method to specify
|
|
a partition in the file from this page, and configure GRUB with UEFI
|
|
support using the instructions provided in
|
|
<ulink url="&blfs-book;postlfs/grub-setup.html">the BLFS page</ulink>.
|
|
</para>
|
|
</note>
|
|
|
|
<sect2>
|
|
<title>Introduction</title>
|
|
|
|
<warning><para>Configuring GRUB incorrectly can render your system
|
|
inoperable without an alternate boot device such as a CD-ROM or bootable
|
|
USB drive. This section is not required to boot your LFS system. You may
|
|
just want to modify your current boot loader, e.g. Grub-Legacy, GRUB2, or
|
|
LILO.</para></warning>
|
|
|
|
<para> Ensure that an emergency boot disk is ready to <quote>rescue</quote>
|
|
the computer if the computer becomes unusable (un-bootable). If you do not
|
|
already have a boot device, you can create one. In order for the procedure
|
|
below to work, you need to jump ahead to BLFS and install
|
|
<userinput>xorriso</userinput> from the <ulink
|
|
url="&blfs-book;multimedia/libisoburn.html">
|
|
libisoburn</ulink> package.</para>
|
|
|
|
<screen role="nodump"><userinput>cd /tmp
|
|
grub-mkrescue --output=grub-img.iso
|
|
xorriso -as cdrecord -v dev=/dev/cdrw blank=as_needed grub-img.iso</userinput></screen>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>GRUB Naming Conventions</title>
|
|
|
|
<para>GRUB uses its own naming structure for drives and partitions in
|
|
the form of <emphasis>(hdn,m)</emphasis>, where <emphasis>n</emphasis>
|
|
is the hard drive number and <emphasis>m</emphasis> is the partition
|
|
number. The hard drive numbers start from zero, but the partition numbers
|
|
start from one for normal partitions (from five for extended partitions).
|
|
Note that this is different from earlier versions where
|
|
both numbers started from zero. For example, partition <filename
|
|
class="partition">sda1</filename> is <emphasis>(hd0,1)</emphasis> to
|
|
GRUB and <filename class="partition">sdb3</filename> is
|
|
<emphasis>(hd1,3)</emphasis>. In contrast to Linux, GRUB does not
|
|
consider CD-ROM drives to be hard drives. For example, if using a CD
|
|
on <filename class="partition">hdb</filename> and a second hard drive
|
|
on <filename class="partition">hdc</filename>, that second hard drive
|
|
would still be <emphasis>(hd1)</emphasis>.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Setting Up the Configuration</title>
|
|
|
|
<para>If booting the system via BIOS, GRUB works by writing a stub to
|
|
the first sector (named the Master Boot Record, or MBR) of the hard
|
|
disk. This area is not part of any file system. The BIOS loads and
|
|
execute the content of MBR, then the stub loads the main GRUB image from
|
|
the BIOS Boot Partition. The GRUB image is stored as raw data instead
|
|
of a file (there must be no file system on the BIOS Boot Partition), so
|
|
the stub don't need to support any file system and it can be made small
|
|
enough to fit in the MBR.</para>
|
|
|
|
<para>If booting the system via UEFI, GRUB works by storing the main
|
|
GRUB image as a PE-COFF executable file at a standard location in the
|
|
EFI System Partition. The EFI firmware loads the file at the standard
|
|
location and execute it.</para>
|
|
|
|
<para>Many GRUB functions (including booting a Linux kernel) are
|
|
not included in the main GRUB image. They are stored in some file
|
|
system as GRUB modules. This file system is usually mounted in a
|
|
way that the GRUB modules can be accessed at
|
|
<filename class='directory'>/boot/grub</filename> on most Linux
|
|
distros. To avoid the chicken-and-egg problem,
|
|
<command>grub-install</command> embeds the modules necessary to
|
|
access this file system into the main GRUB image, so it can find
|
|
and load other modules.</para>
|
|
|
|
<para>The location of the boot partition is a choice of the user that
|
|
affects the configuration. One recommendation is to have a separate small
|
|
(suggested size is 200 MB) partition just for boot information. That way
|
|
each build, whether LFS or some commercial distro, can access the same boot
|
|
files and access can be made from any booted system. If you choose to do
|
|
this, you will need to mount the separate partition, move all files in the
|
|
current <filename class="directory">/boot</filename> directory (e.g. the
|
|
Linux kernel you just built in the previous section) to the new partition.
|
|
You will then need to unmount the partition and remount it as <filename
|
|
class="directory">/boot</filename>. If you do this, be sure to update
|
|
<filename>/etc/fstab</filename>.</para>
|
|
|
|
<para>Leaving <filename class="directory">/boot</filename> on
|
|
the current LFS partition will also work, but configuration
|
|
for multiple systems is more difficult.</para>
|
|
|
|
<para>Using the above information, determine the appropriate
|
|
designator for the root partition (or boot partition, if a separate
|
|
one is used). For the following example, it is assumed that the root
|
|
(or separate boot) partition is <filename
|
|
class="partition">sda2</filename>.</para>
|
|
|
|
<para>For booting via BIOS, first make sure the boot partition is mounted
|
|
(if using a separate one), and the BIOS Boot partition exists.
|
|
Then install the GRUB files into <filename
|
|
class="directory">/boot/grub</filename> and set up the boot track:</para>
|
|
|
|
<warning>
|
|
<para>The following command will overwrite the current boot loader. Do not
|
|
run the command if this is not desired, for example, if using a third party
|
|
boot manager to manage the MBR.</para>
|
|
</warning>
|
|
|
|
<screen role="nodump"><userinput>grub-install /dev/sda --target=i386-pc</userinput></screen>
|
|
|
|
<para>For booting via UEFI, first make sure the boot partition is mounted
|
|
(if using a separate one) and the EFI System Partition is mounted at
|
|
<filename class='directory'>/boot/efi</filename>. Then install the GRUB
|
|
files into <filename class="directory">/boot/grub</filename> and the
|
|
main GRUB image into
|
|
<filename>/boot/efi/EFI/BOOT/BOOTX64.EFI</filename>:</para>
|
|
|
|
<warning>
|
|
<para>The following command will overwrite the
|
|
<filename>/boot/efi/EFI/BOOT/BOOTX64.EFI</filename> file.
|
|
If it already exists, it's likely the entry of another boot loader
|
|
(for example the GRUB installation from the host distro, or the
|
|
Windows Boot Manager). Backup the file so it can be restored later,
|
|
or loaded as a secondary boot loader by the new GRUB installation
|
|
from LFS.</para>
|
|
</warning>
|
|
|
|
<screen role="nodump"><userinput>grub-install --target=x86_64-efi --removable</userinput></screen>
|
|
|
|
<para>
|
|
The command above assumes 64-bit UEFI firmware.
|
|
If you want to make the system bootable on a 32-bit UEFI firmware,
|
|
run the command again with <literal>x86_64-efi</literal> replaced by
|
|
<literal>i386-efi</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
The <parameter>--removable</parameter> option makes
|
|
<command>grub-install</command> use the standard location,
|
|
i.e. <filename>EFI/BOOT/BOOTX64.EFI</filename> (or
|
|
<filename>EFI/BOOT/BOOTIA32.EFI</filename> for
|
|
<literal>i386-efi</literal>), instead of the location GRUB prefers
|
|
(<filename>EFI/GRUB/GRUBX64.EFI</filename> or
|
|
<filename>EFI/GRUB/GRUBIA32.EFI</filename>). Using a non-standard
|
|
location would need to record the location in a EFI variable, but
|
|
LFS lacks the utility for manipulating EFI varaibles.
|
|
</para>
|
|
|
|
<para>
|
|
The GRUB installation for BIOS, 64-bit UEFI, and 32-bit UEFI can
|
|
coexist and share the same configuration. So you can create both
|
|
the BIOS Boot Partition and the EFI System Partition, and install
|
|
GRUB for all the supported firmware types (i.e. running three
|
|
<command>grub-install</command> commands) if you are unsure about
|
|
your firmware type, or you plan to move the hard drive to a different
|
|
computer.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="grub-cfg">
|
|
<title>Creating the GRUB Configuration File</title>
|
|
|
|
<para>Generate <filename>/boot/grub/grub.cfg</filename>:</para>
|
|
|
|
<screen><userinput>cat > /boot/grub/grub.cfg << "EOF"
|
|
<literal># Begin /boot/grub/grub.cfg
|
|
set default=0
|
|
set timeout=5
|
|
|
|
insmod part_gpt
|
|
insmod ext2
|
|
set root=(hd0,2)
|
|
set gfxpayload=1024x768x32
|
|
|
|
menuentry "GNU/Linux, Linux &linux-version;-lfs-&version;" {
|
|
linux /boot/vmlinuz-&linux-version;-lfs-&version; root=/dev/sda2 ro
|
|
}</literal>
|
|
EOF</userinput></screen>
|
|
|
|
<para>
|
|
The <command>insmod</command> commands load the
|
|
<application>GRUB</application> modules named
|
|
<filename>part_gpt</filename> and <filename>ext2</filename>.
|
|
Despite the naming, <filename>ext2</filename> actually supports
|
|
<systemitem class='filesystem'>ext2</systemitem>,
|
|
<systemitem class='filesystem'>ext3</systemitem>, and
|
|
<systemitem class='filesystem'>ext4</systemitem> filesystems.
|
|
As we've discussed, in a typical configuration these two
|
|
modules are already embedded in the main GRUB image by
|
|
<command>grub-install</command> and those two
|
|
<command>insmod</command> commands will do nothing. But they do no
|
|
harm anyway, and they may be needed with some rare configurations.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>set gfxpayload=1024x768x32</command> command sets the
|
|
resolution and color depth of the VESA framebuffer to be passed to the
|
|
kernel. It's necessary for the kernel SimpleDRM driver to use the
|
|
VESA framebuffer. You can use a different resolution or color depth
|
|
value which better suits for your monitor. This line does nothing
|
|
when the system is booted via UEFI, but it does no harm anyway.
|
|
</para>
|
|
|
|
<note><para>From <application>GRUB</application>'s perspective, the
|
|
kernel files are relative to the partition used. If you
|
|
used a separate /boot partition, remove /boot from the above
|
|
<emphasis>linux</emphasis> line. You will also need to change the
|
|
<emphasis>set root</emphasis> line to point to the boot partition.
|
|
</para></note>
|
|
|
|
<note>
|
|
<para>The GRUB designator for a partition may change if you added or
|
|
removed some disks (including removable disks like USB thumb devices).
|
|
The change may cause boot failure because
|
|
<filename>grub.cfg</filename> refers to some <quote>old</quote>
|
|
designators. If you wish to avoid such a problem, you may use
|
|
the UUID of a partition and the UUID of a filesystem instead of a GRUB designator to
|
|
specify a device.
|
|
Run <command>lsblk -o UUID,PARTUUID,PATH,MOUNTPOINT</command> to show
|
|
the UUIDs of your filesystems (in the <literal>UUID</literal> column) and
|
|
partitions (in the <literal>PARTUUID</literal> column). Then replace
|
|
<literal>set root=(hdx,y)</literal> with
|
|
<literal>search --set=root --fs-uuid <replaceable><UUID of the filesystem
|
|
where the kernel is installed></replaceable></literal>, and replace
|
|
<literal>root=/dev/sda2</literal> with
|
|
<literal>root=PARTUUID=<replaceable><UUID of the partition where LFS
|
|
is built></replaceable></literal>.</para>
|
|
<para>Note that the UUID of a partition is completely different from the
|
|
UUID of the filesystem in this partition. Some online resources may
|
|
instruct you to use
|
|
<literal>root=UUID=<replaceable><filesystem UUID></replaceable></literal>
|
|
instead of
|
|
<literal>root=PARTUUID=<replaceable><partition UUID></replaceable></literal>,
|
|
but doing so will require an initramfs, which is beyond the scope of
|
|
LFS.</para>
|
|
<para>The name of the device node for a partition in
|
|
<filename class='directory'>/dev</filename> may also change (this is less
|
|
likely than a GRUB designator change). You can also replace
|
|
paths to device nodes like <literal>/dev/sda1</literal> with
|
|
<literal>PARTUUID=<replaceable><partition UUID></replaceable></literal>,
|
|
in <filename>/etc/fstab</filename>, to avoid a potential boot failure
|
|
in case the device node name has changed.</para>
|
|
</note>
|
|
|
|
<para>GRUB is an extremely powerful program and it provides a tremendous
|
|
number of options for booting from a wide variety of devices, operating
|
|
systems, and partition types. There are also many options for customization
|
|
such as graphical splash screens, playing sounds, mouse input, etc. The
|
|
details of these options are beyond the scope of this introduction.</para>
|
|
|
|
<caution><para>There is a command, <application>grub-mkconfig</application>, that
|
|
can write a configuration file automatically. It uses a set of scripts in
|
|
/etc/grub.d/ and will destroy any customizations that you make. These scripts
|
|
are designed primarily for non-source distributions and are not recommended for
|
|
LFS. If you install a commercial Linux distribution, there is a good chance
|
|
that this program will be run. Be sure to back up your grub.cfg file.</para></caution>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|