On Sat, Dec 27, 2025 at 09:46:41PM +0100, Kirill A. Korinsky wrote: > On Fri, 26 Dec 2025 15:34:07 +0100, > Crystal Kolipe <[email protected]> wrote: > > > > If nobody with the affected hardware has the resources, (serial console), or > > knowledge to supply that information then at least it would be useful to > > have: > > > > * a dmesg from a regular booting kernel with monitor attached > > * a dmesg from a regular booting kernel without monitor attached > > * a dmesg from the ramdisk kernel with monitor attached > > > > Also, what happens when a monitor is plugged in to the crashed system, I.E.: > > > > * boot bsd.rd without a monitor connected > > * wait two or three minutes > > * connect monitor and observe not only if there is output or not, but > > whether > > the monitor even gets sync, (I.E. whether there is any valid signal on the > > display connector). > > > > Here the thread where I shared example of it: > https://marc.info/?t=176200344600002&r=1&w=2
Ah, right, I remember casually reading that thread last month :-). So resuming: The issue has already been identified and it is indeed that no console attaches for two reasons: * RAMDISK doesn't include the same set of drivers that GENERIC does. * Efifb which is included sees fb_addr == 0 as set by the firmware, which has not allocated a framebuffer because there is no EDID data from a monitor. As a result, efifb doesn't connect. Creating a dummy console device, (for example, in the style of Xvfb), is undesirable because you have to deal with the fact that it can't provide input, and work around that limitation in a way that doesn't introduce other issues, although in practice from my work on wscons, I don't see any obvious reason why it would immediately break due to the lack of input capability. In the past this whole situation was uncommon because VGA hardware or emulation was usually present on most hardware, so failing anything else the VGA driver was basically always available. Thinking further: Quite possibly the pre-boot environment on your hardware is using uefi text mode with a fixed scan rate regardless of what monitor is connected, (or indeed not connected). Unfortunately, whilst uefi text mode is conceptially similar to VGA text mode, it's a boot service and as such is not usable after calling ExitBootServices() which would prevent a kernel driver being written to use it. However there are other uefi boot services which allow manipulation of the EDID data, (including presenting completely fake EDID data), and re-initialising the graphics hardware. Presumably the 'correct' or 'intended' way to fix this at a firmware level is for the bootloader, (or other UEFI program), to do this manipulation and allow a framebuffer to be allocated, then the efifb kernel driver, (and indeed any other OS that subsequently boots), sees a real framebuffer connected to a virtual monitor.
