What are the various EFI binaries for?

J

jem

Hi.

Ever since FreeBSD first started supporting native UEFI boot, I always used to use /boot/boot1.efi as the first boot loader by copying it to [ESP]/EFI/BOOT/BOOTX64.EFI. This has always worked just fine.

But I've just noticed the following in uefi(8):
Code: 
     The UEFI boot process proceeds as follows:
           1.   UEFI firmware runs at power up and searches for an OS loader
                in the EFI system partition.  The path to the loader may be
                set by an EFI environment variable.  If not set, an
                architecture-specific default is used.

                      Architecture    Default Path
                      amd64           /EFI/BOOT/BOOTX64.EFI
                      arm             /EFI/BOOT/BOOTARM.EFI
                      arm64           /EFI/BOOT/BOOTAA64.EFI

                The default UEFI boot configuration for FreeBSD installs
                loader.efi in the default path.

If loader.efi is now the correct binary to use for booting, this has me wondering what the purpose is of boot1.efi or gptboot.efi, or any of the other UEFI binaries:

Code: 
# ls -l /boot/*.efi
-r-xr-xr-x  1 root  wheel  114176 30 Jun 19:02 /boot/boot1.efi
-r-xr-xr-x  1 root  wheel  109568 30 Jun 19:02 /boot/gptboot.efi
-r-xr-xr-x  1 root  wheel  805376 30 Jun 19:02 /boot/loader_4th.efi
-r-xr-xr-x  2 root  wheel  892928 30 Jun 19:02 /boot/loader_lua.efi
-r-xr-xr-x  1 root  wheel  747520 30 Jun 19:02 /boot/loader_simp.efi
-r-xr-xr-x  2 root  wheel  892928 30 Jun 19:02 /boot/loader.efi

(loader.efi and loader_lua.efi are hardlinks of the same file)

Can anyone shed any light on this?

EDIT: boot1.efi(8) sheds light on this. boot1.efi is deprecated and should be replaced by loader.efi. Still curious what gptboot.efi is for.
 
Last edited:
Look at the commit: here. Basically used for EFI boot on disk with GPT scheme and UFS rootfs. Man page was missing and PR was logged by grahamperrin@ some time ago.
Interestingly enough I don't have the man page even on my 13.1 VM (my HW machines use still 12.x).
 
jem said:
If loader.efi is now the correct binary to use for booting, this has me wondering what the purpose is of boot1.efi or gptboot.efi, or any of the other UEFI binaries:
Click to expand...
None, AFAIK they're all legacy. I'm not sure since when (12? 13?), but loader now can boot every supported scenario directly as the EFI bootloader.
 
loader_4th was the 'old' Forth loader(8), it got replaced with the LUA loader; loader_lua with 12.0 if I recall correctly. But the old Forth loader is still kept, you can switch back to it if you want. It's going to be removed in some future version though. boot1.efi is still around as sometimes an existing efi partition is too small for loader.efi.
 
SirDice said:
boot1.efi is still around as sometimes an existing efi partition is too small for loader.efi.
Click to expand...
Uhm. Ok, it's kind of plausible :D ... but I'm sure you're aware that you're way outside UEFI specs if your ESP is too small for loader(8)...

Do you have a source that this is indeed the reason to keep it?
 
Older installs created a tiny efi partition. When we still used dd(1) to write efi.fat. loader.efi won't fit in there.
 
SirDice of course I remember that (and that wasn't in line with specs, so it did cause a few problems). But is that really the reason to keep boot1.efi etc? So they must be kept forever for installations that were once made on FreeBSD 11? :-/
 
zirias@ said:
But is that really the reason to keep boot1.efi etc?
Click to expand...
Don't know for sure, but it seems like a reasonable explanation.

zirias@ said:
So they must be kept forever for installations that were once made on FreeBSD 11?
Click to expand...
Deprecation and actual removal of things can take several major versions, at least that's been my experience over the past 25 or so years.
 
Actually yesterday I realized that boot1.efi is important part of my desktop/dev setup. One of my disks is shared between Linux and FreeBSD. I'm using grub, FreeBSD is chainloaded from it. I can't chainload loader.efi, it as to be boot1.efi. So this file is very important in this setup.
 
Never needed PXE/TFTP booting myself, so I can't tell for sure. But as the boot loader should just be downloaded from tftp and the interface is already configured by PXE, I don't see why it shouldn't. ? Maybe just test? ?
 
_martin said:
Actually yesterday I realized that boot1.efi is important part of my desktop/dev setup. One of my disks is shared between Linux and FreeBSD. I'm using grub, FreeBSD is chainloaded from it. I can't chainload loader.efi, it as to be boot1.efi. So this file is very important in this setup.
Click to expand...
And loader.efi lacks support for choosing partition/pool to be actually booted from at boot time.
boot1.efi has the functionality by patching and building with whichever of latest 2 patches on PR 207940. (The difference between 2 versions of patches is how the pools/partitions are displayed.)
Unless this (or equivalent) feature is implemented in loader.efi, I strongly object to actually deleting it from tree.

Note that legacy boot0 had this kind of functionality for MBR (not supported extended partitions, though).
 
T-Aoki said:
And loader.efi lacks support for choosing partition/pool to be actually booted from at boot time.
Click to expand...
Still, you can enter it interactively, setting currdev + if necessary vfs.root.mountfrom (and "discover" what's there with lsdev). I didn't think this was a common scenario, but if an easier (menu-driven?) selection is wanted, it would probably make much more sense to add that to loader.efi, for obvious reasons ... boot1.efi will go away.
 
Maybe just test?
Click to expand...
Can confirm, /boot/loader.efi as a UEFI chainloaded target, transferred via TFTP BOOTP, works fine.

Thanks all, Think I was just checking I wasn't barking up a tree that wasn't there, while setting something up...

And loader.efi lacks support for choosing partition/pool to be actually booted from at boot time.
Click to expand...

Picks up DHCP option 17 (Root Path) without issue, e.g. which NFS server and exported mountpoint to boot from.

FYI: Also respects the following DHCP options when passed to /boot/loader.efi:
  • Option 1 - Netmask
  • Option 3 - Router
  • Option 12 - Hostname
  • Option 17 - root-path
  • Option 16 - swap-server (Not using any NBDs so no idea if this is actually mounted as a swap source or not).
  • Option 26 - mtu
  • Option 54 - server-identifier
Not tried force sending unsolicited options to see if they are passed through to the kernel, only the items above.

if necessary vfs.root.mountfrom
Click to expand...
Wasn't needed for PXE UEFI booting, seems to pick up DHCP option 16 without any additional help. Nice!
 
_martin said:
logged by grahamperrin@
Click to expand...

C'est moi :-)

1727832051014.pngTo anyone who's interested in loader.efi(8): you'll not get the most recent edition of pages such as this if you use the preset markup that normally used in The FreeBSD Forums.

Current editions can be viewed with FreeBSD 15.0-CURRENT, and so on.
 
JamesElstone said:
Can confirm, /boot/loader.efi as a UEFI chainloaded target, transferred via TFTP BOOTP, works fine.

Thanks all, Think I was just checking I wasn't barking up a tree that wasn't there, while setting something up...



Picks up DHCP option 17 (Root Path) without issue, e.g. which NFS server and exported mountpoint to boot from.

FYI: Also respects the following DHCP options when passed to /boot/loader.efi:
  • Option 1 - Netmask
  • Option 3 - Router
  • Option 12 - Hostname
  • Option 17 - root-path
  • Option 16 - swap-server (Not using any NBDs so no idea if this is actually mounted as a swap source or not).
  • Option 26 - mtu
  • Option 54 - server-identifier
Not tried force sending unsolicited options to see if they are passed through to the kernel, only the items above.


Wasn't needed for PXE UEFI booting, seems to pick up DHCP option 16 without any additional help. Nice!
Click to expand...
Hmm, there seems to be mis-understandings.
What I meant was that I want to choose which "local" partition to boot from, like partition ada0p3 and ZFS pool zroot.

Currently, my ThinkPad P52 has 1 NVMe SSD and 1 SATA SSD, so firmware boot menu allows me to choose which drive (actually, which ESP contained in drives), so actually it's enough. But "currently".

Once I'm forced to switch to any other computer, which can only single internal drive available, it suddenly become hazardous.

If the firmware of the new computer is fine enough and handles 100% sanely the boot configs that efibootmgr of FreeBSD creates/edits and everything is running fine, there may be no problem, too.
But when partition to be configured to boot next is somehow broken (mis-updates, new bugs on main, etc), partition for rescue should be chosen on boot. At least, I couldn't find any way to edit detailed boot entries on UEFI firmware on my P52 (possibly overlooking, though).

Usually, for these kind of things, memsticks or external drives would be used, but external ones are often forgotten to take and/or update to at least minimum state to allow rescuering.

By the way, can DHCP specify which "local drive/partition/pool" to boot from? And if yes, can it be specified via UEFI firmware as mandated feature? I'm not familiar with configuring DHCP servers, so I could overlooking something you already know.
 
You must log in or register to reply here.
Back
Top