Date: Thu, 21 May 2026 00:22:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 295463] upgrade to 15.0 p9: booting freezes with "EFI framebuffer information" Message-ID: <bug-295463-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295463 Bug ID: 295463 Summary: upgrade to 15.0 p9: booting freezes with "EFI framebuffer information" Product: Base System Version: 15.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: bob@vesterman.com I recently tried to upgrade from 15.0-RELEASE-p8 (which had been working fine) to 15.0-RELEASE-p9 (which, uh, isn't). I used... -------- freebsd-update fetch freebsd-update install shutdown -r now "Hail Vestertopia!" -------- ... as I have many times in the past for prior upgrades (and as was suggested (well, maybe not the "Hail Vestertopia!" part) by the security advisory). The machine now freezes during boot. Specifically, it gets past decrypting the boot drive (GELI), the boot screen (not sure if that's the right term; I mean where you can select e.g. multi-user mode or single-user mode), "Loading kernel...", "Loading configuration modules...", and "Loading splash ok", but then it freezes after: -------- EFI framebuffer information: addr, size 0xde000000, 0x1d4c00 dimensions 800x600 stride 800 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0x00000000 -------- I waited several minutes (fifteen or so?), and when I came back to it, it was still frozen at the same point. I tried ctrl-C, ctrl-D, and ctrl-alt-delete. None seemed to have any effect. I powered the machine back off and back on. Got the same result. Did it again, but this time selected "single user mode" (having used my normal "multi-user mode" in both earlier reboots). Got the same result. Searching for seemingly similar issues, I found various things in the past. One that seemed of particular interest to my I-Dunno-About-The-Details-Of-Booting brain was bug #209821, "UEFI - installation media hangs when booting on ASUS P6P67 DELUXE". Please note that (A) That's not my motherboard, but (B) the thread contains a bunch of people having the same issue with different motherboards. The bug report is "CLOSED - FIXED", and apparently it was fixed in stable/12 with the following explanation (which is beyond my ken): -------- efi: loader: Inline copy_finish function in amd64 trampoline Instead of calling the efi_copy_finish function from amd64_tramp, include the copy instructions in the trampoline code itself. This avoids boot hangs and restarts in the cases when the efi_copy_finish code happens to be located at a memory location that is overwritten during the copy process. This is a direct commit to stable/12 since no-copy loader mode requires the kernel update not suitable for the branch. -------- It also mentions there that the issue had been fixed in 13 and in HEAD "some time ago". The "tramp" stuff in that message makes me realize that there was something about "tramp" immediately before the "EFI framebuffer" stuff (which is also beyond my ken): -------- Staging 0x6ea00000 (not copying) tramp (0x6e9ff000 PT4 0x6e9f6000) Start @ 0xffffffff80387000 ... Loading splash ok -------- Any help would be appreciated. If there's any additional information I may be able to provide that might help, please let me know. Thanks. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-295463-227>