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 configured into the kernel: > 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 module "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> Here is the line I use in /etc/fstab: > efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 1 At this point, you are ready to get set up to boot. Once you have the 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
