boot1.efi has no longer been used in FreeBSD 12 as UEFI bootloader

« FreeBSD's "cp" doesn't copy extended attributes (in FreeBSD 12 currently)

How to boot a FreeBSD system in any partitions with loader.efi »

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 (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 (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. (Corresponding commit.) It seems that these implementations are now work-in-progress, so there is 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.

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.