Messages

I would the service widget state to look like the Wireguard connection  red for down and green for up.

agree +1

@OPNenthu

Agreed, the NVM version itself probably doesn't directly "cause" the microcode issue. I mentioned it mainly because my boot hangs started right after I updated the i226 firmware, so I was trying to see if there was any pattern.

The reason I updated the i226‑V NVM to 2.32 back then was that the interfaces were flapping a lot. After the firmware update, the flapping completely disappeared. I documented that here:
https://forum.opnsense.org/index.php?topic=48695.195

The fact that you're on 2.13 and I was on 2.32, yet both of us hit boot hangs with the microcode plugin, actually supports your point: it's likely not about the NIC firmware, but about how early microcode loading interacts with the N5105 platform and/or specific BIOS images.

On my box, the practical workaround for now is to keep the microcode plugin removed and wait until the "late load" fix is officially rolled out. If you're okay with a bit more testing, your setup is probably perfect to help validate the fix across different N5105 boxes.

@OPNenthu

Thanks for sharing your logs and screenshots, it's really helpful to see that on very similar hardware (N5105, 4× i226‑V) both the bootloader update and the "late load" steps still result in a boot hang.

Just to connect the dots: my original issue appeared after updating the i226‑V NVM firmware to 2.32 on 26.1.4. With the microcode plugin installed, the box would hang at boot when both WAN and LAN were linked. Removing the microcode plugin fixed it.

Out of curiosity, which NVM/firmware version are your i226‑V NICs currently running?
You can check with:

bash
dmesg | grep -i igc
and look for lines like "EEPROM Vx.xx‑x"

Thanks for the confirmation.

zpool status shows exactly that message:

pool: zroot
state: ONLINE
status: Some supported and requested features are not enabled on the pool.
errors: No known data errors


I have no need for the new features, so I will leave the pool as-is and not run zpool upgrade

@ meyergru

Hi meyergru,

I see how my previous message could sound like "I'll wait for others to test first", and I understand why that comes across as not really helping the thread. That wasn't my intent.

To be clear: on my N5105 box with 4× i226‑V I did hit a concrete problem with the microcode plugin. After updating the i226 NVM to 2.32 and running OPNsense 26.1.4, with os-intel-microcode installed I was getting boot hangs whenever both WAN and LAN were connected (link stayed amber, system seemed stuck, no progress on console). I documented this here in the i226 thread (posts #198–#199) and the issue disappeared after I removed os-intel-microcode.

https://forum.opnsense.org/index.php?topic=48695.msg263682#msg263682

Because of that experience, I'm a bit cautious about re‑introducing any microcode plugin on this primary firewall. I'm absolutely willing to help verify the "late load" fix, but I'm trying to balance testing with not breaking a production device again.

OPNenthu  with very similar hardware (N5105, 4× i226‑V) is now reporting boot stalls after reinstalling the microcode plugin on 26.7. This matches what I experienced on 26.1.4, which is why I'm being cautious about re‑enabling microcode on this box until the "late load" fix is fully validated.

My intention isn't to avoid testing, just to make sure I do it in a controlled way after having already been affected by the early‑load issue on this hardware.

Bottom line: I'm happy to contribute real‑world data on the fix, just please bear with me if I'm a bit more careful than usual on a box that already hung at boot because of microcode.

Hi Patrick and all,

Just to add my experience with microcode on this platform: I'm on an N5105 box with 4× i226‑V. With OPNsense 26.1.4 I had the official os-intel-microcode plugin installed, and I experienced boot hangs when both WAN and LAN were connected (link stayed amber, system seemed stuck, no progress on console). After removing os-intel-microcode, all reboots completed successfully and the issue did not return.

Because of that, I haven't tried any microcode plugin on 26.7/27 yet. From my side, the safe configuration so far has been "no microcode plugin, BIOS handles everything".

If the new "late load" devel packages are meant to address exactly this kind of early‑boot race condition, I'd be interested in testing them, but I'd prefer to wait for the official 26.7.1 / hotfix version before touching microcode again on this box.

Thanks,

Hello nero355,

Thanks for the reply.

The mongodb.so warnings fit exactly with Zenarmor dropping MongoDB in favor of SQLite / newer Elasticsearch. I'll clean up the leftover php83-pecl-mongodb package and run pkg autoremove, then check if the warnings disappear permanently.

About the ZFS warning: I agree it's likely just OpenZFS being updated and reporting newer available features on my existing pool. The pool is online and healthy, and SMART on the SSD is clean, so I'm treating it as informational.

The greyed‑out Services widget seems to be a UI glitch; all services are actually running fine.

If you've seen this combo on other 27 upgrades, any specific cleanup steps beyond removing the mongodb package?

Thanks,

Hello,

After upgrading to OPNsense 27, I initially saw repeated warnings in Firewall > System > Firmware > Reporter, including PHP startup messages about mongodb.so and some other log entries.

However, after letting the system settle and checking again, the firewall is now no longer showing those errors. WAN connectivity, PPPoE, DNS, and the rest of the system are working normally.

At this point, it looks like the issue may have been related to Zenarmor rather than the firewall core itself. Zenarmor is installed on this system and uses a local reporting backend, so it is possible that the reporting database or backend state needed to be updated or reinitialized after the upgrade.

Since the errors have disappeared, I'm not sure whether this was just a transient post-upgrade state, or whether Zenarmor automatically corrected the backend/database on its own.

I also noticed a ZFS pool warning after the firmware upgrade indicating that some supported pool features are not enabled yet. The pool is still online and healthy, and SMART for the SSD is passing, so this appears to be only an informational warning rather than an actual storage problem.

If anyone has seen a similar situation after upgrading to OPNsense 27, I'd be interested in hearing whether this is expected behavior or whether there is something that should still be checked manually.

The Services widget on the dashboard appears greyed out, but all listed services are running normally.

Thanks in advance.

Thanks, Franco! So I can confirm this is the same issue I hit:

First update attempt: log stayed stuck/stacked, firewall rebooted

Second attempt: update succeeded

Since the fix is in the commit you linked and already in 26.1.8, my 26.1.9 should have it, but I still saw the chunked output and reboot. Looking forward to 26.1.10/26.1.11 when the logs return to normal streaming.

Good to know it's tracked and will be resolved!

Thanks for the correction. I shouldn't have used pkg update -f && pkg upgrade or plain reboot.

In my case the upgrade was:

pkg update -f

pkg upgrade

opnsense-update

reboot

The only non‑recommended parts are the manual pkg usage and direct reboot. The system update was done correctly via opnsense-update.


From now on I'll follow the official upgrade path through the GUI/console and only use opnsense-update plus yes | opnsense-shell reboot if needed from shell.

Updated to 26.1.6 from previous 26.1.5 ; upgrade initially hung in GUI but completed cleanly via CLI (pkg update -f, pkg upgrade, opnsense-update, reboot).

Unbound + dnscrypt-proxy stack fully operational post-upgrade (correct listeners, dig tests OK, dnscrypt query logs PASS).

Firewall/NAT, IPv6 (track6), and WebGUI all behaving as expected so far.

System hostwatch is running correctly after the update and "Automatic Discovery" is enabled on the desired interfaces.
Please double‑check under Interfaces → Neighbors → Discovery that "Automatic Discovery" is ticked and that the correct interfaces are selected, then apply the changes.

Thanks

This is a frequent Unbound DNS issue on OPNsense where allowlists don't take effect immediately due to caching, CNAME redirects, or incomplete propagation after adding domains.

Check Reporting First
Go to Reporting > Unbound DNS > Overview or Details to spot the blocked domain (and any CNAME chain). Click it to whitelist directly—this auto-adds to Services > Unbound DNS > Blocklists > Allowlist Domains.

Use CLI on OPNsense: dig example.com @127.0.0.1 to trace resolutions and whitelist all linked domains.

Clear Cache Properly
In Services > Unbound DNS > General > Advanced, enable Flush DNS cache on restart. Apply changes, then Reload Unbound (full reload, not just cache refresh). Also restart the service via CLI: service unbound restart.

Flush client DNS too (e.g., ipconfig /flushdns on Windows). Test again—exceptions working confirms blocklist config is fine, just needs refresh.

Official Documentation
Full Unbound setup: [docs.opnsense.org/manual/unbound.html]

Reporting guide: [docs.opnsense.org/manual/reporting_unbound_dns.html]

Thanks for the detailed explanation, Cedrik! That GitHub link clears it up perfectly—makes sense why multi-select move isn't there yet with the sequence recalc logic.

A quick workaround I've used: when batch-creating rules in the new interface, set the Sequence field manually on each one right away (e.g., 100, 101, 102) to drop them in the exact order/position you want. No repositioning needed afterward.

Feature request for multi-move would still be nice, though—maybe with a "Move selected block" option that shifts the whole range?

Hey everyone,

I've spotted a limitation in OPNsense's "New Rules" feature (latest stable version): when creating multiple firewall rules in batch from the new Rules section, you can't select them all and use the rule's buttons (Move Up/Down) to reposition them together. It only works one at a time, which gets annoying with a bunch of rules.

Is this a bug ? Anyone found a workaround?

Thanks for the feedback!

I removed the "os-intel-microcode" plugin and, after that, several reboots with both WAN   and LAN   connected have all completed successfully. The previous boot hang with only solid amber on the switch has not reappeared so far.

I'll keep monitoring and report back if the issue returns.