Messages

Are you using the same hardware?

Yes, same hardware.

I used this guide to fix it:

To resolve the boot loop caused by CPU microcode, you need to mount your ZFS boot environment from the USB stick and disable the loading instruction in the configuration file.

The reason "unloading" at the loader prompt often fails is that the microcode is frequently loaded as a specific firmware blob or environment variable set early in the boot process, which persists or gets re-read unless explicitly disabled in the configuration.

### Step-by-Step Recovery Guide

**1. Boot into the Live Environment**
Boot from your OPNsense or FreeBSD USB installer. When prompted, select **Shell** (or "Live CD" -> login as `root` / `opnsense` depending on the image).

**2. Import the ZFS Pool**
First, create a temporary mount point and import your pool. The pool is usually named `zroot`.

Code Select Expand

mkdir -p /tmp/mnt
# List available pools to confirm the name
zpool import
# Import the pool with an alternate root (-R) to avoid mounting over the live system
# Use -f to force import since the pool was not exported cleanly
zpool import -f -R /tmp/mnt zroot

**3. Mount the Boot Environment**
OPNsense uses ZFS Boot Environments. The root file system is not at the top of the pool but in a dataset (usually `zroot/ROOT/default`). You must mount this specific dataset.

Code Select Expand

# Identify the boot dataset (look for the 'bootfs' property)
zpool get bootfs zroot

# Mount the dataset identified above (e.g., zroot/ROOT/default)
zfs mount zroot/ROOT/default

**4. Disable Microcode Loading**
You need to edit `/boot/loader.conf`. In the mounted environment, this file is located at `/tmp/mnt/boot/loader.conf`.

Code Select Expand

edit /tmp/mnt/boot/loader.conf
*(If you are uncomfortable with `vi`, try `ee` if available).*

Look for the following lines and either delete them or change `"YES"` to `"NO"`:

Code Select Expand

cpu_microcode_load="YES"
**Check for local overrides:**
Sometimes plugins (like `os-cpu-microcode-intel`) write to a local file. Check if it exists and edit it as well:

Code Select Expand

vi /tmp/mnt/boot/loader.conf.local
**5. Clean Up and Reboot**
Once the files are saved:

Code Select Expand

# Unmount the dataset
zfs unmount zroot/ROOT/default

# Export the pool
zpool export zroot

# Reboot the system
reboot
Remove the USB stick. Your OPNsense server should now boot without loading the problematic microcode. Once booted, you can uninstall the microcode plugin (`os-cpu-microcode-intel` or similar) via the GUI to prevent it from re-enabling the setting during updates. [forum.opnsense](https://forum.opnsense.org/index.php?topic=14245.0)

Same problem here on business edition. There should be a way to blacklist the bad ones :/

Just to confirm.
The replacement box had some changes which made it look like dpinger wasn't working.
OpenVPN connections were established, but content could not flow through due to a cipher issue. That means that dpinger could no ping the monitoring IP.
And the WAN gateway had monitoring disabled for some reason, which is the reason the dpinger service was never started when the other gateways were down.

Thanks for your help marjohn56

Something I've noticed.
The gateway at the top of the list is an OpenVPN one. When it's online, dpinger starts and is marked as green. I have logs.
It goes down, dpinger goes down, depsite the fact that WAN is still up, lower in the list.
Is this the way it's supposed to work? If the only Gateway up is the default, then dpinger is always down?

I think I've found one of the problems.
All the OpenVPN interfaces had been reset to the LAN NIC instead of keeping their VLAN due to a bug in the Interface sub-routine on 19.1.1.
I've re-assigned all of them and now the single interfaces show up as online in the "Single" view, but dpinger still doesn't start.

I edited my answer earlier with my config. It looks like yours, except for the default gateway.

<quote>How is your WAN setup is it static, dhcp PPPoE? Are your gateways auto created or manual?</quote>

WAN is up, using DHCP. It's marked as online, depsite dpinger being down.

The OpenVPN gateway is also using DHCP. It was manually created as an OpenVPN client, then the interface was assigned, in the Interfaces section.

Same problem as in all gateways relying on dpinger are down and cannot be started.
I have gateway monitoring on OpenVPN, but the OpenVPN service is up an running and connected to the remote locations.
Both appliances are on 19.1.1.
Nothing in the gateway or main logs.

Gateway config:
Interface: OpenVPN interface 1
Address family: IPv4
IP address: synamic
Monitor IP: 1.1.1.1

Everything else in unticked.

Same problem here.

Upgrading from 18.7 broke all Open VPN gateways. They can't be started. Gateway logs show nothing.
Happened on 2 different appliances.

Any way to already upgrade to 19.1 RC via the console?
I have a spare system on 18.7 with ZFS which I could test with.

Just a heads up. When using ZFS, password recovery from the live image does not work any more. The script can't mount the partitions.

Fitlet2 with extra LAN on 0.46 bios.

Since I wanted to use ZFS, I had to start with FreeBSD 11.1 and use a script to install of 18.7.4.
The only parameter I needed to add after the installation was: set hint.ahci.0.msi=2

I had disabled mwait and SDHC in the BIOS.

Had to install twice because of the broken installation wizard which destroy passwords. When using ZFS, password recovery from the live image does not work.

OK, so the last step is to upgrade via the GUI.

1. console:

Code Select Expand

select 8
# opnsense-update -t opnsense-devel
# exit

2. console

Code Select Expand

select 12
type "18.1.r2" and hit enter

3. GUI

Check for update and upgrade to 18.1.r2

4. console

Code Select Expand

select 8
# opnsense-patch bba40c97 947718b

Post reboots, the console tells me I'm on r66 and the GUI still says my version is NA, but I can upgrade to 18.1.r2.

Is this the normal behaviour?

Re-read the instructions...

Missed this: type "18.1.r2"

So, it's my fault, but I find the interactive menu confusing. When reading it, I thought it was asking me if I wanted to update to 18.1.r2 and so I pressed "y".

Seems to be downloading base + kernel now, so it should work :)

I've followed the steps above, but it doesn't work. I've edited my message too many times.

Started with 18.1.b + 17.7.11.

After using option 12, I get:

Kernel locked at 18.1.b-amd64, skipping.
Base locked at 18.1.b-amd64, skipping.

Console says I'm on 18.1.r_82. Not sure if it's the same as R2 or if it's still b1

No reboots were performed.

GUI says my current version is "N/A" and that I can upgrade to 17.7.12.

So it seems the upgrade process is missing some steps.