Am 27.09.2014 um 22:29 schrieb Dan McGhee:
I was able to achieve my "grub and uefi" goals using this package.
Apparently, it is the result of some serious EFI work by the grub
developers.
I know that UEFI is still pretty much a "magic, black box," but I'm
sure the firmware will proliferate since its advent with Win-8x
machines. As a result, I recommend that this package be seriously
considered for inclusion in LFS-7.7.
Currently, I could find the archive only at
https://launchpad.net/grub/grub2/2.02
and not on any of the sites at which gnu places it's stable software.
It's probably available through git at savanna, but I'm not at all
familiar with the operations of git and didn't want to obtain an alpha
version of grub.
UEFI support indeed is the reason for most distributions to choose GRUB
2.02. In terms of support for BIOS there do not seem to be many changes
between 2.00 and 2.02 beta2.
But: Building the EFI boot image is fundamentally different from
building and installing GRUB for BIOS. As a hint, to prepare GRUB for
x64 UEFI, take a look at:
https://github.com/mschlenker/lesslinux-builder/blob/master/scripts/stage02/5342_grub_efi.xml
Look at the "--platform"! (You can skip the cross compiler - LessLinux
currently uses a 32 bit userland on a 64 bit kernel, so 64 bit binaries
need a cross compiler). Building a valid EFI image that contains all
relevant GRUB modules for a successful boot on typical LFS systems is a
bit more complicated, though.
1. Some configuration has to be specified as GRUB ramdisk - usually you
just need: /boot/grub/grub.cfg (residing in
/tmp/memdisk/boot/grub/grub.cfg on the host). In theory, this config
file could already include the menu entries. In practice it makes
more sense to search for a certain partition and include the config
files found there:
if ! search --file --set=root
/boot/grub/65253eae-c51d-48cd-a8e7-855ff1230e3d.pt ; then
search --file --set=root
/boot/grub/65253eae-c51d-48cd-a8e7-855ff1230e3d.cd
fi
set prefix=($root)/boot/grub
if [ -e $prefix/x86_64-efi/grub.cfg ]; then
configfile $prefix/x86_64-efi/grub.cfg
else
configfile $prefix/grub.cfg
fi
In this case a file
/boot/grub/65253eae-c51d-48cd-a8e7-855ff1230e3d.pt is prefereed over
a file with suffix .cd. This is just for LessLinux' to search first
on USB thumbdrives and then for bootable CDs. It is a more strict
check than Ubuntus search for a .disk folder. On a LFS system you'd
probably go with the UUID or the label of your root partition.
2. You then tar the memdisk:
tar -C /tmp/memdisk -cvf /tmp/memdisk.tar boot
3. Now you can assemble a valid UEFI image - mine includes also some
modules like ls or minicmd that help with debugging:
grub-mkimage -d /usr/lib/grub/x86_64-efi -Ox86_64-efi -o
/tmp/grubx64.efi \
part_gpt part_msdos ntfs ntfscomp fat ext2 btrfs normal chain boot \
configfile linux multiboot iso9660 udf search search_fs_file
search_fs_uuid \
search_label memdisk tar minicmd ls -m /tmp/memdisk.tar
4. Now copy /tmp/grubx64.efi as /EFI/BOOT/BOOTX64.EFI to your FAT
partition marked as EFI bootable. Since this partition just takes
the EFI files it can be just a few megabytes. Grub will search the
partition containing the file
/boot/grub/65253eae-c51d-48cd-a8e7-855ff1230e3d.pt, include a file
/boot/grub/x86_64-efi/grub.cfg from there and continue. You might
want to have additional GRUB modules in /boot/grub/x86_64-efi, but
since most of the relevant modules are already included in the EFI
blob chances are good you do not actually need them.
In this case GRUB behaves like a bootloader. It executes the kernel
replacing the current EFI process. This allows booting 32 bit kernels on
64 bit systems and booting old kernels without all the EFI stubs
compiled in to boot. However, I experienced some problems for GRUB not
properly passing the UEFI framebuffer parameters to the kernel which
effectively means you won't get any console output until the KMS can
initialize the graphics card. A really big advantage of using GRUB for
UEFI is that the kernel, initramfs and config can reside on the
partition containing the rootfs. Thus most distributions did not have to
change the scripts for updating the grub.cfg upon a kernel update.
Then there are bootloaders like gummiboot that are not bootloaders at
all. Gummiboot is just an EFI executable file selector. It requires your
linux kernel and initramfs to be placed on the EFI boot partition and it
requires your kernel to be properly built with EFI stubs. It does not
allow booting 32 bit kernels on 64 bit loaders. These might all be
disadvantages for big distributions. On the other hand it is dead simple
to configure and very robust. My USB LFS currently boots with gummiboot,
a hint will follow in the next days.
If we want to keep up with big distributions we should go with GRUB as
default loader for UEFI. If we want our readers to understand the bits
and pieces of a linux distribution, I recommend using gummiboot.
I can just tell from my experience. The decision which loader to use
finally as UEFI loader is up to the maintainers of the project. I just
started writing a hint on gummiboot. If desired a hint on GRUB as UEFI
loader will follow soon. When we are done with that, we have to take a
look at preloader.efi and shim.efi, two signed first stage efi loaders
that allow LFS to be started on machines with UEFI secure boot still
enabled. I got experience with both of them and both have advantages and
disadvantages.
Yours,
Mattias
PS: And that's not all. About two years ago noone thought anyone would
be mad enough selling 32 bit EFI anymore (I've seen Apples 32 bit UEFI
and some rather broken 32 bit UEFI implementations on some ca. 2010 Asus
notebooks/netbooks). But with Intels Clover Trail Bay Trail
architecture, many Notebooks, Netbooks, Tablets, Convertibles hit the
market where a 32 bit boot loader effectively crippled 64 bit hardware.
Why? When Intel acquired PowerVR, the graphics core was thought for the
use in smartphones and tablets. Drivers were only available in 32 bit
versions. So, no 64 bit Windows drivers were available (neither
certified). What to do? Forge an unholy alliance: Intel delivers 32 bit
drivers only and specifies that tablets/convertibles have to sport an 32
bit UEFI as well. Microsoft steps in and delivers installable images of
32 bit Windows 8 on UEFI. When Windows 8 was released 32 bit was
considered as a fading platform, thus only images for UEFI were available.
For us Linux guys and girls, the problem is not too big: Build any valid
32 bit UEFI loader, prepare a decent thumb drive using a 32 bit PAE
kernel and boot on the tablet/convertible (bypassing secure boot with
some power/volume down key combination). Now we even have UEFI mixed
mode: A kernel pretends to be a valid 32 bit EFI binary, but upon boot
switches to 64 bit mode. I yet have to test it, I'll get a Clover Trail
tablet in the next days.
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
