boot1.efi has no longer been used in FreeBSD 12 as UEFI bootloader [のふ処|NOFUDOKORO]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== boot1.efi has no longer been used in FreeBSD 12 as UEFI bootloader ======

It is perceived that boot sequence steps of FreeBSD (x64) in UEFI environment are as below. It is pedigreed process written on manpages.

  - UEFI:/EFI/BOOT/BOOTX64.EFI
    * A UEFI bootloader executed when system starts up.
  - boot1.efi ([[https://www.freebsd.org/cgi/man.cgi?query=uefi&apropos=0&sektion=8&manpath=FreeBSD+12.2-RELEASE&arch=default&format=html|man]])
    * The 1st stage bootloader looking for a freebsd-zfs or freebsd-ufs partition and booting a next stage. The look-up proceeds from a device which the loader is loaded to another ones in order of an UEFI's boot order setting.
  - The final stage bootloader: loader.efi ([[https://www.freebsd.org/cgi/man.cgi?query=loader&sektion=8&apropos=0&manpath=FreeBSD+12.2-RELEASE|man]])
    * A bootloader executing a FreeBSD kernel in the storage specified by an environment variable of ''currdev'' or ''loaddev''.
  - kernel

The UEFI firmware gets BOOTX64.EFI up in EFI system partition. Next it runs the boot1.efi, then the loader.efi is lunched, and finally the kernel boots up.
Actually the process is supposed to move ahead as BOOTX64.EFI -> laoder.efi -> kernel because boot1.efi is copied as BOOTX64.EFI

The reason why I say ambiguously is because, as you know, it is different between the implementation and manpages' description.
It looks like that the loader.efi has been used as BOOTX64.EFI in FreeBSD 12.0-RELEASE. ([[https://github.com/freebsd/freebsd-src/commit/d050cd6b99c0a2056d4d07468b481206a31a5407|Corresponding commit]].) 
It seems that these implementations are now work-in-progress, so there is [[https://github.com/freebsd/freebsd-src/commit/db8b56134506840832bec2d1ce07b9e00d4d6d71|a moderate improved patch]] to generate an ESP.

You can find the same hash values between BOOTX64.EFI and loader.efi when mounting the ESP generated by FreeBSD 12.2-RELEASE installer.

{{ :blog:2021:sha1_loader_efi_and_bootx64_efi.png |}}

So, the final stage bootloader goes straight skipping over the 1st stage in fact.

This way is no problem in most environments, but it probably can't boot the system placed on another storage because the loader.efi seems to only look for system partitions from the storage which it is loaded from.
That's a fine how-do-you-do!

Workaround is to replace the BOOTX64.EFI with boot1.efi or to set ''currdev'' and load the kernel and ''zfs.ko'' manually in bootloader prompt remaining the loader.efi as EFI bootloader.
The former is clearly easier than the latter.

According to source codes of the loader.efi, it looks like the loader can boot the system by an undocumented way. I will try it after.

===== References =====

  * [[https://qiita.com/mzaki/items/76acac14c16ac6789e68|FreeBSDのブートプロセス - Qiita]]
  * [[https://www.babagnu.sh/freebsd-boot-process/|The FreeBSD Boot Process | babaGNU.sh]]
  * [[https://www.ish.org/blog/?p=958|aio boot（その3:rEFIndによるFreeBSDのマルチブート） – Welcome to ish.org]]
  * [[https://github.com/freebsd/freebsd-src/commit/d050cd6b99c0a2056d4d07468b481206a31a5407|Switch to creating UEFI ESPs using loader.efi instead of boot1.efi. · freebsd/freebsd-src@d050cd6]]
  * [[https://github.com/freebsd/freebsd-src/commit/db8b56134506840832bec2d1ce07b9e00d4d6d71|Rework UEFI ESP generation · freebsd/freebsd-src@db8b561]]