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.

[zeckma]

My zeckma/uefi-support branch is in a good state after having pulled Xi's changes and changed and added some things.

We just need to ensure jhalfs works fine. After then, I think the branch will be ready to be reviewed.

[pierre]

For jhalfs, no problem: it does not run the grub-install command (too dangerous), and lets the user do it at the end of the build (same for passwords, and creating a non root user, etc). So, there is no problem with the uefi branch in this respect. But ...

I have tested the zeckma/uefi-support branch on my laptop (a Lenovo legion), and there is no way to select the hardcoded location in the UEFI menu! The solution I took was to use efibootmgr from the host to add the hardcoded location to the UEFI menu... I suggest to add a note or so, telling how to do that in case the harcoded location does not appear in the menu.

Then the branch could be merged, IMO.

[Xi Ruoyao]

There is a note about the necessity to use efibootmgr in ​https://www.linuxfromscratch.org/~xry111/lfs/view/arm64-systemd/chapter10/grub.html. I thought the issue was specific to my box for LFS arm64 development but it seems not so specific now.

[zeckma]

Pierre, was booting with the EFI Variable system mounted required to get the system to boot, and did you need to mount the EFI Variable system at all during the process?

[zeckma]

I pushed a new commit to zeckma/uefi-support which includes a <note> on how to go about creating a boot entry for such systems, and which systems that may be susceptible to the issue.

[pierre]

Replying to zeckma:

Pierre, was booting with the EFI Variable system mounted required to get the system to boot, and did you need to mount the EFI Variable system at all during the process?

Not sure what you mean exactly with "booting with the EFI Variable system mounted"... I can tell you what I did:

• after running grub-install --removable in chroot (which does not need the efivarfs mounted in chroot AFAICT), exiting chroot, unmounting kernel vfs, and rebooting, I noticed that the harcoded location was not appearing, so I rebooted to the host system (debian stable).
• of course, on the host system efivarfs is mounted. I installed efibootmgr with apt, then run it. Unfortunately, I cannot remember the exact command (just that it needed some tuning to get it right). I guess it is close to what you are proposing in the note (BTW, why use y for the partition number?). Maybe you could add that this can be run from the host (as root), which removes the need for installing efibootmgr (and deps) from BLFS.

[zeckma]

Replying to pierre:

Replying to zeckma:

Pierre, was booting with the EFI Variable system mounted required to get the system to boot, and did you need to mount the EFI Variable system at all during the process?

Not sure what you mean exactly with "booting with the EFI Variable system mounted"...

In ​https://linuxfromscratch.org/blfs/view/svn/postlfs/grub-setup.html (SysV), it mentions adding to the fstab parameters to mount efivarfs at boot. It isn't exactly explained why this should be done. But from what I read, it isn't really necessary. For the Systemd version of BLFS, it says this is done automatically, but it's still important to keep tabs on what's happening.

I can tell you what I did:

• after running grub-install --removable in chroot (which does not need the efivarfs mounted in chroot AFAICT), exiting chroot, unmounting kernel vfs, and rebooting, I noticed that the harcoded location was not appearing, so I rebooted to the host system (debian stable).
• of course, on the host system efivarfs is mounted. I installed efibootmgr with apt, then run it. Unfortunately, I cannot remember the exact command (just that it needed some tuning to get it right). I guess it is close to what you are proposing in the note (BTW, why use y for the partition number?).

I read up on potential uses of efibootmgr to create an entry, and that showed up, so I included it. If it isn't needed, I can remove it. Same with the drive, if that part isn't needed either. Gonna have to explore exactly what is and isn't needed.

Maybe you could add that this can be run from the host (as root), which removes the need for installing efibootmgr (and deps) from BLFS.

Good idea on this one. Perhaps the command doesn't have to be altered, so it's more general purpose.

[zeckma]

I tested the command and confirmed that it works on my system. This one is with OpenRC that I'm using for testing OpenRC instructions. An MSI laptop.

[Xi Ruoyao]

Running grub-install without --removable will require efivarfs to be mounted. And I guess (?) even with --removable if efivarfs is not mounted grub will default to install for i386-pc instead of x86_64-efi, unless you add the --target=x86_64-efi option.

[pierre]

Replying to Xi Ruoyao:

Running grub-install without --removable will require efivarfs to be mounted. And I guess (?) even with --removable if efivarfs is not mounted grub will default to install for i386-pc instead of x86_64-efi, unless you add the --target=x86_64-efi option.

Sorry for having been lazy writing the full command. I did run grub-install --removable --target=x86_64-efi...

[pierre]

Replying to zeckma:

In ​https://linuxfromscratch.org/blfs/view/svn/postlfs/grub-setup.html (SysV), it mentions adding to the fstab parameters to mount efivarfs at boot. It isn't exactly explained why this should be done. But from what I read, it isn't really necessary. For the Systemd version of BLFS, it says this is done automatically, but it's still important to keep tabs on what's happening.

I can tell you from previous experience that efivarfs needs to be mounted for efibootmgr to be able to modify boot variables. But yes, systemd mounts it automagically at boot. SysV certainly doesn't. For openrc, I cannot tell, but it needs specific code in the init binary. Note that when running grub-install in chroot, as said by Xi, efivarfs has to be mounted.

[zeckma]

Replying to pierre:

I can tell you from previous experience that efivarfs needs to be mounted for efibootmgr to be able to modify boot variables. But yes, systemd mounts it automagically at boot. SysV certainly doesn't. For openrc, I cannot tell, but it needs specific code in the init binary. Note that when running grub-install without --removable in chroot, as said by Xi, efivarfs has to be mounted.

For OpenRC, efivarfs is apparently mounted via /etc/init.d/sysfs, part of the boot runlevel, which is nice to know but not helpful for mainline LFS at the moment.

So far, I think the branch covers every major piece of info and addressed most if not everything here. I think this branch is ready for review.

[zeckma]

zeckma/uefi-support has now been merged into trunk after I got the go-ahead from Bruce via email. I'll adjust BLFS as necessary, then all the major branches will get the changes as well.

[zeckma]

Everything should now be caught up!