Terminal server with consumer hardware

[Polarian]

Hello list,

This has been discussed on #freebsd a few times now with no success.

A common reason you don't full disk encrypt servers is because it makes
unattended boot difficult. I believe TPM encryption is now supported
recently but undocumented (correct me if I am wrong), however TPM only
protects against decryption AFTER you dispose of the disks, if they
have the hardware and the disks, its pointless unless paired with
keydisk or passphrase. Keydisk works, but requires you to plug in the
keydisk to boot, making it infeasible to attend a boot remotely. This
leaves passphrase, which is possible to attend a boot remotely provided
you have access.

Loader supports serial, or a KVM. KVM requires graphics, and on my
server there is no integrated graphics, this means powering a graphics
card (extra 10-15w) which if you are running 24/7, is more costly.

This makes serial ideal, its simple, doesn't require much power, and
unlike a KVM, a cheap RPI is all you need.

My setup is a RPI running OpenBSD which is accessible via ssh,
connected to the FreeBSD server by two WinChipHead CH9102/343/341/340
(not sure which exact chip it is) TTL usb adapters, with the rx and tx
soldered together, transitively, a usb to usb serial adapter.

This works flawlessly when getty is configured, apart from my shell
only rendering a few lines, but I assume this might be a limitation of
cu(1) on OpenBSD. It works as an emergency if I get locked out.

The final issue I thought would be simple, get loader to output to
serial, use the serial access through the terminal server to decrypt
the server, call it a day, but after weeks of trying I am on the verge
of giving up.

My config is the following in loader.conf:

# Serial output
boot_serial="YES"
boot_multicons="YES"
console="comconsole"
comconsole_speed="115200"

I read for EFI you need your motherboard firmware to support serial
redirect, so I switched it to bios boot thinking this would be the fix,
but no dice.

I then think that its just not possible, but after looking through all
the loader man pages, I see this in loader.efi(8):

> On x86 platforms, if you wish to redirect the loader's output to
> a serial port when the EFI BIOS doesn't support it, or to a serial
> port that isn't the one the EFI BIOS redirects its output to, set
> console to “comconsole”. The default port is COM1 with an I/O
> address of 0x3f8. comconsole_port is used to set this to a different
> port address.

Alright cool, so it is possible, but I already set the console to
comconsole and it doesn't work, in fact theres nothing until getty is
executed by init.

So I assume the output is wrong, it does mention that comconsole_port
can be specified for this, so I check further down the man page:

> Windows Name I/O Port Address Typical
> FreeBSD device COM1 0x3f8 /dev/uart0
> COM2 0x2f8 /dev/uart1
> COM3 0x3e8 /dev/uart2
> COM4 0x2e8 /dev/uart3

(Format broke due to character limitations in plaintext, however the
point should still be clear)

So /dev/uart is what is listed, with the port addresses, cool but not
what I need. With a USB TTL adapter the device is /dev/ttyU0 however I
am not smart enough to know what the port address is to set it, maybe
someone here can help?

I am also concerned this is limited to only certain serial devices, I
don't know how much logic is implemented within loader, however the
fact you can use keydisk from a USB (haven't managed to get this
working myself, but heard its possible) means that the loader has got
the ability to read usb devices, but I would question if it would have
the device driver for the serial chip, and maybe this is the problem?

In any case, could anyone provide more information on this, the more
indepth the better. I really want to get this working :D

Thank you,
--
Polarian
Jabber/XMPP: pola...@icebound.dev

[Pete Wright]

On 5/21/26 3:34 PM, Polarian wrote:
> Hello list,
>
> This has been discussed on #freebsd a few times now with no success.
>
> A common reason you don't full disk encrypt servers is because it makes
> unattended boot difficult. I believe TPM encryption is now supported
> recently but undocumented (correct me if I am wrong), however TPM only
> protects against decryption AFTER you dispose of the disks, if they
> have the hardware and the disks, its pointless unless paired with
> keydisk or passphrase. Keydisk works, but requires you to plug in the
> keydisk to boot, making it infeasible to attend a boot remotely. This
> leaves passphrase, which is possible to attend a boot remotely provided
> you have access.
>
> Loader supports serial, or a KVM. KVM requires graphics, and on my
> server there is no integrated graphics, this means powering a graphics
> card (extra 10-15w) which if you are running 24/7, is more costly.
>
> This makes serial ideal, its simple, doesn't require much power, and
> unlike a KVM, a cheap RPI is all you need.
>
> My setup is a RPI running OpenBSD which is accessible via ssh,
> connected to the FreeBSD server by two WinChipHead CH9102/343/341/340
> (not sure which exact chip it is) TTL usb adapters, with the rx and tx
> soldered together, transitively, a usb to usb serial adapter.
>

sorry may have missed this, but why not use IPMI and serial-over-lan?
this is pretty much exactly the use-case it was created for, and most if
not all server class motherboards support it.

for systems where i need full-disk encryption of my root volume i'm able
to provide pass key's via remote console, and it allows you to manage
the devices hardware too.

-pete

--
Pete Wright
pe...@nomadlogic.org

[Polarian]

Hey,

> and most if not all server class motherboards support it.

Yeah if it was a server motherboard it would be p*ss easy.

Unfortunately as mentioned in the title "consumer hardware" not "server
hardware" and also within the body of my initial email I highlight
there is no hardware (firmware) support for it.

I originally though this is not possible, but when reviewing
loader.efi(8) it says it is.

So theres really two questions here:

1. Are TTL USB drivers available within loader stage
2. How do I set the console_device to the correct device as all the hex
codes within the man page assume /dev/uartx not /dev/ttyUx.

Thanks,
--
Polarian
Jabber/XMPP: pola...@icebound.dev

[Pete Wright]

On 5/21/26 4:50 PM, Polarian wrote:
> Hey,
>
>> and most if not all server class motherboards support it.
>
> Yeah if it was a server motherboard it would be p*ss easy.

ah i see when i saw you state "A common reason you don't full disk
encrypt servers is because it makes unattended boot difficult." but i
guess if you are using consumer hardware for a server...

-p

--
Pete Wright
pe...@nomadlogic.org

[Marco Moock]

Am 22.05.26 um 00:34 schrieb Polarian:

> This
> leaves passphrase, which is possible to attend a boot remotely provided
> you have access.

Debian solves that by providing Dropbear (a small SSH server) in
initramfs. Are such ways also possible in FreeBSD?

--
Gruß
Marco

Junk-Mail bitte an tras...@stinkedores.dorfdsl.de

[Polarian]

Hey,

> Debian solves that by providing Dropbear (a small SSH server) in
> initramfs. Are such ways also possible in FreeBSD?

No, loader can't do that.

You would usually do this by having 2 installs, one unencrypted, one
encrypted. You would ssh into the unencrypted one to decrypt the
encrypted one.

Never done it myself, not 100% sure how you even set it up.

However I want to get serial working, full stop :)

I don't want to give up on it, so does anyone have an idea how to get
this working?

[infoomatic]

On 22.05.26 16:47, Polarian wrote:

> I don't want to give up on it, so does anyone have an idea how to get
> this working?

You could have a look at
https://forums.freebsd.org/threads/unlock-geli-partitions-at-boot-through-ssh.96395/
and https://github.com/emtiu/freebsd-outerbase

I have my base OS systems unencrypted, but the rest of the disks
encrypted. On startup my script fetches the key from a different system
(my local firewall), decrypts the disk and starts the jails (which are
on the encrypted partition). When my firewall is down (e.g. power loss
in my house) I need to intervene, however, at least I can ssh into those
systems and check the status before decrypting the data.

Regards,
Robert

[Steve Rikli]

On Fri, May 22, 2026 at 03:47:31PM +0100, Polarian wrote:
> ...

> However I want to get serial working, full stop :)
>
> I don't want to give up on it, so does anyone have an idea how to get
> this working?

It's been quite a while since I looked at this, but AFAIK FreeBSD can't
make use of USB serial devices for the system console.

I.e. there must be an actual serial port, recognized by the bios and
presented to the OS. Something like this, if found:

$ dmesg | grep ^uart[0-9]:
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)

The most I was able to work out with a USB serial device (e.g. on an old
Intel NUC without a native serial port) was starting a login: getty on
ttyU*, but that's only a terminal, not a system console.

Similar situation with GRUB on Linux as well, btw. IIRC I was able to
send some boot output to ttyU* there, but it wasn't usable as an
interactive console during GRUB.

IMO it'd be great if there were more support for USB serial devices as
system console, since modern boards often don't have a serial port these
days. I expect it's a tricky problem, doing console input-output to
removable devices early in loader stages.

Cheers,
sr.

[Polarian]

Hey,

> It's been quite a while since I looked at this, but AFAIK FreeBSD
> can't make use of USB serial devices for the system console.

The man pages cause some confusion here then, as freebsd.efi(8)
explicitly state that if you do not have support for it within your
uefi bios, maybe this is just me getting confused.

> I.e. there must be an actual serial port, recognized by the bios and
> presented to the OS. Something like this, if found:
>
> $ dmesg | grep ^uart[0-9]:
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on
> acpi0 uart0: console (115200,n,8,1)

Ah so it must be presented by acpi, in which case this requires
firmware support within the motherboard full stop.

> The most I was able to work out with a USB serial device (e.g. on an
> old Intel NUC without a native serial port) was starting a login:
> getty on ttyU*, but that's only a terminal, not a system console.

Yeah this is pretty easy to do, this is what im doing currently, but it
doesn't help with a FDE encrypted server.

I am starting to think FDE encrypted servers are too much hassle, but
then again they provide good security when it comes to physical
security of data at rest.

The man page still doesn't make sense on this though. I wonder who
would be a good person to ask about it, because if it isn't possible
then surely the man page needs improvements for being misleading or not
clear enough for idiots like me :p

[Steve Rikli]

On Fri, May 22, 2026 at 11:13:22PM +0100, Polarian wrote:
>
> > It's been quite a while since I looked at this, but AFAIK FreeBSD
> > can't make use of USB serial devices for the system console.
>
> The man pages cause some confusion here then, as freebsd.efi(8)
> explicitly state that if you do not have support for it within your
> uefi bios, maybe this is just me getting confused.

I assume you mean loader.efi(8).

While it doesn't specifically say "COM ports only", IMO it essentially
implies that in this table:

Windows Name I/O Port Address Typical FreeBSD device
COM1 0x3f8 /dev/uart0
COM2 0x2f8 /dev/uart1
COM3 0x3e8 /dev/uart2
COM4 0x2e8 /dev/uart3

I dunno if that's the final word though, and it's quite possible things
have changed since I last looked. There might be some hope from settings
like comconsole_pcidev as described in loader_simp(8) but I haven't
tried anything with it.

> > I.e. there must be an actual serial port, recognized by the bios and
> > presented to the OS. Something like this, if found:
> >
> > $ dmesg | grep ^uart[0-9]:
> > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on
> > acpi0 uart0: console (115200,n,8,1)
>
> Ah so it must be presented by acpi, in which case this requires
> firmware support within the motherboard full stop.

With modern hardware it's typically acpi, yes. But I don't think it
necessarily must be; e.g. in older releases and hardware, there were
other default settings in /boot/device.hints for the uarts, something
like:

hint.uart.0.at="isa"

I don't recall when the default changed to "acpi", I think it's been
a while. device.hints(5) talks about format and syntax.

Afaik for console purposes the serial device must have a uart(4),
regardless of origin.

> The man page still doesn't make sense on this though. I wonder who
> would be a good person to ask about it, because if it isn't possible
> then surely the man page needs improvements for being misleading or not
> clear enough for idiots like me :p

I'm no expert at all, a while ago I simply spent a lot time websearching,
reading man pages, and experimenting with an old NUC.

Ultimately I "solved" the situation here by primarily using systems
with a native (built-in) serial port. :-)

[Polarian]

Hey,

> I assume you mean loader.efi(8).

Yeah apologies.

> While it doesn't specifically say "COM ports only", IMO it essentially
> implies that in this table:

True, however if the device has a COM port you would assume it would
have firmware support for it, its a bit pointless shipping a board with
a COM port if it hasn't got firmware for it.

So this is why I still find the paragraph mentioning comconsole
confusing. Yes you could also imply from the name "comconsole" that it
requires a com port.

I am 99.99% sure you are right, and I pretty much predicted this from
when I started this experiment. However the man page provided some
optimism that it would actually be possible, but I think this is just
because its ambiguous.

> I dunno if that's the final word though, and it's quite possible
> things have changed since I last looked.

I doubt it, as I mentioned in my original email, this would require the
loader to load firmware in order to interface with it. If the COM port
is already provided by the firmware as far as I am aware, no device
drivers are needed, and that would explain why loader would require a
COM port.

This isn't the end of the world, as many consumer boards actually still
have a JCOM connector, this is not supported by all motherboards (I
think especially gaming motherboards drop this header in preference to
fit more fan headers and RGB), however desktop orientated boards
(budget options) sometimes still have a JCOM header.

Provided the firmware would support it, it would therefore be feasible
to use a JCOM bracket which would have a DB9 port, this then can be
plugged into the terminal server, provided the driver support is there
(which, as the terminal server is OpenBSD, is a big if :p)

I kinda expected to have to do this once I went from simple serial
backup (in case of network lockout) to remotely accessing the boot. Its
also feasible to drill some holes into the bracket of the adapter, to
run a power switch jumper, and reset jumper through it and then these
can be controlled by gpio on RPI, but thats an issue for another day,
or a cleaner solution, in theory you can adapt the 5v pin on a molex to
a microusb, and then you could run a rpi pico W inside of the case, and
then have this connect to a wifi network, which you can in theory
provide by the RPI with hostap, and then a small program can run which
awaits for a connection and then if it is "RESET" or "POWER" or hell
you could do it in binary (0 for power, 1 for reset) and then the
corresponding gpio are shorted. And as for power draw, the pico W
shouldn't draw more than 0.2W which I don't think is going to run up
your energy bills by a lot. Oh and this has the added benefit of a
single RPI hostap network in theory could serve a whole rack of servers
with pico W in them, although you are limited to 4 USB ports, so 4
serial connections... unless you use a usb hub...

But yeah I really do think the loader.efi(8) man page needs some
clarification, as we don't want more idiots like me getting confused by
it :p

Thanks for the help,
--
Polarian
Jabber/XMPP: pola...@icebound.dev