Some questions about the "new" console and the boot loader

From: Patrick M. Hausen <hausen_at_punkt.de>
Date: Thu, 25 Sep 2025 16:56:43 UTC
Hi all,

I had hoped to meet Warner in Zagreb to discuss this over a beer which I would
have happily paid for, or even some more, but he did not make it.

Ever since FreeBSD 14 a certain hardware platform that we rent at Hetzner showed
this irritating and extremely difficult to debug problem:

- Hetzner does not support FreeBSD directly, but they do not prevent you installing it
  and they accept hardware related tickets without a fuss about "supported OS" or anything.
  So that's good.

- Boot into the Debian rescue system and load the "depenguinator" for installation.
  Works great.

- Reboot the system with FreeBSD. System does not come up - "no ping".

- Reboot into Linux rescue, import zpool, triple check installation, reboot.
  No worky.

- Ask Hetzner for an IP KVM - which they provide on demand. System boots immediately.
  WTF? Continue with installation, close support tickt, thank them for KVM, all good.

- Weeks later reboot because of updates - "no ping".

- Connect KVM - instant boot.


You probably guess where this is leading. Those boards don't have a serial port, neither
a physical one nor IPMI and serial over IP. They have an onboard HDMI connector
instead of VGA.

And when nothing is plugged into that HDMI port they seem to deactivate the onboard
"VGA" completely. I cannot tell, because the systems don't boot without a monitor connected.

So now we had them plug these tiny "HDMI emulators" into every system and they
boot reliably.

This is what the running FreeBSD thinks is the graphics adapter:

vgapci0: <VGA-compatible display> port 0xe000-0xe0ff mem 0xfce0000000-0xfcefffffff,0xfcf0000000-0xfcf01fffff,0xf6700000-0xf677ffff at device 0.0 on pci15

vgapci0@pci0:15:0:0: class=0x030000 rev=0xc9 hdr=0x00 vendor=0x1002 device=0x164e subvendor=0x1002 subdevice=0x164e
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Raphael'
    class      = display
    subclass   = VGA

So my educated guess is

- There is no graphics adapter when no monitor or "dongle" is connected.

- Our boot loader doesn't like it for a reason when there is no console at all.


During the last round of updates I even found a proof that it *is* the loader and
not the kernel. I booted into a new BE configured to boot *once*. The system hung. I had
Hetzner connect a KVM and the system booted into the *new* BE. Hence the loader
never made it into even touching the BE at the first attempt without the KVM connected.


I browsed the source a bit and found "nullconsole". Now that looks promising.

Questions:

- console="foo,bar" without multicons - will they be tried in turn?

- Our default is still "vidconsole", right? Yet kenv claims my system has console=efi

- What is the difference?

- Some docs have the entries comma separated, some space separated - which is it?

- I'd love to have a single "failproof" entry for all our machines, so what happens when I
  set console="efi" and the system does a legacy boot?

- Or will "vidconsole" fall back to "efi" when the system boots that way? Seems to be the case
  for the system in question.

- Is that idea above possible? Like console="comconsole,vidconsole,efi,nullconsole" and the
  first one found will be used? I don't need multicons, I only need one console for every
  system that has one and a reliable boot for the systems that absurdly don't.


Kind regards and thanks in advance,
Patrick

P.S. Greetings from Zagreb!
-- 
punkt.de GmbH
Patrick M. Hausen
.infrastructure

Sophienstr. 187
76185 Karlsruhe

Tel. +49 721 9109500

https://infrastructure.punkt.de
info@punkt.de

AG Mannheim 108285
Geschäftsführer: Daniel Lienert, Fabian Stein