Hmm, well hard to be sure I'd guess that Unbound was restarted when pfBlocker updated and then failed to restart for some reason. However that wouldn't prevent pinging 8.8.8.8. So another possibility is that one of the pfBlocker feeds had some rogue entry blocking far too much when it updated.

FWIW doing a "pfSense-upgrade -d" from CLI fixes this for me and does the upgrade properly. Not sure why that works and the GUI fails lol. I did have to rebuild my base packages. Here is what ChatGPT had to say about it. I had the same problem, two different locations, network providers, etc. One is in a datacenter with multiple network redundancies so I doubt it was a network issue. Root cause: The core problem was due to an incomplete or partially failed upgrade from pfSense 24.11 to 25.07. The missing critical libraries (libmd.so.7), corrupted package repositories, and broken package signatures indicate that some part of the upgrade script was interrupted, incomplete, or encountered dependency conflicts. Specific indicators of broken upgrade: Missing libraries (libmd.so.7) causing package operations to fail. Missing critical files (/usr/local/sbin/read_global_var, /usr/local/libexec/pfSense-upgrade, and /etc/version) indicate that pfSense-base or core packages were only partially upgraded. Invalid or broken repository signatures (pkg-static: Error loading trusted certificates) point to repository configuration or trust issues post-upgrade. Dependency conflicts (IGNORE_OSVERSION prompts) clearly indicated version mismatches due to packages from different pfSense/FreeBSD versions.

@stephenw10 Thank you. I will do some research on this option

Yes this needs to be addressed. But I would argue that if you can set the pppoe password you already have a high level access and could break things far more easily.

The ath(4) driver doesn't support USB NICs as far as I know.

@Gertjan said in BootLoader not found, please install an OS: @opticalc Well, the (cut short) TPM story is : if something changes the boot files on the boot partition, then the user should be warned when the system boots. That's the IMHO, whole idea behind TPM protection. On the other had, end user devices do have a TPM so they can install Windows 11. If its actually used to protect the system, only your BIOS can tell you that. OK, thanks - all that makes sense. But theres still got to be something weird going on with the pfsense installer, given linuxmint worked fine on a single partition, and pfsense gave so many problems?

Skipping the untrusted certs there is expected in any install. CE is not supported in Azure.

Yes upgrading CE in Azure is not supported. And that includes to Plus. The only supported deployment in Azure is from the tested Netgate image.

The issue vanished on it's own

This is still an issue as of 2.8.0 / 25.07, and it drives me crazy. Gateway failure works as expected, the wireguard tunnels will fail over to the backup gateway and continue on as normal, but will never recover once the failed gateway comes back online. While a reboot will (usually) fix it, I usually just go into my routing settings and mark the secondary gateway as down, forcing it to revert back to the primary... the users tend to dislike it when I reboot the firewall in the middle of the day

@stephenw10 Yep; the php-fpm script hung right at config upgrade. Had to do ctrl-t to see what was stuck. Stayed there until the script timed out then threw an error and rebooted in 24.11.

@eloich Thanks, this worked. Was back online in 2 mins of reboot and I didnt remove any packages this time either.

Yes, in the dynamic repo system ugrades are supported from the previous two versions. So you can skip one version. For 25.07 that's 24.03 and 24.11 so you would have needed to upgrade to one of those first from 23.09.

@slu said in Filterdns has stopped resolving hostnames in firewall aliases: aybe its relevant how ACME is configured. Nice catch ! This : [image: 1754480078430-7f044d98-4fe3-4b61-9697-d44d3c9bd573-image.png] implies that when you set DNS Sleep to '0', it's the script itself that starts polling every 'x' seconds the domain name servers. If its using one of the Doh etc, (which you've blocked with pfBlockerng) then yeah, that fails ... Set DNS Sleep to "200" or so and solved ^^

@johnpoz Thanks John, looking forward to your findings.

For reference that's an ugly error but it's only cosmetic. It's safe to upgrade still if you see that after rolling back.

@stephenw10 again... no errors. It's kind of wild... [2.8.1-BETA][admin@waw-staff-vpn.cic.com]/root: pfSense-upgrade -dC >>> Updating repositories metadata... Updating pfSense-core repository catalogue... Fetching meta.conf: Fetching data.pkg: pfSense-core repository is up to date. Updating pfSense repository catalogue... Fetching meta.conf: Fetching data.pkg: pfSense repository is up to date. All repositories are up to date. Your system is up to date [2.8.1-BETA][admin@waw-staff-vpn.cic.com]/root:

So you're using the CARP IP address for the pfBlockerNG redirects? May I ask why that's necessary?