Bug 219957 - FreeBSD Install freeze using UEFI
Summary: FreeBSD Install freeze using UEFI
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Many People
Assignee: Konstantin Belousov
Keywords: regression, uefi
Depends on:
Reported: 2017-06-13 16:24 UTC by col
Modified: 2022-05-28 05:24 UTC (History)
16 users (show)

See Also:
koobs: mfc-stable13+
koobs: mfc-stable12-


Note You need to log in before you can comment on or make changes to this bug.
Description col 2017-06-13 16:24:12 UTC
When using any FreeBSD v11-12, Install freezes after the following

>> FreeBSD EFI boot block
Loader path: /boot/loader.efi

Initializing modules: ZFS UFS
Probing 7 block devices.......*... done
ZFS found no pools
UFS found 1 partituion
Consoles: EFI Consoles <Freezes here 

Never gets to the Beastie Logo

Tried multiple newer Dell system models which fully support UEFI. Tried many other distro's such as LinuxMint, Ubuntu, debian, Windows 8, Windows 10 all work fine on a UEFI install. Legacy mode and Secure Boot turned off. Install works fine in legacy mode. Even tried installing in legacy mode and as soon as I try to boot UEFI, it freezes in the same place.

Also tried adding set gop 0,set mode 0, set mode 3, or set kern.vty=sc to loader.conf. Still freezes.

Please help with this.
Comment 1 Ed Maste freebsd_committer 2017-06-14 14:22:00 UTC
Can you please provide the model numbers and UEFI firmware versions of the systems you've tested?
Comment 2 col 2017-06-14 15:17:23 UTC
Systems tested that do not boot FreeBSD UEFI are, with the BIOS rev, Dell Optiplex 3010SFF(A17), 7010SFF(A25), 7010Desktop(A25), and 9010SFF(A26)
Comment 3 col 2017-06-14 15:25:17 UTC
One other note. I have been able to boot only the 7010 desktop intermittently, but only if I load default settings, turn off legacy boot, disable the internal NIC PXE, and do not have any PCIe NIC cards installed. Same procedure has no effect on the SFF's. The SFF's have never been able to boot FreeBSD in UEFI mode, but boot all other OS's just fine. Subsequent boots on the desktop sometimes also freeze.
Comment 4 zheilbron 2017-07-21 21:24:01 UTC
I'm also facing the same symptom.

I have multiple drives attached to my system, two of which are bootable and another that is a data drive. When I unplug the data drive, the system boots normally.

The result of booting (with or without the data drive attached) are the same when using a USB stick with the FreeBSD image and using an internal ZFS-on-root device (aka it's probably not an issue with the loader configuration).

I spent a little bit of time trying to debug the issue. It appears that the EFI loader hangs while trying to init the ZFS device in the device switch (/usr/src/sys/boot/efi/loader/{main.c,conf.c}) -- aka when the ZFS device's dv_init is called.
Comment 5 zheilbron 2017-07-23 08:54:59 UTC
Minor update with some more evidence:

I managed to get the system to boot with the other HDD attached. Apparently there was a GPT partition table on this HDD. Removing this table allowed the system to boot normally.

Unfortunately, I didn't inspect the details of the table before removing it. I still don't know the root cause of the problem.
Comment 6 col 2017-07-24 18:27:57 UTC
After install is complete using GPT and ZFS, I am able to manually boot in UEFI mode by selecting from the boot menu. Automatic boot only works in legacy mode. And doing an install of FreeBSD only works in legacy mode.
Comment 7 nibon7 2017-08-05 08:33:52 UTC
This also happens on Thinkpad E431,but I can boot with legacy mode.
Comment 8 David O'Rourke 2017-09-01 10:46:25 UTC
I was encountering this on a Lenovo Thinkpad X250 with version 1.26 (N10ET47W) UEFI firmware (the latest as I write this), with the freeze occurring in the same place as the original post.

It just so happened that this laptop had had FreeBSD installed before and that  the old ZFS label was still on the SSD. The loader.efi seemed to be finding this old ZFS label and freezing when it couldn't do anything with it (the filesystems it referred to no longer existed).

My fix for this was to boot something that could use the zpool pool and `zpool labelclear -f <dev>`. The loader.efi for the installer would then start properly.

After a new install of FreeBSD when there was a proper ZFS on the SSD, the installer worked correctly.
Comment 9 col 2017-09-01 15:34:11 UTC
I have the same issue with a fresh install of FreeBSD with or without ZFS. Install only works in legacy mode. All other Linux and Windows based installs work fine in UEFI mode. 

In a nutshell, there is something in the boot process that FreeBSD does that is not supported by all UEFI BIOS'es. Or FreeBSD expects something from the BIOS that no other distro does.

All Dell UEFI xx10 and xx20 Optiplex systems seem to be affected. Probably more models as well. Don't expect Dell to fix it just for FreeBSD when every other OS works fine. FreeBSD needs to fix this compatibility issue.
Comment 10 col 2017-09-01 15:45:13 UTC
The problem must be something that FreeBSD expects to happen during a UEFI boot.
I setup FreeBSD in legacy mode with ZFS and GPT. After a successful install, I can manually boot in UEFI mode from the drop down F12 menu and select the UEFI device
 and I must have the Legacy option ROM turned on in the BIOS. If I try to auto boot to UEFI it hangs before the beastie logo. If I turn the legacy option ROM off, auto or manual UEFI booting hangs before the beastie logo.

So, the only way UEFI booting works is if I turn on the legacy option ROM and manually boot to the UEFI drive.

Whatever FreeBSD is waiting for, causing the hang, needs to be addressed.
Comment 11 Avery 2018-07-11 12:35:19 UTC
This happened on my machine with the 11.1-RELEASE memstick image. I resolved it by disabling UEFI networking in the BIOS menu. (Turning on IPv4 and IPv6 alone isn't enough - the whole networking feature needs to be off.)
Comment 12 La_Bela 2018-07-11 16:30:49 UTC
I have the same problem with a Dell Optiplex 7010 (BIOS A28) UEFI on, Secure Boot off. I tried to install FreeBSD-11.2-RELEASE-amd64-memstick with no luck.
Comment 13 col 2018-07-11 16:39:58 UTC
FreeBSD will not install in UEFI mode on any 3010,7010, or 9010 Dell computer.
Been trying for a long time and devs never responds to this issue because they don't have a clue what to do. I tried FreeBSD 10, 11, and 12 with no luck.
But any other Linux distro and Windows installs fine.
Comment 14 Yuri Victorovich freebsd_committer 2018-09-29 23:56:27 UTC
see also bug#230090
Comment 15 Warner Losh freebsd_committer 2018-10-09 21:39:17 UTC
I'm guessing that we're dereferencing a null pointer or jumping into a NULL pointer. No clue which one, though.
Comment 16 Ming-Yuan Yu 2018-10-22 00:15:46 UTC
My Dell Optiplex 7010, with the latest BIOS (A29), has the exact same problem. It boots with Windows and Ubuntu. Interestingly it also boots with FreeNAS 11.1, which is based on FreeBSD 11.1.
Comment 17 col 2018-10-22 19:45:41 UTC
I have been working with Android x86 and that works fine with UEFI boot. So far the only OS I have NEVER been able to boot UEFI on a Dell Optiplex x010 is FreeBSD. They should fix it.
Comment 18 harryruhr 2020-08-01 08:45:38 UTC
Still not working with install media for FreeBSD 12.1, still hangs at the "EFI Consoles" stage.

However, a UEFI install of GhostBSD 20.04.1 worked. After that I installed FreeBSD in legacy mode on the Partition created by GhostBSD, et voila, I can boot FreeBSD with UEFI using the GhostBSD EFI loader.

Now, what does GhistBSD differently?
Comment 19 z84976 2020-08-18 11:42:58 UTC
To add to this, on OptiPlex 3010, bios A10 and now A22, same thing.
With UEFI enabled in bios, I get the boot block message.
However, with boot set in bios to Legacy, if I do an F12 during boot and select the SSD as UEFI, it boots fine.  That's the only way it will boot, which technically works but is unworkable in the event of system restarts, as it requires manual intervention every time.
Comment 20 David Sebek 2021-05-28 15:57:50 UTC
I was able to locate and fix the problem on my machine. See Bug 209821 for more information and a proposed patch.
Comment 21 Ed Maste freebsd_committer 2021-10-05 17:56:01 UTC
This should be fixed in main and stable/13. I would appreciate it if anyone who has encountered this issue can test a 13.x or 14.x snapshot.

For main / 14.x any snapshot from Sept 2021 or later should have the fix:

commit 6032b6ba9596927aba15a8004ade521a593a7d58
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Tue Aug 10 04:38:55 2021 +0300

    amd64 UEFI loader: enable automatic disable of staging area copying
    Discussed with: emaste
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 month

For stable/13 / 13.x need a snapshot after the change was merged Oct 1:

commit caaf4ae21e0600844aa723f87c57dcff37c27a39
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: Tue Aug 10 04:38:55 2021 +0300
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: Fri Oct 1 03:32:24 2021 +0300

    amd64 UEFI loader: enable automatic disable of staging area copying
    (cherry picked from commit 6032b6ba9596927aba15a8004ade521a593a7d58)
Comment 22 Graham Perrin 2022-05-16 00:42:21 UTC
(In reply to Ed Maste from comment #21)

> This should be fixed in main and stable/13. …

Now close as fixed? 

Release note

From <https://www.freebsd.org/releases/13.1R/relnotes/#boot-loader>: 

> UEFI boot is improved for amd64. The loader detects whether the 
> loaded kernel can handle the in-place staging area (non-copying 
> mode). The default is copy_staging auto. Auto-detection can be 
> overridden, for example: with copy_staging enable, the loader 
> will unconditionally copy the staging area to 2M, regardless of 
> kernel capabilities. Also, the code to grow the staging area is 
> more robust; for growth to occur, it’s no longer necessary to 
> hand-tune and recompile the loader. (Sponsored by The FreeBSD 
> Foundation)

Hats off to Konstantin Belousov for this great improvement to FreeBSD, and to the Foundation for sponsorship. 


Comment 23 Ed Maste freebsd_committer 2022-05-16 16:05:20 UTC
Fix is included in 13.1
Comment 24 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-17 00:49:29 UTC
^Triage: Assign to committer that resolves and track branch merge.

Note: Original report was for 11-12. If an MFC to stable/12 is possible, please re-open issue and set mfc-stable flag to ? until merge.
Comment 25 Graham Perrin 2022-05-28 05:24:37 UTC
(In reply to Kubilay Kocak from comment #24)

> … If an MFC to stable/12 is possible, …

Whilst I can not speak for kib@, I suspect that the situation here (bug 219957) is the same as the situation summarised at bug 209821 comment 74 (2022-01-09): 

>> … we cannot do more for stable/12. …