Dan McGhee
2013-12-19 18:43:04 UTC
Booting LFS can now involve a series of decisions on how you want to
boot. If you don't have UEFI firmware it's easy. Follow the GRUB2
instructions in Ch. 8.4. If you have UEFI firmware, the situation can
get a little "stickier." Now the decision is to boot using GRUB2 in the
"BIOS Mode" or to use the kernels "efi stubs" to boot without GRUB2.
(NOTE: All the testing I have done to date indicates that, GRUB2, as
compiled and built in LFS-7.4--modifying the configuration options from
the book, will not boot an LFS kernel. I plan to do more "in depth"
testing to verify this. If anyone has specific questions about what I
have done and the reasons why I came to this conclusion, I will be more
than happy to answer them. At this point, this post is a set of
directions on how to build and boot a kernel using the efi stubs and not
a discussion of research.)
In either case, the first thing to do is determine whether or not you
have this firmware. If your box came with Windows 8 installed you
definitely have it. You might have it if Windows 7 came installed. If
you have x86_64, you probably do.
In either case verify it.
In a utility of your choice, I use 'parted,' examine the partition
table. There are two entries that are of interest. In parted they are:
Partition Table: gpt
2 420MB 693MB 273MB fat32 EFI system
partition boot
The firsts entry indicates that you have a gpt partition table and that
your firmware is "gpt aware." If it were not, if you checked your hard
drive in Windows, it would indicate one large partition for the whole disk.
The second entry is, as it says, the EFI partition. It is the location
for the files that the System Boot Manager uses to boot. This is the new
way of doing things. The system uses a boot manager to select boot
loaders. Although GRUB2 has a lot of characteristics of a boot manager
it is a boot loader, and, therefore, must have the ability to be
selected by the boot manager. The EFI partition is identified by the
name and the fact that the "boot" flag is set. This is not what most of
us are used to. This "boot" flag does not make the partition "bootable"
it identifies is as the EFI partition. Maybe it would have been more
clear if parted had chosen a different name for the flag.
The EFI partition is usually the first partition on the disk. It
doesn't have to be, but it usually is. In any case, it exists as close
as possible to Sector 1 depending on what your manufacturer has done.
By convention in Linux, it is mounted at /boot/efi. If you've booted
into a non-LFS system you can check this by simply running:
df /boot/efi
You may discover, after you've verified that this partition exists on
your disk, that it's mounted at another mount point or not mounted at
all. To use the UEFI firmware, it must be mounted. In your LFS system,
it is probably a good idea to add an entry to /etc/fstab:
/dev/sdaX /boot/efi vfat defaults 0 1
And finally run:
[ -d /sys/firmware/efi ] && echo "EFI boot on HDD" || echo "Legacy boot on HDD"
If the result is "Legacy boot on HDD," then either the BIOS in not UEFI,
or the BIOS is not set up to boot the HDD in UEFI mode. If you're not
booted in UEFI mode, you won't be able to set up to boot in UEFI.
If you choose to use GRUB2 in the BIOS Mode, mounting the EFI partition
is not necessary.
On a GPT disk, there is an area at LBA0 called the "MBR Protected
Layer." This is for "backwards compatibilty." Using the commands in
Ch. 8.4, GRUB2 will write its image there. Since I did not test this, I
do not know if GRUB2 installed this way in UEFI firmware will boot other
linux systems by using a menu entry similar to what is used to boot
LFS. You can boot other systems if they have entries on the EFI
partition by chainloading them.
Build the kernel in accordance with Ch. 8.3 of the LFS book. Make sure
that you have everything necessary to mount and boot into your LFS
system configured into the kernel and not set as modules. There are two
additional things that you need.
1) the kernel needs to know where to mount the file systems and this
system doesn't have GRUB2 to tell it where. Therefore, you need to
compile command line parameters
CONFIG_CMDLINE="root=<partition that contains LFS> ro"
2) The ability to use the EFI partition and EFI variables must be
"efivars." The EFI variables in linux have been moved to the efivarfs
and the module will "go away" in future kernels.
It is imperative that the EFI variables are available to you to go any
further. If your current kernel does not have the EFI support
configured into it, as indicated above, you need to reconfigure and
rebuild your kernel as indicated. If your current setup supports the
module system then <lsmod> should tell you whether the module "efivars"
is loaded. If not, use "insmod" or "modprobe" to load it. If, on the
other hand, your current kernel has efivarfs configured into it, make
sure it is mounted.
<mount -v -t efivarfs /sys/firmware/efi/efivars efivarfs>
EFI partition mounted and the EFI variables available, put your new
kernel on the EFI partition.
$ mkdir -p <your EFI partition mount point>/EFI/<some directory name>. #
I used lfs-7.4
$cp -v /boot/vmlinuz-3.10.10-lfs-7.4 <mount point/EFI/<new
directory>/kernel.efi #The name is just arbitary but must be of the form
"*.efi"
To make things clear, my set up is /boot/efi/EFI/lfs-7.4/kernel.efi.
At this point you should be able to boot. Restart the computer and
interrupt the boot process. In mine, I use <ESC>. This, in a UEFI
system will give you boot options. Choose the one that is similar to
"Boot from EFI file," and navigate to "kernel.efi." Select it and keep
your fingers crossed. :)
I recommend booting this way at least once just to make sure everything
works the way you want.
Alternatively, you can build and install "efibootmgr." To build and use
it, you *must* have either the module efivars loaded or efivarfs
mounted. It has a wonderful README about its use. What it can do is
create a new system boot manager entry and change the order of these
entries to make booting into your LFS easy--that is without having to
interrupt the boot process and navigating to the *.efi file.
The following is an example command that will boot you into LFS only and
no others all the time.
$ efibootmgr -c -d /dev/sda -p <number of EFI partition> -L "LFS" -I
'\EFI\lfs-7.4\kernel.efi' -u root=/dev/<LFS partition> ro #The back
slashes are not a type-o.
This command creates a boot manager entry that boots from
\EFI\lfs-7.4\kernel.efi file with the options root=/dev/<LFS partition>
ro passed to the kernel. Theoretically, the -d and -p options are not
necessary unless your EFI partition is in a place *other than*
/dev/sda1. I did not ever use the -u option in my experiments. Now that
I'm seeing this again, I don't know why.
If you choose to use efibootmgr the README in the source tree tells you
how to use all the options and gives examples of what they do.
To come up with what I have written here, I've used many, many
references. I purposefully did not include here the logic for my
choices. Nor did I include any of the references. I will be more than
happy to try to answer any "why" questions and provide references. If
it's appropriate, I can post a list of links for my references.
Dan
boot. If you don't have UEFI firmware it's easy. Follow the GRUB2
instructions in Ch. 8.4. If you have UEFI firmware, the situation can
get a little "stickier." Now the decision is to boot using GRUB2 in the
"BIOS Mode" or to use the kernels "efi stubs" to boot without GRUB2.
(NOTE: All the testing I have done to date indicates that, GRUB2, as
compiled and built in LFS-7.4--modifying the configuration options from
the book, will not boot an LFS kernel. I plan to do more "in depth"
testing to verify this. If anyone has specific questions about what I
have done and the reasons why I came to this conclusion, I will be more
than happy to answer them. At this point, this post is a set of
directions on how to build and boot a kernel using the efi stubs and not
a discussion of research.)
In either case, the first thing to do is determine whether or not you
have this firmware. If your box came with Windows 8 installed you
definitely have it. You might have it if Windows 7 came installed. If
you have x86_64, you probably do.
In either case verify it.
In a utility of your choice, I use 'parted,' examine the partition
table. There are two entries that are of interest. In parted they are:
Partition Table: gpt
2 420MB 693MB 273MB fat32 EFI system
partition boot
The firsts entry indicates that you have a gpt partition table and that
your firmware is "gpt aware." If it were not, if you checked your hard
drive in Windows, it would indicate one large partition for the whole disk.
The second entry is, as it says, the EFI partition. It is the location
for the files that the System Boot Manager uses to boot. This is the new
way of doing things. The system uses a boot manager to select boot
loaders. Although GRUB2 has a lot of characteristics of a boot manager
it is a boot loader, and, therefore, must have the ability to be
selected by the boot manager. The EFI partition is identified by the
name and the fact that the "boot" flag is set. This is not what most of
us are used to. This "boot" flag does not make the partition "bootable"
it identifies is as the EFI partition. Maybe it would have been more
clear if parted had chosen a different name for the flag.
The EFI partition is usually the first partition on the disk. It
doesn't have to be, but it usually is. In any case, it exists as close
as possible to Sector 1 depending on what your manufacturer has done.
By convention in Linux, it is mounted at /boot/efi. If you've booted
into a non-LFS system you can check this by simply running:
df /boot/efi
You may discover, after you've verified that this partition exists on
your disk, that it's mounted at another mount point or not mounted at
all. To use the UEFI firmware, it must be mounted. In your LFS system,
it is probably a good idea to add an entry to /etc/fstab:
/dev/sdaX /boot/efi vfat defaults 0 1
And finally run:
[ -d /sys/firmware/efi ] && echo "EFI boot on HDD" || echo "Legacy boot on HDD"
If the result is "Legacy boot on HDD," then either the BIOS in not UEFI,
or the BIOS is not set up to boot the HDD in UEFI mode. If you're not
booted in UEFI mode, you won't be able to set up to boot in UEFI.
If you choose to use GRUB2 in the BIOS Mode, mounting the EFI partition
is not necessary.
On a GPT disk, there is an area at LBA0 called the "MBR Protected
Layer." This is for "backwards compatibilty." Using the commands in
Ch. 8.4, GRUB2 will write its image there. Since I did not test this, I
do not know if GRUB2 installed this way in UEFI firmware will boot other
linux systems by using a menu entry similar to what is used to boot
LFS. You can boot other systems if they have entries on the EFI
partition by chainloading them.
Build the kernel in accordance with Ch. 8.3 of the LFS book. Make sure
that you have everything necessary to mount and boot into your LFS
system configured into the kernel and not set as modules. There are two
additional things that you need.
1) the kernel needs to know where to mount the file systems and this
system doesn't have GRUB2 to tell it where. Therefore, you need to
compile command line parameters
CONFIG_CMDLINE="root=<partition that contains LFS> ro"
2) The ability to use the EFI partition and EFI variables must be
CONFIG_EFI_PARTITION=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_FB_EFI=y
# EFI (Extensible Firmware Interface) Support
# CONFIG_EFI_VARS is not set
CONFIG_EFIVAR_FS=y
Please note that this configuration does not employ the moduleCONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_FB_EFI=y
# EFI (Extensible Firmware Interface) Support
# CONFIG_EFI_VARS is not set
CONFIG_EFIVAR_FS=y
"efivars." The EFI variables in linux have been moved to the efivarfs
and the module will "go away" in future kernels.
It is imperative that the EFI variables are available to you to go any
further. If your current kernel does not have the EFI support
configured into it, as indicated above, you need to reconfigure and
rebuild your kernel as indicated. If your current setup supports the
module system then <lsmod> should tell you whether the module "efivars"
is loaded. If not, use "insmod" or "modprobe" to load it. If, on the
other hand, your current kernel has efivarfs configured into it, make
sure it is mounted.
<mount -v -t efivarfs /sys/firmware/efi/efivars efivarfs>
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 1
At this point, you are ready to get set up to boot. Once you have theEFI partition mounted and the EFI variables available, put your new
kernel on the EFI partition.
$ mkdir -p <your EFI partition mount point>/EFI/<some directory name>. #
I used lfs-7.4
$cp -v /boot/vmlinuz-3.10.10-lfs-7.4 <mount point/EFI/<new
directory>/kernel.efi #The name is just arbitary but must be of the form
"*.efi"
To make things clear, my set up is /boot/efi/EFI/lfs-7.4/kernel.efi.
At this point you should be able to boot. Restart the computer and
interrupt the boot process. In mine, I use <ESC>. This, in a UEFI
system will give you boot options. Choose the one that is similar to
"Boot from EFI file," and navigate to "kernel.efi." Select it and keep
your fingers crossed. :)
I recommend booting this way at least once just to make sure everything
works the way you want.
Alternatively, you can build and install "efibootmgr." To build and use
it, you *must* have either the module efivars loaded or efivarfs
mounted. It has a wonderful README about its use. What it can do is
create a new system boot manager entry and change the order of these
entries to make booting into your LFS easy--that is without having to
interrupt the boot process and navigating to the *.efi file.
The following is an example command that will boot you into LFS only and
no others all the time.
$ efibootmgr -c -d /dev/sda -p <number of EFI partition> -L "LFS" -I
'\EFI\lfs-7.4\kernel.efi' -u root=/dev/<LFS partition> ro #The back
slashes are not a type-o.
This command creates a boot manager entry that boots from
\EFI\lfs-7.4\kernel.efi file with the options root=/dev/<LFS partition>
ro passed to the kernel. Theoretically, the -d and -p options are not
necessary unless your EFI partition is in a place *other than*
/dev/sda1. I did not ever use the -u option in my experiments. Now that
I'm seeing this again, I don't know why.
If you choose to use efibootmgr the README in the source tree tells you
how to use all the options and gives examples of what they do.
To come up with what I have written here, I've used many, many
references. I purposefully did not include here the logic for my
choices. Nor did I include any of the references. I will be more than
happy to try to answer any "why" questions and provide references. If
it's appropriate, I can post a list of links for my references.
Dan