Messages

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.

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.)

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.)

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!

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.