(In reply to Ed Maste from bug 209821 comment #54) Re: <https://forums.freebsd.org/posts/545215> (2021-12-04) it may be that <https://cgit.freebsd.org/src/commit/?h=stable/13&id=1b33aa1f5f99e1270d526ffa5b652250ec80a7efhttps://cgit.freebsd.org/src/commit/?h=stable/13&id=1b33aa1f5f99e1270d526ffa5b652250ec80a7ef> is not effective in stable/13 with these key points: * ASUS Prime B560-Plus and iGPU * FreeBSD-13.0-STABLE-amd64-20211125-354988ca3f9-248228-memstick * mounted the EFI partition and copied /boot/loader.efi to /EFI/BOOT/BOOTx64.efi … ---- Reporting by Graham Perrin on behalf of Nemo1024 in FreeBSD Forums.
> * mounted the EFI partition and copied > /boot/loader.efi to > /EFI/BOOT/BOOTx64.efi … This happens automatically as part of the installation, so I suspect that the loader from FreeBSD-13.0-STABLE-amd64-20211125-354988ca3f9-248228-memstick to an existing system. If that is the case it's not going to work, the fix needs both the loader and kernel.
(In reply to Ed Maste from comment #1) that should be, "so I suspect that this report describes copying the loader from FreeBSD-13.0-STABLE-amd64-20211125-354988ca3f9-248228-memstick..."
Oh, more details from the forum post: > I installed the system from > FreeBSD-13.0-STABLE-amd64-20211125-354988ca3f9-248228-memstick as 13.0-RELEASE > ... After all was set up, I mounted the EFI partition and copied > /boot/loader.efi to /EFI/BOOT/BOOTx64.efi there, thereby making the system > bootable both in CSM and EFI modes. so the install was done in CSM mode and loader.efi was copied to support UEFI boot. > After the FreeBSD boot screen, the system displayed the framebuffer information > and froze all output to the screen, while silently continuing with the boot > process. After a few second I could SSH into the system. So the issue here is independent of the 2M staging copy, as the system does boot correctly.
Thank you. I needed expert @freebsd.org eyes to summarise, and maybe read between the lines, in this case (another forum user reporting "the exact same issue" at <https://forums.freebsd.org/posts/545290>). (In reply to Ed Maste from comment #3) > … the issue here is independent of the 2M staging copy, as the system > does boot correctly. Now, I believe so. My current view of what was reported: * as FreeBSD-13.0-STABLE-amd64-20211125-354988ca3f9-248228-memstick did boot in CSM on the ASUS Prime B560-Plus with discrete NVIDIA graphics * so stable/13 should also boot with the ASUS Prime B560-Plus in pure UEFI mode (more specifically: boot progress beyond EFI framebuffer information appearing on screen) -- and if **beyond that point** there's a graphics-related issue with either the iGPU or discrete NVIDIA, then it's _not necessarily_ Bugzilla keyword 'uefi'; we should edit the summary line appropriately; _not_ an edge case akin to bug 209821. This assumes _not_ manually copying any boot-related file. ---- At this point I should probably drop kib from the cc list, if I have the Bugzilla privilege to do so. There's a little more, which I should keep separate from this comment …
I can not remove names from the cc list. Sorry, kib. (In reply to Graham Perrin from comment #4) > … a little more, which I should keep separate … For anyone who's curious: bug 255072 comment 11, bug 255073 comment 26.
(In reply to Graham Perrin from comment #4) I am the original poster from the forums. I want to clarify a few points. > so the install was done in CSM mode and loader.efi was copied to support UEFI boot. Correct. If I attempted to install without CSM, I would experience an apparent screen freeze after the EFI framebuffer information. I had to resort to using a discreet video card to be able to enable CSM. Once the install was performed (with manual partition creation), I set up the EFI partition and removed the nVidia card from the system, thus booting the newly-installed system in UEFI mode. > so stable/13 should also boot with the ASUS Prime B560-Plus > in pure UEFI mode (more specifically: boot progress beyond > EFI framebuffer information appearing on screen) This was, sadly, not the case. To reproduce, it is enough to boot from the memstick in non-CMS mode on that system. If need be, I can test a newer memstick or a fix candidate, to see if I manage to go past the EFI framebuffer information screen.
> another forum user reporting "the exact same issue" That one is using 13.0-RELEASE and so is expected. > This was, sadly, not the case. To reproduce, it is enough to boot from the > memstick in non-CMS mode on that system. From your report (switching to UEFI loader after install) I believe that the system does boot in UEFI mode, but without working video. Is it possible that this is the same case with memstick, or is the observable behaviour different? (e.g., screen cleared in one case and not the other, or similar?) Of course it may not be possible to determine that the memstick has booted to the installer (without video). A useful datapoint would be to try booting the most recent -current snapshot on the same hardware.
> Of course it may not be possible to determine that the memstick has booted to the installer (without video). Actually, there is a way: After the boot wait for a few minutes, then press <Tab>, <Tab>, <Enter> This will launch "Live CD". Type root <Enter> to drop into the command prompt. This can be done blindly. Then try to enter the command reboot <Enter> If the host reboots, then the system was operational. I just tried this with success in a VM and then attempted to repeat it on the hardware using the latest memstick FreeBSD-13.0-STABLE-amd64-20211223-b30e760ce73-248689-memstick.img First of all, there is still no video output with the screen connected to an HDMI or Display Port past the "EFI framebuffer information". Second, the blind test described above did not give any result - the machine did not reboot. It does, however, respond to <Ctrl-Alt-Del>. An interesting aside, if I connect a really old 1024x768 VGA LCD monitor to the VGA port and boot into the already-installed system, then after a while the mouse pointer appears on the screen, and then, after another minute a legible text login prompt appears as well. However, nothing, not even the boot option screen or the POST screen are shown on the VGA display prior to that point. On the other hand, a newer display connected to the HDMI or Display Port will show both POST and the FreeBSD Boot options, but then nothing past EFI framebuffer information. So this is indicative of problems with video mode switching and the detection of display capabilities/resolutions. And booting into memstick using that old VGA LCD monitor did not produce any output to the screen at any point, however long I waited.
I am also experiencing this issue, on ASUS PRIME B560M-A (BIOS version 1203 - the latest) with the 13.0-STABLE-amd64-20211223 snapshot. I also tried 14.0-CURRENT-amd64-20211223, which progresses beyond the "EFI framebuffer information" message and draws the cursor and mousepointer - the same behaviour described for 12.3-RELEASE in https://forums.freebsd.org/threads/framebuffer-issues-with-asus-prime-b560-plus-and-igpu-without-csm-on-12-3-13-bug-260735.83096/#post-543784. For what it's worth, I updated the BIOS to latest version (1203). As a consequence of this issue, I am unable to install FreeBSD on my system. I am happy to test experimental builds or configurations or provide additional information to help resolve this issue.