Date: Mon, 30 Mar 2026 16:03:24 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 288900] loader.efi: System won't boot without kvm or console=comconsole in loader.conf Message-ID: <bug-288900-227-Ysj2Ym6cy4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-288900-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288900 Vidith Hundekar <hundekarvidith@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hundekarvidith@gmail.com --- Comment #2 from Vidith Hundekar <hundekarvidith@gmail.com> --- Hi, I’m Vidith, currently working on the EFI boot counter project as part of GSoC exploration, and while going through the loader and early boot path I came across this issue. I was trying to understand how console initialisation works in loader.efi when no display is attached. >From the description and the follow-up comment, it seems like when no monitor is connected, the firmware may not expose a usable EFI console — no GOP or no usable Simple Text Output Protocol. If loader.efi assumes ConsoleOut is always valid and tries to use it during early initialisation without checking, that would explain the hang or reboot loop, since this is all still happening in the BootServices phase where the loader depends entirely on what the firmware provides. The comconsole workaround seems to support this — it sidesteps EFI console usage entirely and takes a different code path, which is why it works even when there's no serial port physically present. My question is whether loader.efi currently verifies that a valid console handle exists (for example, via HandleProtocol on ConsoleOut) before attempting to use it, or whether it assumes one is always present. If it's the latter, would it make sense for the loader to fall back more gracefully when firmware exposes no console? I'm likely missing some of the finer details of how console selection is handled internally, so any clarification would be helpful. 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-288900-227-Ysj2Ym6cy4>