• RE: Some questions about the "new" console and the boot loader

    From Mark Millard@marklmi@yahoo.com to muc.lists.freebsd.stable on Thu Sep 25 12:30:41 2025
    From Newsgroup: muc.lists.freebsd.stable

    Patrick M. Hausen <hausen_at_punkt.de> wrote on
    Date: Thu, 25 Sep 2025 16:56:43 UTC :
    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:

    . . .
    I did some looking around for the status vs. the
    documentation and there appears to be no documentation
    in the man pages mentioning "eficom" that was added in
    mid 2023. For:
    # uname -apKU
    FreeBSD 7950X3D-ZFS 16.0-CURRENT FreeBSD 16.0-CURRENT main-n280598-57d5a8feda3f GENERIC-NODEBUG amd64 amd64 1600000 1600000
    (official pkgbase from on 2025-Sep-24) the search
    for eficom and the results are:
    # man -K eficom
    #
    So this console handling subject area may well be one
    needing consultation with Warner instead of reading man
    pages.
    In case you want to look, the eficom commits to
    main are from:
    QUOTE
    author Warner Losh <imp@FreeBSD.org> 2023-05-11 20:03:17 +0000
    committer Warner Losh <imp@FreeBSD.org> 2023-05-11 20:06:03 +0000
    commit 2f131435bc22540db2d3f6bf97e5f9fe7039f889 (patch)
    tree 6dbcc069a318165f9827ca21f1ef5b631187b796
    parent 86c31aca33ff771b845acbbed3b3659fde7e710f (diff)
    stand: efi create eficom console device.
    . . .
    END QUOTE
    through:
    QUOTE
    author Kyle Evans <kevans@FreeBSD.org> 2023-05-28 18:50:46 +0000
    committer Kyle Evans <kevans@FreeBSD.org> 2023-05-28 18:54:50 +0000
    commit 9ed4ec4ae34a9ecab0471f1dbf392729155d7411 (patch)
    tree b47b4755066ec1e404c85a9aa36c8ed51bbd1f01
    parent 697727110b68e483c320d834bcbcdf01c01142a1 (diff)
    stand: libefi: avoid a null pointer deref in eficom
    . . .
    END QUOTE
    For reference:
    # ~/fbsd-branches-containing.sh 2f131435bc22540db2d3f6bf97e5f9fe7039f889
    * main
    releng/14.2
    + releng/14.3
    + stable/14
    remotes/freebsd/HEAD -> freebsd/main
    remotes/freebsd/main
    remotes/freebsd/releng/14.0
    remotes/freebsd/releng/14.1
    remotes/freebsd/releng/14.2
    remotes/freebsd/releng/14.3
    remotes/freebsd/stable/14
    ===
    Mark Millard
    marklmi at yahoo.com
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mark Millard@marklmi@yahoo.com to muc.lists.freebsd.stable on Thu Sep 25 14:41:57 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Sep 25, 2025, at 12:30, Mark Millard <marklmi@yahoo.com> wrote:
    Patrick M. Hausen <hausen_at_punkt.de> wrote on
    Date: Thu, 25 Sep 2025 16:56:43 UTC :

    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:

    . . .

    I did some looking around for the status vs. the
    documentation and there appears to be no documentation
    in the man pages mentioning "eficom" that was added in
    mid 2023. For:

    # uname -apKU
    FreeBSD 7950X3D-ZFS 16.0-CURRENT FreeBSD 16.0-CURRENT main-n280598-57d5a8feda3f GENERIC-NODEBUG amd64 amd64 1600000 1600000

    (official pkgbase from on 2025-Sep-24) the search
    for eficom and the results are:

    # man -K eficom
    #


    So this console handling subject area may well be one
    needing consultation with Warner instead of reading man
    pages.


    In case you want to look, the eficom commits to
    main are from:


    QUOTE
    author Warner Losh <imp@FreeBSD.org> 2023-05-11 20:03:17 +0000
    committer Warner Losh <imp@FreeBSD.org> 2023-05-11 20:06:03 +0000

    commit 2f131435bc22540db2d3f6bf97e5f9fe7039f889 (patch)
    tree 6dbcc069a318165f9827ca21f1ef5b631187b796
    parent 86c31aca33ff771b845acbbed3b3659fde7e710f (diff)

    stand: efi create eficom console device.
    . . .
    END QUOTE

    through:

    QUOTE
    author Kyle Evans <kevans@FreeBSD.org> 2023-05-28 18:50:46 +0000
    committer Kyle Evans <kevans@FreeBSD.org> 2023-05-28 18:54:50 +0000

    commit 9ed4ec4ae34a9ecab0471f1dbf392729155d7411 (patch)
    tree b47b4755066ec1e404c85a9aa36c8ed51bbd1f01
    parent 697727110b68e483c320d834bcbcdf01c01142a1 (diff)

    stand: libefi: avoid a null pointer deref in eficom
    . . .
    END QUOTE


    For reference:

    # ~/fbsd-branches-containing.sh 2f131435bc22540db2d3f6bf97e5f9fe7039f889
    * main
    releng/14.2
    + releng/14.3
    + stable/14
    remotes/freebsd/HEAD -> freebsd/main
    remotes/freebsd/main
    remotes/freebsd/releng/14.0
    remotes/freebsd/releng/14.1
    remotes/freebsd/releng/14.2
    remotes/freebsd/releng/14.3
    remotes/freebsd/stable/14

    If my git repository had been more up to date, then
    remotes/freebsd/stable/15 would have shown up as
    well.
    ===
    Mark Millard
    marklmi at yahoo.com
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Warner Losh@imp@bsdimp.com to muc.lists.freebsd.stable on Sun Sep 28 15:12:42 2025
    From Newsgroup: muc.lists.freebsd.stable

    --0000000000006b0474063fe2fb1c
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 25, 2025 at 10:57=E2=80=AFAM 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 "supporte=
    d
    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 seria=
    l
    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=3D0x030000 rev=3D0xc9 hdr=3D0x00 vendor=3D0x10=
    02
    device=3D0x164e subvendor=3D0x1002 subdevice=3D0x164e
    vendor =3D 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device =3D 'Raphael'
    class =3D display
    subclass =3D 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 a=
    t
    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=3D"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=3Defi


    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 - whic=
    h
    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=3D"efi" and the system does a legacy boot?


    We use console=3D"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=3D"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=3Dyes wouldn't be se=
    t,
    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=C3=A4ftsf=C3=BChrer: Daniel Lienert, Fabian Stein



    --0000000000006b0474063fe2fb1c
    Content-Type: text/html; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25,=
    2025 at 10:57=E2=80=AFAM Patrick M. Hausen &lt;<a href=3D"mailto:hausen@pu= nkt.de">hausen@punkt.de</a>&gt; wrote:<br></div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex">Hi all,<br>

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

    Ever since FreeBSD 14 a certain hardware platform that we rent at Hetzner s= howed<br>
    this irritating and extremely difficult to debug problem:<br>

    - Hetzner does not support FreeBSD directly, but they do not prevent you in= stalling it<br>
    =C2=A0 and they accept hardware related tickets without a fuss about &quot;= supported OS&quot; or anything.<br>
    =C2=A0 So that&#39;s good.<br>

    - Boot into the Debian rescue system and load the &quot;depenguinator&quot;=
    for installation.<br>
    =C2=A0 Works great.<br>

    - Reboot the system with FreeBSD. System does not come up - &quot;no ping&q= uot;.<br>

    - Reboot into Linux rescue, import zpool, triple check installation, reboot= .<br>
    =C2=A0 No worky.<br>

    - Ask Hetzner for an IP KVM - which they provide on demand. System boots im= mediately.<br>
    =C2=A0 WTF? Continue with installation, close support tickt, thank them for=
    KVM, all good.<br>

    - Weeks later reboot because of updates - &quot;no ping&quot;.<br>

    - Connect KVM - instant boot.<br>


    You probably guess where this is leading. Those boards don&#39;t have a ser= ial port, neither<br>
    a physical one nor IPMI and serial over IP. They have an onboard HDMI conne= ctor<br>
    instead of VGA.<br>

    And when nothing is plugged into that HDMI port they seem to deactivate the=
    onboard<br>
    &quot;VGA&quot; completely. I cannot tell, because the systems don&#39;t bo=
    ot without a monitor connected.<br>

    So now we had them plug these tiny &quot;HDMI emulators&quot; into every sy= stem and they<br>
    boot reliably.<br></blockquote><div><br></div><div>I have several machines = w/o a monitor connected at all. If the boot loader isn&#39;t liking yours, = it&#39;s likely the EFI firmware that&#39;s being picky.</div><div>=C2=A0</= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex">
    This is what the running FreeBSD thinks is the graphics adapter:<br>

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

    vgapci0@pci0:15:0:0: class=3D0x030000 rev=3D0xc9 hdr=3D0x00 vendor=3D0x1002=
    device=3D0x164e subvendor=3D0x1002 subdevice=3D0x164e<br>
    =C2=A0 =C2=A0 vendor=C2=A0 =C2=A0 =C2=A0=3D &#39;Advanced Micro Devices, In=
    c. [AMD/ATI]&#39;<br>
    =C2=A0 =C2=A0 device=C2=A0 =C2=A0 =C2=A0=3D &#39;Raphael&#39;<br>
    =C2=A0 =C2=A0 class=C2=A0 =C2=A0 =C2=A0 =3D display<br>
    =C2=A0 =C2=A0 subclass=C2=A0 =C2=A0=3D VGA<br>

    So my educated guess is<br>

    - There is no graphics adapter when no monitor or &quot;dongle&quot; is con= nected.<br>

    - Our boot loader doesn&#39;t like it for a reason when there is no console=
    at all.<br></blockquote><div><br></div><div>This isn&#39;t a general thing=
    , but there might be some set of circumstances that leading your setup to c= rash w/o the monitor that I can&#39;t for the life of me think of at the mo= ment.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg= in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=

    During the last round of updates I even found a proof that it *is* the load=
    er and<br>
    not the kernel. I booted into a new BE configured to boot *once*. The syste=
    m hung. I had<br>
    Hetzner connect a KVM and the system booted into the *new* BE. Hence the lo= ader<br>
    never made it into even touching the BE at the first attempt without the KV=
    M connected.<br>


    I browsed the source a bit and found &quot;nullconsole&quot;. Now that look=
    s promising.<br>

    Questions:<br>

    - console=3D&quot;foo,bar&quot; without multicons - will they be tried in t= urn?<br></blockquote><div><br></div><div>They will all be tried, in turn, b=
    ut all the ones that succeed will be used.</div><div>=C2=A0</div><blockquot=
    e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex">
    - Our default is still &quot;vidconsole&quot;, right? Yet kenv claims my sy= stem has console=3Defi<br></blockquote><div><br></div><div>For BIOS, the de= fault is vidconsole. For EFI it&#39;s efi. It&#39;s a big mistake that we d= idn&#39;t try to have the EFI environment be the same as BIOS. We started w= ith the &#39;efi&#39; console instead. And then hacked it from the &#39;any= thing that supports output text&#39; to include video/graphics support. At = that time we should have, honestly, created an efivideo=C2=A0and an efiseri=
    al to replace efi (or rather, EFI would revert back to just using the simpl=
    e text protocol via whatever device the firmware thinks is the console). ef= ivideo would be like vidconsole, etc. But there&#39;s issues with doing tha=
    t. tl;dr: we created a mess years ago, and haven&#39;t fixed the mess yet.<= /div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
    0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    - What is the difference?<br></blockquote><div><br></div><div>Today, one is=
    BIOS only, the other is EFI only.</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">
    - Some docs have the entries comma separated, some space separated - which =
    is it?<br></blockquote><div><br></div><div>Doesn&#39;t matter. Officially, =
    I think it&#39;s comma separated, but we accept both separators.=C2=A0</div= ><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
    0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    - I&#39;d love to have a single &quot;failproof&quot; entry for all our mac= hines, so what happens when I<br>
    =C2=A0 set console=3D&quot;efi&quot; and the system does a legacy boot?<br>= </blockquote><div><br></div><div>We use console=3D&quot;efi,vidconsole&quot=
    ; at work and put up with the warnings when one isn&#39;t available.</div><= div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
    px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    - Or will &quot;vidconsole&quot; fall back to &quot;efi&quot; when the syst=
    em boots that way? Seems to be the case<br>
    =C2=A0 for the system in question.<br></blockquote><div><br></div><div>I do= n&#39;t think it does. vidconsole isn&#39;t initialized in EFI. I don&#39;t=
    think we have a fallback console.</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">
    - Is that idea above possible? Like console=3D&quot;comconsole,vidconsole,e= fi,nullconsole&quot; and the<br>
    =C2=A0 first one found will be used? I don&#39;t need multicons, I only nee=
    d one console for every<br>
    =C2=A0 system that has one and a reliable boot for the systems that absurdl=
    y don&#39;t.<br></blockquote><div><br></div><div>All of them found would be=
    used, though boot_multicons=3Dyes wouldn&#39;t be set, so -D wouldn&#39;t =
    be passed to the kernel.</div><div><br></div><div>Warner</div><div>=C2=A0</= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex">
    Kind regards and thanks in advance,<br>
    Patrick<br>

    P.S. Greetings from Zagreb!<br>
    -- <br>
    <a href=3D"http://punkt.de" rel=3D"noreferrer" target=3D"_blank">punkt.de</=
    GmbH<br>
    Patrick M. Hausen<br>
    .infrastructure<br>

    Sophienstr. 187<br>
    76185 Karlsruhe<br>

    Tel. +49 721 9109500<br>

    <a href=3D"https://infrastructure.punkt.de" rel=3D"noreferrer" target=3D"_b= lank">https://infrastructure.punkt.de</a><br>
    <a href=3D"mailto:info@punkt.de" target=3D"_blank">info@punkt.de</a><br>

    AG Mannheim 108285<br>
    Gesch=C3=A4ftsf=C3=BChrer: Daniel Lienert, Fabian Stein<br>

    </blockquote></div></div>

    --0000000000006b0474063fe2fb1c--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2