After an update to 25.1, the serial console is no longer interactive, i.e. I see the output during the boot process, but I cannot log in. There is no prompt, the output stops at 'lo=: link state changed to UP'. It seems that there is a bug in version 25.1. Another person in the german forum reported a simillar issue (https://forum.opnsense.org/index.php?topic=45531.msg227723#msg227723).
The interactive serial console worked for years up to version 25.1. Now no interaction is possible.
My console settings are as follows:
Console
Console driver
- [y] Use the virtual terminal driver (vt)
Primary Console
- Serial Console
Secondary Console
- VGA Console
Serial Speed
- 115200
USB-based serial
- [n] Use USB-based serial ports
Console menu
- [n] Password protect the console menu
Hi there,
yesterday I made the same experience.
I tried to update my PC Engines APU.1D4 Board running for years with OPNSense to 25.1
Update via Web Interface didn't finish after 2 hours.
I tried a new install with the 25.1 nano edition.
The system booted, but the serial interface stopped sending at a specific point. I wasn't able to do anything from the serial interface.
Same with the serial edition.
After hours of trying I switched back to 24.7 using the serial edition to directly import my backuped configuration.
This worked.
I won't touch the 25.1 until there is a fix.
My upgrade to 25.1 (from a 24.7 serial console) worked well on a 2013 Deciso AMD machine. For me it's just the effect with the serial interface in 25.1 that you described.
I've had similar issues on a Protectli FW6Br2. I tried updating from the console and after the update never received a login prompt. After that I tried to run opnsense off of a live USB, and had the same issue there as well. At this point is seems like the serial version of opnsense is broken.
There is no general issue with serial console operation is what I can assure you from extensive QA testing, but aging hardware mileage may vary as FreeBSD likes to subtly change things around serial consoles and these changes are hard to pin down since they are likely not well-documented either.
Link to open bug report for further reference: https://github.com/opnsense/src/issues/236
Cheers,
Franco
Well, this indeed has been broken upstream. Try with something like
hint.uart.0.at="isa"
hint.uart.1.at="isa"
Setting this in /boot/device.hint from
hint.uart.0.at="acpi"
hint.uart.1.at="acpi"
to
hint.uart.0.at="isa"
hint.uart.1.at="isa"
fixed the problem for me. I wonder if this file will be overwritten with the next update? I am not very familiar with FreeBSD. Can it be made permanent for my hardware in the OPNsense GUI in System/Settings/Tuneable?
Might be even the next reboot, not just update. So yes, using the tunables GUI is the way to override those values.
I added the values to tuneables and rebooted. Serial is still working and /boot/device.hints does still have "isa" and "hint.uart.0.at". I will cross check with and without tuneables.
So current FreeBSD is not supporting older hardware anymore?
FreeBSD does support your hardware. With the tunables added. That's just configuration - the default has changed to EFI console.
Setting those tunables fixed the issue for me, and I was able to upgrade from the console. However the live CD installer still does not work for me because of this issue. I've seen it mentioned that this is because BSD 14.2 assumes ACPI COM ports by default instead of ISA COM ports, and potentially doesn't properly detect which ones are in use. Is this considered a bug in BSD, and is there a way to make the live installer work for hardware that is affected by this?
It's not considered a bug. You can set these tunables at the loader prompt even when booting the installer medium. Apparently there is no method of failsafe auto detect, so FreeBSD defaults to current widely available and used hardware.
APU are ... like ... *really* old architecture. And they *are* still supported, you just need to take one extra step.
Sounds good! I did some more exploring and determined that the way you can set those tunables at boot is by interrupting the boot sequence by pressing "space" when prompted, then pressing escape to get to the menu. From there the "show" command can be used to list tunables and the "set" command can be used to update them, in case anybody else was struggling with this. With these steps I am able to boot from the live USB and have serial console support.
Quote from: Patrick M. Hausen on February 06, 2025, 08:48:18 AMFreeBSD does support your hardware. With the tunables added. That's just configuration - the default has changed to EFI console.
Yes, you are right.
Also seeing this on Protectli V1410. Will try the tunables, thanks
Quote from: estebang on February 07, 2025, 03:00:06 PMAlso seeing this on Protectli V1410. Will try the tunables, thanks
I wouldn't think you'd see this here...that uses the FT232RQ-QFN32 (https://ftdichip.com/products/ft232rq/) UART.
I'm running the old FW2B and have no serial console issues.
Ok, interesting. I'll check if makes any difference over the weekend if I can get to the site
Just heard from Protectli support that they have been able to reproduce the issue and it's a different one all together, though similar effect. Essentially related to the coreboot bios. The workaround they suggested is to flash back to AMI bios for the time being
Quote from: estebang on February 07, 2025, 07:09:43 PMJust heard from Protectli support that they have been able to reproduce the issue and it's a different one all together, though similar effect. Essentially related to the coreboot bios. The workaround they suggested is to flash back to AMI bios for the time being
I have the V1410 also. Thanks for posting- I'll follow for updates. Hopefully they issue a coreboot update soon.
Prior to seeing this thread I tried to upgrade to 25.1 from a USB flashed with Rufus, using the OPNsense 'serial' image. I was not able to get the USB drive listed in the boot menu at all, whereas I did not have that issue with 24.7. I guess there must also be something new with 25.1 boot images that coreboot doesn't like (?) Did you have to do anything special to boot the installer?Edit: I was finally able to get the USB drive seen in the boot menu of coreboot. Don't know what the issue was, but it worked after several attempts. I do also now get stuck on the "lo=: link state changed to UP" line as the OP, so indeed this affects the N5105 Vaults as well.
I successfully upgraded my ancient APU2D4 (with serial port console) on my home network.
THANK YOU for the fix provided in this discussion thread! Otherwise, the upgrade would have caused some panic for me when the console would have stopped working.
In Tunables, I simply added hint.uart.0.at = isa (and hint.uart.1.at = isa). This added the settings to /boot/loader.conf and superceded the values in /boot/device.hints. Just for completeness, I updated the values in /boot/device.hints after the upgrade.
The upgrade from 24.7.12_4 to 25.1 was smooth. THANK YOU, Franco!
On a side note, I will start investigating new hardware for my firewall. That's a discussion for the Hardware and Performance forum.
Good evening,
I have the same problem with the "Protectl FW6Bi"....
If I enter the commands hint.uart.0.at="isa" and hint.uart.1.at="isa" in Tunables, I see the complete start but then I have no access to the selection menu with the keyboard.
I can neither get into the "boot menu" with "F11" nor into the BIOS with "delet" when starting. Does anyone have any other ideas?
Many thanks
By chance, did you verify that hint.uart.0.at="isa" (& hint.uart.1.at="isa") were in /boot/device.hints before upgrade? To verify that "isa" is the correct value?
Also, was hint.uart.0.at="isa" (& hint.uart.1.at="isa") in /boot/loader.conf after you added the values in Tunables and saved?
If the upgrade worked correctly, there is the possibility that the web interface is working. Did you try to connect to web interface?
For me, watching the console simply confirmed that the upgrade worked.
IF the web interface is working, you could possibly go to System:Settings:Administration and enable Secure Shell.
Login with Secure Shell and you should be able to manually edit/boot/device.hints and check that hint.uart.0.at="isa" is in /boot/loader.conf
Good Luck!
I ran into this issue with Protectli devices using Coreboot and the 25.1 installer as well. I was able to get the installer working properly by doing the following:
- Spool up FreeBSD VM and attached the installer .img as a second hard drive
- Figure out which device was the .img using gpart list
- Create a directory and mount the device
- Edit the /mnt/directory/boot/device.hints and set hint.uart.0.at="isa" and hint.uart.1.at="isa"
- Un-mount the device, disconnect the .img from the VM and write it out to a USB
I don't know if this was a bad idea or not, but was able to wipe the device from the installer, install 25.1 and import the config backup from a second USB device, and the serial console worked in both the installer and the device itself once the upgrade completed.
I am now using the tunable hint.uart.0.at="isa" on the Protectli V1410, which does get serial working again. However three odd new behaviors are observed in PuTTY (my serial terminal of choice) on Windows that were not there in 24.7:
1) The COM connection randomly fails with "Error 5: Access is denied." When this happens I have to keep re-trying until I get success.
putty_error.png
2) I can no longer paste my password into the PuTTY terminal on the login prompt. I have to manually type out the Unix password else I get "Login incorrect". This is a pain because I use randomly generated strong passwords that I keep in a password safe and don't type from memory, though fortunately I can do most things in SSH.
3) The text renders a lot more slowly than it did before, even though the baud rate (115200) isn't changed in PuTTY. It used to be smooth but now I can watch as each individual line of text fills in. Not terrible, but a notable difference.
Aside from this, I have a positive update from Protectli tech support that a coreboot update is in the works (ETA >1 month) to address serial initialization and any other updates that they think might be needed for recent & upcoming FreeBSD kernels.