Bug 247845 - FreeBSD 12.⋯ does not boot when UEFI bootvar entry does not exist in NVRAM
Summary: FreeBSD 12.⋯ does not boot when UEFI bootvar entry does not exist in NVRAM
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 12.1-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Warner Losh
URL:
Keywords: loader, needs-qa, uefi
Depends on:
Blocks:
 
Reported: 2020-07-08 10:50 UTC by Michael Osipov
Modified: 2024-01-23 11:40 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Osipov 2020-07-08 10:50:30 UTC
I'll try to be as detailed as possible:
I have a Fujitsu CELSIUS W410 which has M/B D3062-A13 by Fujitsu. The fireware version is up to date: V4.6.4.0 - R1.29.0 (18.06.2015). Yes, the machine is old. I have unplugged all drives which still contain Windows to avoid any issues during installation/boot.
The firmware config is set to UEFI mode only, no CSM, no ATAPI. Pure new mode. Downloaded FreeBSD-12.1-STABLE-amd64-20200702-r362880-memstick.img and wrote to a stick with Rufus. The firmware properly shows it as "UEFI: <stick name>". The FreeBSD EFI loader comes up and I am can install the system.
I have selected Auto (UFS) on the 60 GB SSD, bsdinstall created ESP, ufs for / and swap. Reboot the system, nothing happens. ESP DOES contain the default loader, but not picked up by the system. After some digging I have found: https://forums.freebsd.org/threads/cant-boot-on-uefi.68141/#post-406138. efibootmgr -v does not show any bootvar in NVRAM. Strage. Added manually one, the system started to boot, even "gop list" works.
Tried FreeBSD-13.0-CURRENT-amd64-20200702-r362853-memstick.img, installed the same way with UFS, there is a bootvar in NVRAMm, it has been created automatically.
After some search I have found: https://github.com/freebsd/freebsd/blob/master/usr.sbin/bsdinstall/scripts/bootconfig#L151-L152 which does not exist fo 12-STABLE: https://github.com/freebsd/freebsd/blob/4df7391aa971ab3c1ac672de3eb5ed72a384b58f/usr.sbin/bsdinstall/scripts/bootconfig#L38-L39

My understanding is that FreeBSD 12 relies on the default fallback loader while the UEFI implementation of my M/B does not locate it on disk although this one has been selected for boot. I guess my firmware is buggy, but FreeBSD 12 does not know about that. Since 12 is the latest and greatest for the years to come, I expect some better handling: either an explicit bootvar or or warning that the fallback might not always work on all systems. Others will trip with way less knowledge to dig into.
Comment 1 Michael Osipov 2020-07-08 10:52:39 UTC
I have just found: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1366546/comments/1

If this is correct, FreeBSD fails to create the entry and thus being non-UEFI compliant.
Comment 2 Warner Losh freebsd_committer freebsd_triage 2023-08-18 16:43:22 UTC
I'm pretty sure that now that we have efibootmgr support, this is no longer a bug (at least in 13 and newer). I think with 13 we even set it right in the installer. Is this still an issue?
Comment 3 Michael Osipov 2023-08-18 18:42:01 UTC
(In reply to Warner Losh from comment #2)

I need to verify this with a new image of 12 and 13, give me a couple of weeks. I need to plugin a separate SSD for this.
Comment 4 Warner Losh freebsd_committer freebsd_triage 2023-09-18 07:30:58 UTC
Bootloader not standards
Comment 5 Warner Losh freebsd_committer freebsd_triage 2024-01-13 16:04:19 UTC
12 is no longer supported, and there were no further updates on this bug. If it is still happening, please open a new bug. I cannot recreate this.
Comment 6 Michael Osipov freebsd_committer freebsd_triage 2024-01-23 11:40:13 UTC
(In reply to Warner Losh from comment #5)

Let's make it so.