Identified slow update reboot issue 24.03 and 24.03_1

skogs

Ok even though it was completely unnecessary on my end, I did the 24.03_1 update today. Knowing it was an extremely small change, I was kind of frustrated when a few minutes later it still wasn't pingable at all.
Turned on the monitor to see several lines about copying configs to new environment - all good.
See several failures to download DNSBL/pfblockerng lists. - not good
This is a majority of the wasted time...every single list...full tcp/ip timeout period.
Additionally - these update kickoffs were attempting to update PRIOR to bringing up the interfaces. - very bad.

Need to sort this behavior. This should have been a blocker.

skogs

Additionally I'm not smart enough to find this logged anywhere.
Not in dmesg because it is after that.
Not in syslog that I could find.
Not in update log.
Not in DNSBL log.

I'd love to prove it with more data...but I'm too dumb to find it.

stephenw10

It's this: https://redmine.pfsense.org/issues/15396

It does add a delay when upgrading but because it doesn't prevent the upgrade succeeding it wasn't a blocker for 24.03. It will need to be fixed though.

Steve

SteveITS

@skogs not saying it’s not an issue of course, but if you uninstall those packages first before the upgrade, as per the upgrade guide, they aren’t there at the boot.

skogs

@stephenw10 and @SteveITS
perfect. Usually I'm much more invested in beta testing and track the redmine much better. I just didn't have it in me this cycle.

I get that it be nmfp a bit because package and upgrade guide...but the tiny arm related thing...yeah...that isn't a real system update. I just didn't want to look at the thing telling me I was out of date.

I bet most of the guys that corrupted their stuff had this issue, didn't know it, and forced power while doing funny environment things. The delay, when using a good number of lists, far outweigh the actual time doing a fresh install. And no...I'm not using 50....just like 8 maybe?

stephenw10

Hmm, like how long exactly? We had to bump the verification timeout value to accommodate this issue though it's still only 300s (5mins).

But, yes, it clearly shouldn't do that.