BIOS halted with 0x06 Invalid Opcode in the pre-boot UEFI environment

[txr13]

I'm running OPNsense 25.7.11_2 on a Dell PowerEdge R250. After updating the BIOS to version 1.15, I can no longer boot OPNsense at all.

After POST, the loader menu comes up, and OPNsense proceeds to load the various modules for ZFS, intel_uucode.bin, bridge, and others I didn't catch. On a normally-booting system, the screen is cleared, the font changes, and the actual boot sequence begins. On a system running BIOS v1.15, I get a red screen indicating the BIOS has halted because of a CPU exception 0x06 Invalid Opcode in the pre-boot UEFI environment. Registers are visible, but there is no stack trace. (From memory, it says something about there being no LBR, but I don't know what that is.)

This was the primary router for a fairly large site, so I focused on getting the system back into operation rather than deeply investigating the issue. The problem was fixed upon reverting to BIOS v1.14.

Version 1.14 (working): https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=t3jrr&oscode=naa&productcode=poweredge-r250
Version 1.15 (failed): https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=2yt0g&oscode=naa&productcode=poweredge-r250

The most notable change in 1.15 seems to be "Intel processor and memory reference codes in the IPU Production Release IPU 2026.1 2125.15." I freely admit that I don't know that this caused the error, but I wanted to raise this as a possibility that this may change the opcodes available to the loader in the UEFI environment.

The site in question does have a secondary router on identical hardware, so there's a possibility I can use that to gather more information if necessary / helpful.

[meyergru]

I would guess that your OpnSense installation is a little older. You must know that OpnSense does never upgrade the actual UEFI bootloader.

Yours may be incompatbible with your current BIOS / microcodes in version 1.15.

So, once back to the running 1.14 release, you could try to manually upgrade the UEFI bootloader and then try again to upgrade your BIOS.

See this - not exactly your situation, but the instructions on how to update the boot loader probably still work. Patrick is the expert on these matters. Be careful about your specific partitioning.

[txr13]

I remember looking at that thread some time ago, as it happens! :) I was referencing it because I observed during the boot sequence that the loader needed to be updated. It was a while back, but I think the thread I saw was this one (https://forum.opnsense.org/index.php?topic=46035.0) which referenced your instructions to update the bootloader. (And in fact, I also remember taking some pains to be sure I updated the bootloader on both drives, since this is a ZFS mirror.)

So I know that the bootloader has been updated since the original installation, and probably within the last 12 months. It may be worth trying to update it again and then having a go with BIOS 1.15, but I do want to just confirm that I have done this update process once before in the past, so at the very least it's not as old as it could have been!

[meyergru]

I think that the 1.15 BIOS may have Intel microcode update from september 2025, so you probably need some very recent UEFI code to fix the problems caused by that. Other than that, there are probably only the microcode updates in there that caused Dell to issue that release.

Since it may be only the UEFI code that causes problems (and not the FreeBSD kernel), you could skip the BIOS update and only use the OpnSense microcode package. That is applied after the UEFI bootloader has finished.

Another possible trick would be to use BIOS boot instead of UEFI boot - OpnSense can do both.

[txr13]

I have the intel-microcode plugin installed, so if it was a microcode issue, I would expect that to (hopefully) be up to date already. My goal in applying the BIOS update was to incorporate any other security fixes and hardware-specific updates, essentially as routine maintenance on a network perimeter device.

Right now, I'm okay with continuing to run the working 1.14 version of the BIOS, so I'm not pushing for any sort of an immediate fix. My goal was mostly to flag what seemed like a potential issue if an Intel platform update causes (some versions of) the bootloader to red screen and halt the system. (And if that does need fixing, I also recognize that it would need to be pushed upstream, so it might not be something immediately fixable by OPNsense anyway.)

[meyergru]

After OpnSense has booted, the BIOS does not control much any more (except from vPro features, that is). So if the BIOS is viable to control your hardware (fan control, disk drivers for boot phase), it should never need an update, unless hardware is changed or CPU microcodes must be applied.

Since OpnSense offers a way to update the microcode independend of the BIOS, you actually do not need to update the BIOS any more - this is even more true if the only reason to update the BIOS is in fact updated microcode. I think this may be true for most systems older than 5 years.

I think this is true of your BIOS 1.15, especially, because there are no release notes as to why there is an update - maybe security patches are not even mentioned for "security by obscurity" reasons. Matter-of-fact, there are no functional reasons given, either.

[txr13]

On the contrary, the release notes on the page I linked for the 1.15 version also notes the following points:

- Fix PXE boot fails when there is boot option is listed as the last entry in the boot sequence and set by Virtual Console.
- This product release contains security update DSA-2026-012 and DSA-2026-040. Any security fix information will be accessible on the Dell Security Advisories and Notices website.

DSA-2026-012 appears to be an Intel CVE that is fixed in microcode, so the plugin would certainly mitigate that. DSA-2026-040 does not appear to be available at the present time, so who knows what that's about. Regardless, the release notes definitely do mention security updates, and also a functional reason (though that doesn't apply to me, since I disable PXE boot on perimeter devices anyway).

Still, I wouldn't consider "just don't do updates for that" a valid response in general. I do read the release notes for what I update, and I'm generally happy to postpone or skip individual updates if I don't have a burning reason to install them... but I will install them eventually, and other users may have them installed even before installing OPNsense. Hence why I wanted to flag the possibility that a new platform update might affect some versions of the bootloader.

If the general thought is "you don't need to update your BIOS, so use of a newly-illegal operand isn't a concern," then I'll drop it, even if I do find that an unsatisfying answer. I realize the issue may also need more investigation. I may do some of that investigation myself, when I get a chance. (I think updating the bootloader again and then trying to upgrade to 1.15 might be informative, and if nothing else I'll have the presence of mind to capture the registers visible in the halt screen for further analysis.)

[meyergru]

Interesting, I did not find any release notes on the download page for the BIOS update.

Again, the CVE is most probably adressed by a microcode update that is also in the OpnSense microcode package - and if the functional update was not for for anything that kept your OpnSense instance from working (well, obviously not), then what does it fix (for you)?

Also, if you use your search engine chi (I did), you will find references to that boot problem and the probable microcode cause, so you do not have to investigate.

To conclude - and only IMHO:

1. You now know how to fix the boot problem, even with 1.15 applied.
2. I explained why I think that neither security upgrades via microcodes not functional upgrades warrant BIOS updates after installation (mind you, provided that you keep OpnSense current, which you did not). You are entitled to your own opinion, of course.
3. I gave pointers to the probable root problem of this failure which you may or may not care to investigate.

[alex303]

This is why your firewall should always use open source BIOS like core boot or libreboot. UEFI is just too much hassle and insecure.

[txr13]

This is why your firewall should always use open source BIOS like core boot or libreboot. UEFI is just too much hassle and insecure.

I would agree that using coreboot is an excellent option, particularly where the hardware vendor officially supports it. I find the Protectli boxen are very good on that point, and any of those which run OPNsense for me are indeed using coreboot.

...which boots using UEFI.