Messages

You cannot apply CPU microcode updates from inside a VM at all. Installing the plugin is nonsense vor virtualised systems. The hypervisor host must do this.

Thanks for clarifying this. My point was that this os-cpu-microcode-intel plugin hasn't caused any issues from 23.1 to 26.1 until now with 26.7 where it completely broke the update process and forced to recover the system from backup.

I have same issue right after os-cpu-microcode-intel-1.1 update

Opnsense is running on top of the latest Proxmox version 9.2.4, using SeaBIOS and UFS2 filesystem.

Why not let Proxmox handle it ?!

Had to restore Opnsense VM from backup taken just before upgrade since this failed upgrade messed up system completely. After removing os-cpu-microcode-intel-1.1 plugin before the upgrade the upgrade went without issues. Yes Proxmox now handles the microcode update. This os-cpu-microcode-intel plugin had been installed maybe to 23.1 Opnsense and haven't caused any issues before this 26.7 upgrade.

opnsense.c0urier.net mirror seems to have broken packages-26.7-amd64.tar for 26.7 upgrade. Tried multiple times but every time same failure.

Code Select Expand

***GOT REQUEST TO UPGRADE***
Currently running OPNsense 26.1.11_10 (amd64) at Sun Jul 19 13:42:17 EEST 2026
Fetching packages-26.7-amd64.tar: ... failed, signature invalid
***DONE***

I have same issue right after os-cpu-microcode-intel-1.1 update

Code Select Expand

Reinstalling os-cpu-microcode-intel-1.1...
[22/392] Extracting os-cpu-microcode-intel-1.1: .. done
Reloading firmware configuration
failed waiting for configd (doesn't seem to be running)
failed waiting for configd (doesn't seem to be running)
failed waiting for configd (doesn't seem to be running)
failed waiting for configd (doesn't seem to be running)
Opnsense is running on top of the latest Proxmox version 9.2.4, using SeaBIOS and UFS2 filesystem.

Most likely this was not related to 25.7.11_1 update but changes in IDS configuration I had done right after the update. Finally today I restored the Opnsense VM from the backup taken before 25.7.11_1 update and updated the VM then to latest 25.7.11_2 and now all good so far.

I was able to isolate this issue to WebGUI Dashboard. When I have shell open at the same time when I login to WebGUI and tens of php processes starts to spawn I then run killall php from the shell and then go to some other part of the WebGUI without any issues. So there is something in the Dashboard itself or in my particular Dashboard view which gets Opnsense to go haywire.

I managed to update to version 25.7.11_2 by using opnsense-shell and then run restart all the services from shell also.
System remains stable. No exessive disk writes, normal memory consuption and regular CPU load.

But still immediately after I open the WebGUI the systems goes haywire. Tens and then hundreds of PHP processes spawn and system runs out of memory.

Hi,

System is fully functional and stable after reboot if I don't open the WebGUI. So clean start and staying away from management keeps the load and memory consumption in similar levels what were before the 25.7.11_1 update. Is it sure that my case is connected to this Neighbors: Automatic Discovery feature?

I've updated from 25.7.10 to 25.7.11_1 yesterday. It's now impossible to access WebGUI because after the login screen when dashboard starts loading the UI spawns hundreds of PHP processes which causes system load to raise above 100 and after few minutes sytem runs out of memory and also consumes all the allocated swap space finally killing the network traffic completely.

System recovers from the situation after closing the WebGUI browser tab but it might take 30-60 minutes when all the PHP processes are finished and memory consumption and system load returns back to normal values.

I'm having this exactly same issue as Shoresy described.

Immediately when I switch the gateway to WAN Gateway Group it console is flooded with these

Code Select Expand

arpresolve: can't allocate llinfo for <WAN IPv4> on igc1 / igc2 messages.

For me it looks that <WAN IPv4> it mentions in interface igc1 llinfo message is the default WAN gateway for igc2 and similarly <WAN IPv4> it mentions in interface igc2 llinfo is the default WAN gateway for igc1.

In my case both WAN interfaces igc1 and igc2 get the IP configurations from two different ISPs DHCP servers.