UEFI support

[zeckma]

We tell users to go to BLFS to build and setup GRUB for UEFI boot support. The issue with this is that most systems nowadays use UEFI booting, and a lot don't even have a legacy boot option available. Being told to go to another book for this is clumsy, and also requires the user to find a way to get the packages from BLFS. Some users are led to believe that they have to install more than 5 packages just for UEFI support. They are also told pretty late in the process, instead of being told upfront during the partitioning stage the situation regarding BIOS and UEFI.

This has been a long standing issue and I think it's time we work something out here. There already has been some work in branches me and xry111 created. I worked mainly on documentation, while xry111 worked on instructions. This was done in early 12.4. Fundamentally, the issue is simple. We don't need FreeType2 or efibootmgr at all. All that's needed is to build GRUB as shown in BLFS, which only adds the --with-platform=efi and --target=x86_64 parameters, and do a normal install from there. For doing grub-install, just add the --removable flag so that the EFI file gets put in a hardcoded location, skipping the need for efibootmgr. We should still keep efibootmgr in BLFS to better handle EFI entries if needed.

This has been known about for a little while now. There is an issue though, regarding --target=x86_64 specifically, and handling different architectures. Most solutions would look fine when rendered, for humans to read. But jhalfs would break as it wouldn't reconcile with which instructions to actually run. We have to find a way to create XML that doesn't break jhalfs, or alter jhalfs somehow to reconcile.

It's been a while since this issue was being worked on, xry111 knew most about this issue. So for further info, it'd be good for him to better shed light on the issue.

Ideally, I want this coming in at 12.5. This was planned before 12.4, but the issue stopped us from working on it.

[Bruce Dubbs]

While I understand what your motivations are, I'm not sure that we really need to do this. There are several issues regarding the transition from LFS to BLFS that we don't address comprehensively. These include wireless connectivity and dhcp.

From my point of view sudo, wget (along with make-ca), and ssh are also pretty critical packages. I did address all these issues in my article at ​https://anduin.linuxfromscratch.org/~bdubbs/external-lfs.

At a presentation I made a couple of weeks ago I was asked what a user could do with a base LFS system. My answer was "Build more packages."

From the standpoint of UEFI, perhaps the easiest way to do an initial boot is to not install GRUB at all, but to use what is installed for the host unless you are going to have a dedicated bootable drive.

[thomas]

The boot loader

While I understand what your motivations are, I'm not sure that we really need to do this.

It is not needed to do it but maybe it should be done. It looks like that UEFI is the mechanism with which PCs are started nowadays. LFS should support what is commonly required/used. The user can hardly deside when a new PC is bought, so the book should switch from doing

• "BIOS and optionally UEFI"
  that was when EFI was invented and was kinda exotic

to

• "UEFI and optionally BIOS"
  now, EFI is in hardware with no choice for the users and the latter is to support 'old' HW

From the standpoint of UEFI, perhaps the easiest way to do an initial boot is to not install GRUB at all, but to use what is installed for the host unless you are going to have a dedicated bootable drive.

Yes, dropping the boot loader is indeed a possible option as most of the people who are doing LFS, have one installed already. But without one, the book is incomplete IMHO and therefore i'd tend to say that is not really a good option. At least, BLFS must have a chapter covering boot loader or boot loaders since grub is not the only one.

The "LFS/BLFS gap"

This is a separate thread and has nothing to do with the boot loader and therefore, a separate ticket might be opened for it.

There are several issues regarding the transition from LFS to BLFS that we don't address comprehensively. These include wireless connectivity and dhcp.

From my point of view sudo, wget (along with make-ca), and ssh are also pretty critical packages. I did address all these issues in my article at ​https://anduin.linuxfromscratch.org/~bdubbs/external-lfs.

IMHO, there is no need to include dhcp nor ssh into LFS. User should be able to select an unused IP address of the actual network. If a static IP is provided, then LFS can do networking. But if required, dhcpcd isn't that complex so it might be optional in LFS. Wireless is a tricky thing as the host may have only wireless, so the freshly built LFS cannot use it. The LFS book could state that a wired connection is required in the phase from from booting into the new LFS until the wireless tools are built.

I think sudo is also not needed as the user has the tools (ch8:shadow) to create an ordinary user and set its and root's password. When LFS is booted, use one tty for the user, another tty for root. A third tty for browsing in the BLFS book via lynx. That's all u need. Without sudo, it is still possible to go on from LFS to BLFS.

At a presentation I made a couple of weeks ago I was asked what a user could do with a base LFS system. My answer was "Build more packages."

Which is - after a reboot as described in 11.3 - not true. It cannot be used for that as it has no client to download anything in a sufficiently comfortable way nor to read/browse the book(s). To build more packages, you shouldn't leave the chroot env for a while until enough packages are installed so that the new system can do downloads with ots own tools.

What LFS is really lacking is a (https-)client like wget, lynx, curl or something. Not even bash can be used as the --enable-net-redirections​¹ is not given. wget or lynx seems to be simple packages for networking (preferable lynx as it can be used to show the books after reboot, too. wget can only download it). With them, the very next packages after finishing and booting LFS can be downloaded. The LFS book could be extended by a small chapter 10½ were some packages gets installed which enables a booted LFS do download something from the internet. Those packages (libtasn1, polkit, make-ca, wget) might be stripped down in terms of dependencies and a clear note that those pkgs are only a vehicle for the transition from LFS to BLFS and that they will be overwritten in BLFS. They are in LFS only to enable a freshly booted LFS to go on with BLFS.

[zeckma]

I think this is a trap that a lot of issues fall into in regards to any of the LFS books, where an issue is presented, and a solution, but the solution is deemed not good enough as there is a better solution. This solution may not be better at all and may require a lot more effort to do. Either way, the result is the issue gets stalled and does not get taken care of.

In this case, the goal is to boot without tools provided by the host, instead rather by the target. This has to consider LFS targets that are installed on separate drives where only the LFS system is present. This can be the case from installing from a livecd onto a completely new SSD. The majority of systems are UEFI.

So the options are on the table:

1. Skip dealing with a bootloader and document properly how to boot from the target only using the targets installed tools (not the host's) that is not needlessly complicated. This will involve a good amount of work.
2. Simply enable UEFI booting in GRUB with minimal effort and a little extra documentation. Once the multi-target jhalfs issue is figured out, it will be a really simple change. This is usually what most users want. Other options range from using another bootloader to using EFI-stub.

To me, the simplest option and least-polarizing will be option 2. In the mean time, we can create solution 1. while having the easy generic solution already available in the book.