From nobody Thu May 21 22:34:22 2026 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gM3B46vmlz6f88P for ; Thu, 21 May 2026 22:34:36 +0000 (UTC) (envelope-from polarian@polarian.dev) Received: from mail.polarian.dev (mail.polarian.dev [IPv6:2001:8b0:57a:2385::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gM3B36Tmsz3kRv for ; Thu, 21 May 2026 22:34:35 +0000 (UTC) (envelope-from polarian@polarian.dev) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=polarian.dev header.s=polarian header.b=fCJw1aai; dmarc=pass (policy=reject) header.from=polarian.dev; spf=pass (mx1.freebsd.org: domain of polarian@polarian.dev designates 2001:8b0:57a:2385::8 as permitted sender) smtp.mailfrom=polarian@polarian.dev DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=polarian.dev; s=polarian; t=1779402864; bh=U3YdMtc+EV0oFQ9ZW/TR4EUnrn9cP61G6diF7zfeuRc=; h=Date:From:To:Subject; b=fCJw1aai5rnkzbIzkwBwHdHx2nJtGcIyr4NNy67z5kA5zxoohrpy8X50yaJ6uo1e7 aBe6qhQLBkJXrl2NhY2TmkD1faaMdXJMhwXDwo6Ep2PJgrJSOth7H4RnMTknr8Xu03 A2ygh4511FYC8/j97ZSQqqCiddDwS/MKCTKCs9vM= Date: Thu, 21 May 2026 23:34:22 +0100 From: Polarian To: freebsd-questions@freebsd.org Subject: Terminal server with consumer hardware Message-ID: <20260521233422.001d364f@Hydrogen> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; amd64-portbld-freebsd15.0) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[polarian.dev,reject]; R_SPF_ALLOW(-0.20)[+ip6:2001:8b0:57a:2385::8]; R_DKIM_ALLOW(-0.20)[polarian.dev:s=polarian]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20712, ipnet:2001:8b0::/34, country:GB]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[polarian.dev:+] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gM3B36Tmsz3kRv 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=3D"YES" boot_multicons=3D"YES" console=3D"comconsole" comconsole_speed=3D"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 =E2=80=9Ccomconsole=E2=80=9D. The default port is COM1 with a= n 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, --=20 Polarian Jabber/XMPP: polarian@icebound.dev