I've been upgrading my routers to 25.12.4 and ran into lots of problems, mainly having to do with the build servers (but that's all been fixed, and thank you for that--ASU is a dream for upgrades!). On one specific router out of a dozen or so (I've got a lot of testing cases), the part after the flash and reboot seems to "hang" for a long time while it applies configuration, and even when the login prompt finally appears, the router is still not really quite ready: I have no connectivity at all. Subsequent boots on this one router are also slow, sans the configuration part, since that is only done once after the upgrade.
But, if I wait for maybe a minute or so, everything starts working as expected, just as it did in 24.10.5. I believe this may be due to PBR (and/or VPN?) taking some time to get fully started, but I am not certain. That's why I labeled this question with "init" rather than "boot" stage, because the delinquency seems to be post-boot. Strangely, at least 2 other routers here also use PBR with VPN and do not suffer as much latency after boot. The non-PBR routers upgraded without a problem.
I would say that this router is configured pretty similarly to those other PBR+VPN routers that don't appear to have that latency after boot. It is, however, my edge router, connected to the modem, so perhaps that accounts for the difference. BTW, there is no wifi on this router; that's handled elsewhere. It connects to the modem via a USB dongle, which otherwise works flawlessly and does not seem to present any issues for the upgrade.
It may be that 25.12.x does additional things that 24.10.x did not, particularly with respect to changes in PBR. I read through the release notes, but I did not spot anything that called out this kind of latency.
There's no fire here; the router is working fine. It is just a bit of concern, that's all. Maybe it is just the fact that it is the edge router talking to the modem over a USB Ethernet link. Other users might know of other factors. Thank you for your constructive, community-building responses!
You are unlikely to get any advice unless you specify more details of the problem. What type of router, startup log files from before and after the upgrade, etc. There are lots of smart people on the forum but nobody is a mind reader.
Thanks for the feedback. I think I've narrowed it down to a (documented!) issue in pbr.
It seems that in order to run pbr, one must also install dnsmasq-full if rules are to specify remote targets by DNS. It works if I enter an IP address as the remote address, but not a DNS name.
I stumbled across this fact while trying to determine why "service pbr start" was stalling on one of the rules--I had specified a DNS name that is defined locally on a downstream DNS router (not on the router where pbr is running). For whatever design considerations, pbr is unable to access the downstream router. I double-checked this by running tcpdump on the downstream router. After some period of time, of course, the pbr startup times out on that rule and continues processing. The pbr startup ultimately fails. The stalling is what was making the init stage so slow.
I noticed that a different rule had an IP address as the remote and pbr set it up without an issue. So I changed the rule in question to use an IP address and that put an end to the long hang in pbr start up.
For myself, I can live without the full dnsmasq package. Entering the target by hardcoded IP address is working. I only use that one rule for one downstream system, and it is merely for testing Internet connectivity.
If you do not use nftsets with PBR (for that you have to install dnsmasq-full) PBR has to resolve the domains at startup and if you do not have DNS then it will sit waiting until it times out.
In practice indeed use nftsets for domain resolving as stated in the manual.
If you cannot then make sure you have DNS resolving ready before you start PBR
Is there a way to change the timeout? Since I already know it is going to hang this way, I'd rather not have it continue trying to resolve the DNS names at startup.
Also, I notice that openvpn does not finish its startup. It only initializes one of the VPN connections, so I wind up having to restart openvpn service when the init scripts finish up.
Pico: Why do you say "top secret"--is there anything secretive about using a VPN? I don't claim that VPN keeps anything secret, or even necessarily keeps anyone safe online. There are a lot of disagreements and competing claims about VPNs online.
Certainly, there can be nothing "top secret" about a USB ethernet dongle! It is just a plain, ordinary RTL8153 (or sometimes an ASIX dongle).
The difficulty seems to occur during pbr startup. Before and after, DNS works, using the default resolver (whatever is specified for resolv.conf). Maybe this happens because during startup, pbr is generating rules that might be causing some kind of gridlock? The downstream DNS probably isn't responding because the route to its own upstream DNS is not accessible then.
I understand that the implementation of pbr has changed since the release of 25.12. But pbr worked prior to that (24.10.5 and previous), and that is a key point: Upgrading should not normally break anything, right?
I did notice that there is a prefetch option that might potentially get around this problem (it does sound from the description that it might), but even enabling that did not solve the issue either. Maybe I need to do something more than just enabling that option?
That was directed at Pico. It was a different user who inquired about hardware. It is a VM on x86_64 (or is it x86/64?). The router has what seems to be adequate memory (512MB) and CPU (2 vCPUs). I've run htop while starting pbr and did not notice any spikes or exhaustion of resources.
I did try installing unbound, in search of a smaller footprint than dnsmasq-full, but I remember running into some problem--that was weeks ago and I don't recall now what the problem(s) was.