I had to reinstall, I had a free pfsense plus licence which sadly was now invalid. After the first boot everything worked but after restoring the pfsense plus config the error started showing up.

I changed System>Advanced>Miscellaneous>PHP Settings>Memory Limit from 128 to 256, rebooted and the banner is gone. Presumably this has resolved it. I have a second 1100 which I'll repeat the update and see if the error recurs. If so, I'll see if the above fix resolves it as well. Seems the update process, at least, should make this adjustment instead of leaving a mess requiring the customer to trouble-shoot. In the long run, as I've observe elsewhere before, the SG1100 seems to be under-resourced for pfSense's modern versions.

What does zfs list show? Or zpool status?

@jimp Well done, in fact I have thousand of files on it. After cleaned up, upgrade works fine. Thanks a lot...

The ZFS upgrade process now does most of the upgrading to the new BE before the reboot to minimise downtime.

@stephenw10 Thanks, since pfS runs in KVM, I can restore an old backup in a few seconds if there are problems.

It appears to hang immediately after loading the kernel at the UEFI console? Try booting legacy to confirm it's the same issue.

@stephenw10 honestly I am not too sure at this point. First day after the fix, I've been randomly losing LTE links for shorts periods. Since last 2 days it's been all right, it would have been such a coincidence that the provider had problems at the same time. Though not impossible... Last night I lost IPSEC tunnel (one site only) for maybe ±30mins and then it came back. No indication of LTE down/gateway down during this time. I've adjusted the log level for IPSEC so I can go back when it happened (level was too high). We did NOT downgrade the units for now. We had NO init string using 2.7.2 and it was working fine!

@WB3FFV said in Update or Fresh install of 25.07 causes HP ProLiant DL20 Gen9 to Reboot after PFSense Menu: @stephenw10 The million dollar question is, should load modern servers in BIOS or UEFI mode? I assumed now days UEFI was an improvement and the preferred method, but maybe not.. There is no million dollar answer. Recently I run into issues due to a bug in freebsd that would only affect NON uefi installs. Using uefi, all worked fine. It was fixed later on. Now it seems you are facing the opposite. Apart from that, uefi is probably the only way to go, longterm.

@Unoptanio per the upgrade guide https://docs.netgate.com/pfsense/en/latest/install/upgrade-guide-prepare.html#packages “The safest practice is to remove all packages before upgrading to a new release. The upgrade process will handle packages automatically, but packages are frequently a source of problems. To ensure a smooth upgrade, note the installed packages, remove them, perform the upgrade, and then reinstall when the upgrade is complete.” No it’s not required. pfSense will upgrade packages. Yes the package setting remain in the configuration file by default.

Vendors have firmware bugs similar to this quite often, and usually you'd see the OS failing suddenly for no good reason. Falling back to PCI IO access for the config space will probably only allowing boot-through, but any time something allocates memory into that region, it won't be going to DRAM... leading to data corruption. If you enable above 4GB decoding (and it successfully boots), there could be a change to the ACPI tables that the firmware generates. In any case, we'll need to find a way to let FreeBSD know not to use that memory region for allocations.

@JonnyQuest im on 2.8.0 and i also had no problems Shell Output - pkg update -f Updating ntop repository catalogue... Fetching meta.conf: . done Fetching data.pkg: . done Processing entries: . done ntop repository update completed. 6 packages processed. Updating pfSense-core repository catalogue... Fetching meta.conf: . done Fetching data.pkg: . done Processing entries: . done pfSense-core repository update completed. 4 packages processed. Updating pfSense repository catalogue... Fetching meta.conf: . done Fetching data.pkg: ......... done Processing entries: .......... done pfSense repository update completed. 541 packages processed. All repositories are up to date.

@SteveITS I went back and retraced my steps, ONLY to realized that I had actually been attempting to restore an OPNsense config and NOT a pfSense config into pfSense 2.8.0... Today I had been running the same exercise (prep for switching from Cable to Fiber) in both... Hence False Alarm: pfSense 2.8.0 was "Correct", in fact it was NOT a pfSense config!!! Restoring Today's Initial Chrome config into pfSense 2.8.0 works as expected... Lawrence Houston

@m80s said in Update 2.7.2 to 2.8.0 Dynamic DNS not working with Cloudflare: @stephenw10 in my case I tried with 25.07.1: DuckDNS DeSec both with IPv4 and both failing. Yeah that's unexpected. Unless they are using a WAN with a gateway that shows as down. In which case you would be hitting the new behaviour requiring gateway monitoring be corrected.

Your root filesystem is down to 1.5G with only 345MB available. It is a space issue. Go to System> Boot Environments and remove any older snapshots you're no longer using. I usually recommend removing all but the currently running BE and one previous one. Then retry upgrading.

@dennypage Last night I upgraded the 2100 via the console with pfBlockerNG and Avahi packages left in place, and after 20 minutes or so it came back up and avahi appears to be working properly.