I have made several attempts to install the Opnsense upgrade to 26.7, but every time it gets stuck or hangs on reboot at "masks 0x00ff0000, 0x0000ff00, 0xff000000" I have to power off the system and reboot to the previous snapshot I made before attempting the upgrade to get things working again... Can anyone offer some advice or help that may resolve this issue..?
System Info: Dell Optiplex 7050 with Intel i5-6500, Integrated Intel HD Graphics 530, 16GB Memory, UEFI Boot
AMD Ryzen system with integrated graphics? Try switching to serial console before upgrading. See:
https://forums.freebsd.org/threads/wont-boot-masks-0x00ff0000-0x0000ff00-0x000000ff-0xff000000.79638/
The initial thread is quite old but there are some helpful recent comments at the end.
There is an even bigger problem behind that with 26.7.:
I upgraded and after reboot, saw this on my stalled boot console:
2026-07-15 15_38_00-jetkvm - JetKVM — Mozilla Firefox.png
The "Witty Woodpecker" part is just because that is only updated after a sucessful reboot. But you can see the error message "console vidconsole is unavailable". This now keeps the system from properly booting - it did not do that ever before.
My console settings were "vt" = enabled, primary console = efi, secondary console = VGA console. I did this in case I ever had to boot the disk on a legacy system, while my current one is UEFI. With 26.7, this setting kept the system from even booting. What is worse is that you cannot even use boot environments - at least it did not work for me.
I had to switch the secondary console to serial or none in order to be up and running again. IDK if the vidconsole driver would work on its own. For safety reasons, I switched to EFI console on another UEFI system before doing the upgrade.
This is noteworthy for people who update from remote: Change the console setting before the update!
I updated my original post to include my system specs:
Dell Optiplex 7050 with Intel i5-6500, Integrated Intel HD Graphics 530, 16GB Memory, UEFI Boot
Well ... integrated graphics matches. Try the console settings as suggested by @meyergru.
Primary console: EFI
Secondary console: none
Quote from: Patrick M. Hausen on July 15, 2026, 05:52:02 PMWell ... integrated graphics matches. Try the console settings as suggested by @meyergru.
Primary console: EFI
Secondary console: none
How do I go about doing that..?
System > Settings > Administration > Console
Quote from: Patrick M. Hausen on July 15, 2026, 06:03:22 PMSystem > Settings > Administration > Console
So... My current settings are:
Use the virtual terminal driver (vt) is Checked
Primary Console is set to: VGA Console
Secondary Console is set to: None
So change Primary Console to: EFI Console, and then reboot and try do the upgrade again..?
Yes.
That did not work... It still hangs at masks...
Any other suggestions..?
I finally got the 26.7 upgrade to install. I had to remove the "os-cpu-microcode-intel" plugin and reboot. Then I tried the upgrade again and it worked... I left the "Primary Console" setting I changed previously set to EFI so I am not sure if that even had anything to do with it or not. I may try changing it back to VGA and see what happens... But for now it seems like the "os-cpu-microcode-intel" plugin is what was causing the problem...
Should I try re-installing the "os-cpu-microcode-intel" plugin now that the system has been upgraded or hold off to see if there may be an update to the plugin later on..?
Allegedly this was fixed in late 15.1 RC cycle: https://github.com/opnsense/src/commit/56e59980b67
But since FreeBSD insisted this was a pressing bug for 15.1 and we already seen the same behaviour on 14.x for a long time I'm not even sure that fix is the full story.
So long story short:
> Should I try re-installing the "os-cpu-microcode-intel" plugin
Definitely maybe.
Cheers,
Franco
OK... So I tried enabling the "os-cpu-microcode-intel" plugin again after upgrading to 26.7 and it caused the system to hang on boot again in the same spot "masks"... So I would suggest that if you have this plugin installed that you remove it before attempting the upgrade and don't re-install it afterward...
Thanks for trying! We will suggest removing the microcode package then for others running into similar issues.
Cheers,
Franco
It seems like with the new kernel, there are now race conditions with the early microcode loading under certain conditions. For me, it was the presence of vidconsole (but I did not check if that problem would prevail if the microcode update was disabled - I still have it running).
I think that the recent kernel changes of memory layout and such is responsible for that, although at times, it even surfaced earlier than with 26.7: https://github.com/opnsense/ports/issues/230. Whatever the specific condition is, it seems that the early loading is always part of the problem, so disabling that should fix it.
Alas, since many mainboard manufacturers do not supply microcode updates in the BIOS and it seems there is no way of doing the microcode update even earlier in FreeBSD, there is currently no fix for this situation other than to disable os-cpu-microcode-intel.
P.S.: Doing the update later via cpuctl is a tough decision, because:
1. There is code in the kernel that detects certain features at boot, which might change because of the update and cause problems.
2. Race conditions may occur when the update is being applied while other code executes, which is why the preferred way was early updates in the first place.
BryanC1968, you are the best!!!!!! i almost formatted the firewall for the upgrade :)
Quote from: Wintrob-IT on July 16, 2026, 05:46:58 PMBryanC1968, you are the best!!!!!! i almost formatted the firewall for the upgrade :)
Your Welcome. Glad I could help someone else... I did quite a bit of googling to find a fix for the problem. I found some old forum posts either on this forum or on reddit from someone else having this same issue with one of the previous version upgrades. And they found out that the cpu-microcode plugin was what was causing the issue, so I gave it a try and it worked...
This is the late-loading change Patrick and Uwe have been asking about if anyone wants to try it:
https://github.com/opnsense/plugins/commit/506bbad4
Cheers,
Franco
So instead of creating a new issue I added a comment now :-)
Thanks!
It's not on master, please let me know how this works in practice.
Cheers,
Franco
Encountered this issue as well. Failed to upgrade with multiple attempts. Relied heavily on snapshots to recover.
In my case, I needed to remove plugins: os-cpu-microcode-intel, and os-realtek-re
Was able to successfully upgrade after all plugins were removed. Leaving these plugins uninstalled as I'm not sure they're relevant any longer.
After installing the os-cpu-microcode-intel plugin, there's a notice in the console output that states:
"This port is deprecated. Abandoned upstream, fails to identify anything remotely new according to upstream issue reports. It is scheduled to be removed on or after 2025-06-30."
Didn't reinstall the os-realtek-re plugin because I already have the FreeBSD realtek-re-kmod package installed. This is to provide support dual Realtek RTL8125 2.5GbE network adapters in the MeLE Quieter DL mini PC. The package automatically updated to the latest version with the upgrade to FreeBSD 15.
Hope this additional info is helpful.
Quote from: sAnDs on July 16, 2026, 11:11:39 PM"This port is deprecated. Abandoned upstream, fails to identify anything remotely new according to upstream issue reports. It is scheduled to be removed on or after 2025-06-30."
This message refers to a port that is installed as an upstream dependency but not even used by the os-cpu-microcode-intel plugin. This is not the cause of your issue. And it will just go away, eventually.
What seems to be causing all sorts of boot time freezes is the early loading of the microcode updates. Franco and team are working on it.
Quote from: Patrick M. Hausen on July 16, 2026, 11:48:51 PMThis message refers to a port that is installed as an upstream dependency but not even used by the os-cpu-microcode-intel plugin. This is not the cause of your issue. And it will just go away, eventually.
What seems to be causing all sorts of boot time freezes is the early loading of the microcode updates. Franco and team are working on it.
Ah, good to know. I appreciate the insight. Thank you.
In terms of solved what does this mean? Removal of the Intel Microcode updates could be an issue due to lack of fixes. Inclusion of the updates could prevent the router from working. I have been trying to recreate a router on this box (earlier versions of OPNSENSE) since I started getting an intermittent multi-color boot screen after some boots (with a hung system). The router often requires multiple reboots before it succeeds. Maybe I have been suffering from this race condition for a while. I am holding at my current version at the present time.
I am currently running OPNsense 26.1.11_10-amd64 with an Intel(R) Core(TM) i3-8130U CPU. Should I consider a new box for the router?
Thanks for reading this question.
An experimental microcode update package for OPNsense 26.7 will be published soon and I will open a new forum thread with a call for testers. A bit of patience, please.
Maybe it is obvious that this is a rare issue but it probably doesn't hurt to mention that the update worked flawlessly for me with the os-cpu-microcode-intel plugin installed. (Topton X2E N150)
Quote from: Patrick M. Hausen on July 17, 2026, 01:46:54 PMAn experimental microcode update package for OPNsense 26.7 will be published soon and I will open a new forum thread with a call for testers. A bit of patience, please.
# pkg add -f https://pkg.opnsense.org/FreeBSD:15:amd64/snapshots/misc/os-cpu-microcode-amd-devel-1.1_1.pkg
or
# pkg add -f https://pkg.opnsense.org/FreeBSD:15:amd64/snapshots/misc/os-cpu-microcode-intel-devel-1.1_1.pkg
These will not do very early loading and let init boot for a bit, but in the grand scheme of things it's still a relative early loading WRT OPNsense boot sequence.
I don't know if you need to install the dependencies via pkg install first, but there is a storm here and I need to run for now.
Cheers,
Franco
Thanks, Franco.
https://forum.opnsense.org/index.php?topic=52441.0
Thanks -- great answer Patrick.
Quote from: franco on July 15, 2026, 07:50:40 PMAllegedly this was fixed in late 15.1 RC cycle: https://github.com/opnsense/src/commit/56e59980b67
But the fix affects loader.efi, so it's not actually effective until the bootloader gets updated in ESP: https://www.freebsd.org/releases/15.1R/upgrading/#upgrade-loader-uefi
That's not something that happens as part of the OPNsense upgrade (should it?).
You're right. Doesn't change the fact that everyone including 26.7 would be affected either way by it unless they did a clean reinstall.
Cheers,
Franco
Quote from: jll544 on July 18, 2026, 09:05:10 AMQuote from: franco on July 15, 2026, 07:50:40 PMAllegedly this was fixed in late 15.1 RC cycle: https://github.com/opnsense/src/commit/56e59980b67
But the fix affects loader.efi, so it's not actually effective until the bootloader gets updated in ESP: https://www.freebsd.org/releases/15.1R/upgrading/#upgrade-loader-uefi
That's not something that happens as part of the OPNsense upgrade (should it?).
Patrick and meyergru have made some excellent instructions about upgrading the bootloader in a couple of topics so I am sure they can help you out in one of those topics :)
Quote from: Patrick M. Hausen on July 15, 2026, 06:03:22 PMSystem > Settings > Administration > Console
Quote from: meyergru on July 15, 2026, 06:22:19 PMYes.
I don't have the exact links anymore so could one of you do that part ?
Thnx! in advance ;)
https://forum.opnsense.org/index.php?msg=243083
However, the process is different for BIOS and UEFI boot, sometimes it depends on the type of boot disk and / or partitioning.
This is the reason why there is no automatic bootloader update (or upgrade of zpool options, FWIW). And if you want to update like depicted in the link, you need to have booted the NEW system first, which sometimes does not work, so it is a catch-22. That is why Franco wrote:
Quote from: franco on July 18, 2026, 09:19:41 AMDoesn't change the fact that everyone including 26.7 would be affected either way by it unless they did a clean reinstall.
I thought I'd share a related experience, though I didn't experience a direct crash. I have a CWWK S7 Pro (Intel N150) that was running 26.1.10_11. I had no issues with the `os-cpu-microcode-intel` package until attempting the upgrade to 26.7.
After rebooting, the upgrade process would start and then fail (log snippet below). I ended up power cycling the device, as I had no KVM connected to it. This left the system in an odd state where it was running the 15.1 kernel, but the OPNsense version was still showing as 26.1.10.
I ended up removing the `os-cpu-microcode-intel` package and then running `opnsense-update -u` from the command line. The normal upgrade process was just reporting "nothing to do."
[12/360] Extracting os-upnp-1.9: ....... done
Reloading plugin configuration
Flushing all caches...done.
Configuring system logging...done.
Reloading template OPNsense/Syslog: configd socket missing (@/var/run/configd.socket)
pkg-static: POST-INSTALL script failed
[13/360] Upgrading pciids from 20260522 to 20260624...
[13/360] Extracting pciids-20260624: ..... done
[14/360] Reinstalling libpci-3.15.0...
[14/360] Extracting libpci-3.15.0: .......... done
[15/360] Reinstalling x86info-1.31.s03_1...
[15/360] Extracting x86info-1.31.s03_1: ....... done
[16/360] Reinstalling os-cpu-microcode-intel-1.1...
[16/360] 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)
I have same issue right after os-cpu-microcode-intel-1.1 update
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.
Quote from: wide on July 19, 2026, 12:38:17 PMI 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 ?!
Quote from: wide on July 19, 2026, 12:38:17 PMOpnsense is running on top of the latest Proxmox version 9.2.4, using SeaBIOS and UFS2 filesystem.
...which in turn prevents a CPU microcode update in a VM for security reasons, so that is useless, if not even harmful. If you want the upgrade, install "intel-microcode" under PVE and uninstall the OpnSense plugin. That is one of the first recommendations here (https://forum.opnsense.org/index.php?topic=44159.0).
Quote from: nero355 on July 19, 2026, 03:06:32 PMQuote from: wide on July 19, 2026, 12:38:17 PMI 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.
You cannot apply CPU microcode updates from inside a VM at all. Installing the plugin is nonsense for virtualised systems. The hypervisor host must do this.
Quote from: Patrick M. Hausen on July 19, 2026, 05:03:29 PMYou 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.
Yes, because there is a bug in the FreeBSD boot loader that might make the system hang with early loading of the ucode updates, regardless if the updates are ever successfully applied to the CPU ;-)
Quote from: wide on July 19, 2026, 03:17:58 PMYes Proxmox now handles the microcode update.
Good, because the reason I mentioned it was the same as these posts :
Quote from: meyergru on July 19, 2026, 03:14:03 PM...which in turn prevents a CPU microcode update in a VM for security reasons, so that is useless, if not even harmful.
If you want the upgrade, install "intel-microcode" under PVE and uninstall the OpnSense plugin.
Quote from: Patrick M. Hausen on July 19, 2026, 05:03:29 PMYou cannot apply CPU microcode updates from inside a VM at all.
Installing the plugin is nonsense for virtualised systems. The hypervisor host must do this.
;)