We previously installed boot1.efi as EFI/boot/bootx64.efi in the ESP (on amd64), later changing to installing EFI/freebsd/loader.efi and setting EFI variables to make that bootable. Although this change is correct, it introduces some new boot failure cases. I encountered this just now, after a failed laptop mainboard. After the tech replaced the mainboard FreeBSD did not boot from the NVMe device as the EFI variables did not make it to the nvram on the new board. For greenfield ESP installations perhaps we can install loader.efi also as EFI/boot/bootx64.efi, or install a startup.sh that loads EFI/freebsd/loader.efi.
This is samewhat similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247845#c0. I'd to point it the special meaning of EFI/boot/bootx64.efi.
(In reply to Michael Osipov from comment #1) That looks like a similar problem from the opposite side. My issue here is that, at least when using ZFS from the installer, we have _only_ EFI/freebsd/loader.efi and an EFI variable referencing it.
(In reply to Ed Maste from comment #2) Correct, with UFS it is worse, nothing is set at all. I wasted hours for this, but learned a lot about UEFI and FreeBSD ;-)
(In reply to Michael Osipov from comment #3) Did UFS mode still install it as EFI/boot/bootx64.efi?
https://reviews.freebsd.org/D26428
(In reply to Ed Maste from comment #4) Yes, it did.
D26428 was closed (2020-10-09) with reference to workaround <https://bsdimp.blogspot.com/2020/10/how-to-recover-from-bios-upgrade.html> (2020-10-06) > Warner's Random Hacking Blog: How to Recover From a BIOS Upgrade and <https://github.com/freebsd/freebsd-src/commit/c6d56081c9dca474130c0b34c39451b21c55102f> c6d56081c9dc Initial support for implementing the bootXXX.efi workaround
> CURRENT Reproducible with 13.2-RELEASE, 14.0-BETA2, or 15.0-CURRENT? emaste@ close this as a duplicate of bug 247845, or vice versa?
This has been fixed.