On Mon, Mar 30, 2026 at 09:06:24AM +0000, Job Snijders wrote:
> On Sun, Feb 08, 2026 at 06:34:50PM +0100, Mark Kettenis wrote:
> > > > > What about my suggestion to have a dummy framebuffer?
> 
> That seems a very useful thing to have.
> 
> > > > I had tried, but I wasn't able make something that works.
> > > > 
> > > > Or better to say all my attemt leads to that machine still hungs.
> > > > 
> > > > Here hard part: this is remote machine, I haven't got access to serial
> > > > console on it, I can only boot it, or boot in "rescue mode" (Linux) or as
> > > > to attach KVM.
> > > > 
> > > > ... and without the way to debug I can't figure out why and where it hangs.
> 
> I have a similar issue on a machine, but fortunately that machine is
> within walking distance.
> 
> > Does the diff below work for you?
> 
> With the below diff, a Minisforum MS-A2 does boot, but only with HDMI
> dummy plugged in...

This is a bit of an apples to oranges comparison, and we're straying away from
the original problem towards other possibly related stuff.

The original documented issue that prompted this thread was that bsd.rd did
not boot without a display connected.  The regular sp and mp kernels did boot.

Obviously during interactive installation using the ramdisk kernel, the user
is almost certainly going to have a display connected, or a serial console.

The issue becomes visible, (excuse the pun), when booting bsd.rd during
upgrades of a machine which has been running headless since after the original
install was completed.

The reason seems to be that:

* Machines without VGA hardware will default to using efifb when booting
  bsd.rd kernel.

* The same machines usually use inteldrm or amdgpu when booting a regular
  kernel.

* The firmware on some of these machines:

  * Looks at the EDID data from a connected monitor.
  * Sets up a framebuffer based on that data.
  * If there is no EDID data, (typically because no monitor is connected),
    then no framebuffer is set up.
  * This doesn't affect the firmware itself, because it can happily use efi
    textmode, (which as I understand it is _required_ by the efi standards).

Your supplied dmesg is of booting bsd.mp, and it's using amdgpu.

If your machine is not booting the _regular kernel_ without a dummy plug
connected, then this is a very different situation and the solution probably
lies elsewhere.