Messages

We need to fix that bug in the boot loader. I am quite a bit disappointed the issue in the tracker has not got any attention. In March a volunteer intending to fix the problem asked for some information - no response so far.

I'll raise some "management attention" in a week ;-)

Kind regards,
Patrick

Hi Patrick,

Thank you so much for bringing this up and pushing for a fix! It's great to know that the issue is being looked into.

Please let me know if I can assist in any way, whether by providing logs or testing a patch/build on my system.

Best regards,
Fabian

I have the same hardware and same problem. Mine is running Manjaro Linux because its my Linux desktop.
I think it makes no difference which OS is installed, because it had this problem also with other OS installed.
Mine also have a display attached all the time, which makes me think it could be a genereal bios or hardware problem.
For me its just a power-off and power-on if it fails to boot and it cames back with 99% success after that.

No, this is not my experience. I just downloaded the latest Ubuntu ISO and tried to boot into the live environment (installer) multiple times without any problems. After plugging in the monitor to check if it worked, the installer was visible a few seconds later.

I don't think these Lenovo mini PCs have a general problem with headless booting, since I see them used all over YouTube for homelab projects.

Does your problem occur every time or, like mine, only occasionally?

Unfortunately, this seems to be an OPNsense bootloader problem, even though I would like to spare the OPNsense maintainers the trouble...

Did you try setting the primary console to serial and the secondary to none as I already advised?

Yes, I tried that setting as suggested, but unfortunately, it didn't solve the issue. I suspect this workaround only applies when the system fails to boot altogether. In my case, it's just inconsistent, it boots fine about 3 out of 4 times, but occasionally gets stuck.

That makes it really difficult to isolate the cause, as the behavior is fairly stochastic. Sometimes it works 5 to 6 times in a row, leading me to believe it's fixed, only for it to fail on the next attempt. It's tough to troubleshoot under these conditions.

[Unfortunately, I have to retract my statement regarding the monitor state conclusion.]

Unfortunately, I have to retract my statement regarding the monitor state conclusion.

The system still occasionally hangs during boot. As I gathered from the boot logs in /var/log/system/, when the system hangs, it doesn't even write to these logs, meaning the kernel is not loaded yet. It must be a bootloader issue. Unfortunately, I don't know how to log bootloader output (or if that's even possible), so it's not really possible to determine the root cause of these hangs.

I just ordered a few HDMI dummy plugs to make the system more reliable, as I cannot afford to have it go down after a power outage.

However, I am still interested in solving this problem at a fundamental level rather than relying on this band-aid fix.

Any suggestions are much welcome!

I mean, you can configure OPNsense as a WireGuard client using a configuration provided by Surfshark:

Surfshark: How to set up a manual WireGuard connection

Then, follow the appropriate guide to configure your firewall as a WireGuard client:

OPNsense: 
WireGuard Selective Routing to an External VPN Endpoint

pfSense: 
WireGuard VPN Client Configuration Example

However, this will only create a standard VPN tunnel. I'm not sure what additional features Surfshark offers, but with this setup, you would only be using the VPN connection itself.

[if I boot with a monitor attached, unplug it, and then restart or shut down, the system hangs on the next boot.]

First of all, thanks for all the replies. For now, the issue seems to be "resolved".

Here is what I noticed: if I boot with a monitor attached, unplug it, and then restart or shut down, the system hangs on the next boot. It seems like the system expects the monitor to still be there, though I might be wrong. Performing a forced shutdown resolves the issue on the following start.

This only occurs when booting with a monitor and shutting down without one. Hot-plugging the monitor while the system is running does not affect the boot process.

My previous confusion was likely caused by a mix of these scenarios, which made the behavior seem inconsistent and hard to reproduce reliably. In the end, I just wasn't connecting the dots regarding the system's prior state (booted with or without monitor).

This might be common knowledge, but I wanted to share my findings just in case it helps someone else. I still don't know the exact cause, but I at least have a workaround.

Yes, a display emulator would be a relatively easy but not a really satisfying fix, but yeah, I will consider this when I run out of options.

Hi,

I'm having a strange boot issue with OPNsense on a Lenovo ThinkCentre M720q Tiny and I'm trying to determine whether this is related to FreeBSD/OPNsense, EFI console handling, or the Lenovo firmware.

Hardware / system:

- Lenovo ThinkCentre M720q Tiny
- Intel Core i5-8400T
- 8 GB RAM
- Toshiba NVMe SSD
- Intel I350-T4 PCIe NIC
- Onboard Intel I219-V
- Intel Dual Band Wireless-AC 8265 (currently unused)
- OPNsense 26.7.3_8
- UEFI boot
- Latest Lenovo UEFI/BIOS installed (the same problem was already present with the previous UEFI/BIOS version, so updating to the latest firmware did not resolve it)

The problem is that the machine sometimes hangs during boot or reboot when running headless.

When a monitor is connected via DisplayPort before powering on/rebooting, the machine appears to boot/reboot reliably. Without a monitor, cold boots and reboots can randomly hang.

When it hangs, OPNsense does not become reachable over the network. Connecting a monitor after the machine has already started/hung does not produce any video output either — the monitor has to be connected before boot for video output to work.

Interestingly, after a failed boot, forcing the machine off and starting it again will often result in a successful headless boot.

After some research, I came across the following article describing a very similar issue with OPNsense systems not booting without a monitor:

https://www.thomas-krenn.com/en/wiki/OPNsense_does_not_boot_without_monitor

Following the recommendation in that article, I changed the console configuration to:

    Primary Console: Serial Console
    Secondary Console: VGA Console

Subjectively, this seemed to make the system somewhat more reliable, although the boot issue was still present. The reboot could still hang; however, in this configuration a short press of the power button was sufficient to shut the machine down from the hung state, whereas previously I sometimes had to hold the button for a forced power-off.

During boots/reboots with a monitor connected, however, I noticed the following messages from the FreeBSD loader:

    no valid consoles!
    console vidconsole is unavailable

The loader also listed the available consoles as:

    Available consoles:
        efi
        eficom
        comconsole
        nullconsole
        spinconsole

Since "efi" was available while "vidconsole" was explicitly reported as unavailable, I changed the configuration again to:

    Primary Console: EFI Console
    Secondary Console: None

With this configuration, the console warnings disappeared completely, and headless reboots also seem to have become more reliable. However, the underlying problem is not completely solved: cold boots without a monitor can still occasionally hang, while other cold boots with exactly the same configuration succeed normally.

Using EFI Console therefore appears to be the more appropriate console configuration for this UEFI system, but I am not yet sure whether the console configuration is actually related to the root cause of the intermittent headless boot issue.

The particularly strange behavior is:

    Monitor connected before boot:
        boot/reboot appears reliable

    No monitor:
        cold boot/reboot may hang
        OR may boot completely normally

    Failed headless boot:
        power off -> another headless cold boot often works

The system is already running the latest Lenovo UEFI/BIOS. The issue also occurred with the previous firmware version, so this does not appear to be a regression introduced by the latest UEFI update.

At this point I have left the console configuration at:

    Primary: EFI Console
    Secondary: None

since this matches the consoles actually provided by the UEFI loader and avoids the "vidconsole is unavailable" warning.

Has anyone seen similar behavior with the Lenovo M720q/M920q or other Intel Coffee Lake systems running FreeBSD/OPNsense?

Any suggestions for further diagnostics would be appreciated. I would prefer to identify where the boot actually stops before randomly changing hardware or loader tunables.

Thanks!