Second reboot after upgrade required?
-
Here is something I noticed: I autoupgrade to a new version of pfSense, the software is downloaded, installed, the system reboots, and then over the course of a period of time reinstalls all the packages.
After all is done, my SIP phones have trouble connecting to their registrars. I try all sorts of things, pfSense seems to be operating just fine: no go.
Reboot pfSense, BINGO, phones registered in an instant.It seems that even though the box pretends to be OK, it really isn't, until it's rebooted once more after all packages are reinstalled after an OS update.
I wonder if that's a bug, or if certain packages required that, why that second reboot isn't done automatically. Given the downtime the update causes, one more reboot won't make much of a difference…
-
I think the packages here are the cause for not starting everything after a package install.
File bugs against the respective packages.
-
If you're on NanoBSD, package reinstalls after upgrade sometimes do necessitate the need for a second reboot.
-
I'm not on NanoBSD, at least not on the system with the specific issue.
Problem about filing bugs against the packages: I wouldn't know which packages would be causing the trouble, since right now pfSense is just used as a router/VPN box, so I have essentially "permit all" rules for IPv4 traffic set up on every interface and the VPN link until I have time to create the rule set, so there's really nothing that should stop traffic, whether packages installed or not.
The only packages that don't reinstall properly and need to reinstalled manually after each upgrade are the Antivirus Dashboard widgets (Antivirus Status and HAVP Alerts).
I first suspected siproxd, but starting it and stopping it makes no difference, and the SIP phones currently don't use it anyway.
So the thing isn't that some packages that are required for the SIP phones to work aren't running, because regular traffic is routed just fine, and the SIP phones don't really do much different things than anything else.
IP addresses are all fixed and routed publicly (through the tunnel) so the NAT and DHCP WAN should only affect the establishment of the VPN tunnel, if anything, and that works for the most part.What things make the reboot a necessity in NanoBSD? Could it be that some things think they are on NanoBSD when they are not?
-
The NanoBSD thing is because some package installs don't do the right thing for the ro/rw switch so the counts get off and it sticks on rw, and some things can flake out.
That can't ever happen on a full install.
