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

On Thu, Sep 25, 2025 at 10:57 AM Patrick M. Hausen <hausen@punkt.de> wrote:

> 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.
>

I have several machines w/o a monitor connected at all. If the boot loader
isn't liking yours, it's likely the EFI firmware that's being picky.


> 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.
>

This isn't a general thing, but there might be some set of circumstances
that leading your setup to crash w/o the monitor that I can't for the life
of me think of at the moment.


> 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?
>

They will all be tried, in turn, but all the ones that succeed will be used.


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

For BIOS, the default is vidconsole. For EFI it's efi. It's a big mistake
that we didn't try to have the EFI environment be the same as BIOS. We
started with the 'efi' console instead. And then hacked it from the
'anything that supports output text' to include video/graphics support. At
that time we should have, honestly, created an efivideo and an efiserial to
replace efi (or rather, EFI would revert back to just using the simple text
protocol via whatever device the firmware thinks is the console). efivideo
would be like vidconsole, etc. But there's issues with doing that. tl;dr:
we created a mess years ago, and haven't fixed the mess yet.


> - What is the difference?
>

Today, one is BIOS only, the other is EFI only.


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

Doesn't matter. Officially, I think it's comma separated, but we accept
both separators.


> - 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?
>

We use console="efi,vidconsole" at work and put up with the warnings when
one isn't available.


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

I don't think it does. vidconsole isn't initialized in EFI. I don't think
we have a fallback console.


> - 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.
>

All of them found would be used, though boot_multicons=yes wouldn't be set,
so -D wouldn't be passed to the kernel.

Warner


> 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
>
>