Well that's not a bug if the gateways used were marked as down. That's the expected behaviour in 2.8.X. If the gateway being marked down is a change since 2.7.2 that could be a separate problem.

Now you can upgrade to 25.07.1.

It's no different in 25.07.1. The 1100 can take a while to complete the check I agree. It's not really a bug though, it really is waiting for another instance to finish. Previous versions just hid that.

@Flowi001 Thank You .

@SteveITS Thanks.

918MB is potentially not enough available space. You should remove some older BEs and retry. I would normally expect to see the 'not enough space' alert if it hits that though.

@SteveITS Tool tips say the following: green: Current Boot Environment yellow: Boot Verification Failed black: Upgrading Boot Environment

@malindsay Your welcome, and I would say stay back a version, or switch to Legacy BIOS mode, either works. Was going to give you a thumbs up, but apparently my reputation isn't good enough here yet.. LOL Trying to remember how many years I have been around this place, just not always active.. -Howard

Hmm. Well if you can replicate the WAN failure after upgrade it would be good to grab a status_output file to check. I've not seen that on an 1100 here.

@Gertjan @stephenw10 Thank you for the explanations. I will start a new thread.

@jacksonp Well that’s unexpected also, haven’t had that sort of issue across our clients. I think the only reinstalls on 2100s were for the EFI issue.

I have to agree with you! My upgrade went smooth and nothing needed to be restarted, upgraded or anything else! I did upgrade a 4200, but at least it went smoothly. I will run another backup since it is upgraded.

@syhm Thanks, although I did try that and unfortunately no dice.

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.

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

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

@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!

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

@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