Bug 219957
| Summary: | FreeBSD Install freeze using UEFI | ||
|---|---|---|---|
| Product: | Base System | Reporter: | col |
| Component: | misc | Assignee: | Konstantin Belousov <kib> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | 0mp, attila.laszlo, bcran, dasebek, dor.bsd, emaste, freonmonkey, grahamperrin, hjensen, i.dani, imp, kib, nibon7, tn00364361, z84976, zheilbron |
| Priority: | --- | Keywords: | regression, uefi |
| Version: | CURRENT | Flags: | koobs:
mfc-stable13+
koobs: mfc-stable12- |
| Hardware: | amd64 | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821 | ||
Can you please provide the model numbers and UEFI firmware versions of the systems you've tested? Systems tested that do not boot FreeBSD UEFI are, with the BIOS rev, Dell Optiplex 3010SFF(A17), 7010SFF(A25), 7010Desktop(A25), and 9010SFF(A26) 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. 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.
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. 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. This also happens on Thinkpad E431,but I can boot with legacy mode. 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. 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. 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. 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.) 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. 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. see also bug#230090 I'm guessing that we're dereferencing a null pointer or jumping into a NULL pointer. No clue which one, though. 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. 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. 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? 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. I was able to locate and fix the problem on my machine. See Bug 209821 for more information and a proposed patch. 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) (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. <https://www.freebsd.org/status/report-2021-07-2021-09/#_improved_amd64_uefi_boot> <https://freebsdfoundation.org/blog/2021-in-review-software-development/> Fix is included in 13.1 ^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. (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. … |
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. Thanks