[Bug 214261] [uefi] boostrap hangs
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sun Nov 6 08:26:33 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214261
Bug ID: 214261
Summary: [uefi] boostrap hangs
Product: Base System
Version: 11.0-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: emz at norma.perm.ru
CC: freebsd-amd64 at FreeBSD.org
CC: freebsd-amd64 at FreeBSD.org
Created attachment 176675
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=176675&action=edit
hangup screen
FreeBSD 11.0-RELEASE-p2, generic kernel, Supermicro server (X9SCL-F MB) with a
recent BIOS (v2.2). See the attached screen for details. 100% reproducible.
Boots fine from GPT/MBR. Isn't affected by the hw.vga.textmode.
Furthermore, I cannot make it boot automatically, see my message in the stable@
for details -
https://lists.freebsd.org/pipermail/freebsd-stable/2016-August/085280.html:
"Recently I've installed FreeBSD 10.3 as an experiment to get the
UEFI-enabled system, on one of mine Supermicro servers. The installer
worked just fine, but after insttallation I got myself a problem: it
cannot boot. If I select to boot the old way, froma disk, BIOS says
there's no valid boot device, and I guess i'ts as intended. When I
select to boot to the UEFI shell, I got a listing of valid boot deviced
identificators, and then an error:
===Cut===
'f??('is not recognized as an internal or external command, operable
program or batch file
Exit status code: Invalid parameter
===Cut===
and the booting process bails to the shell itself.
When I enter
===Cut===
fs0:
EFI\BOOT\BOOTX64.EFI
===Cut===
FreeBSD boots just fine, but I would rather see it boots automatically."
as the final attempt to resolve this I've upgraded the installed system to
11.0-p2 (nothing changed) and upgraded it's BIOS from 2.0b to 2.2 (got this
hangup problem). I'm not entirely sure who's problem is that, but FreeBSD
totally lacks any documentation about installing UEFI loaders, so at least this
is worth attention. Still both problems can be caused by the FreeBSD UEFI
support.
Workaround: change to the legacy GPT/MBR bootstrap scheme.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the freebsd-amd64
mailing list