Packages not starting after config restore on pfSense 2.4.4
nmeth last edited by
I am finding that when we restore a config (built on pfSense 2.4.4) to a pfSense 2.4.4 box and including some package data, the package re-install process that is happening as part of that is not starting the packaged daemons.
For example the config I am testing with is running on VMware ESXi, so has the Open VMtools packages, and has some BGP routing using the FRR package.
Following the config restore and associated reboot, the box reinstalls the packages, but none of the VMtools or BGP daemons are started. They are started correctly after a further reboot.
This did not happen with 2.4.3p1
Probably related to this: https://redmine.pfsense.org/issues/9045
Similar restore issue. If you have a spare box to try an experiment, test a 2.4.5 snapshot.
nmeth last edited by
@jimp Tested with a VM built against
pfSense-CE-2.4.5-DEVELOPMENT-amd64-20181025-0115.isoand that fixes the problem.
I don't know enough to tell if this is related or helps diagnose the problem...
My recent restore to 'bare metal' failed, with packages not being restored, and NTP not updating the system time.
The system was set to use only DNS Resolver (no servers added to General Setup). Maybe because the time was wrong, DNS couldn't work, so the time couldn't update - stuck in a loop, with packages not working/installing etc.
I switched the system to use (OpenDNS servers) DNS Forwarder, and the system came back to life. I had to manually reinstall the packages, but my previous settings seemed to be retained.
Once complete, I reverted to DNS Resolver, and the system continues to function as expected.
Is accurate time required for Resolver but not Forwarder?
How much tolerance is allowable?
My BIOS had reset to 2012, so I guess this failure was understandable!
Inaccurate time could hinder DNSSEC validation, which may have caused some things to fail to resolve.
That's not related to this thread, however.
Thanks for the prompt reply.
One of the first things that I noticed didn't resolve was the repository. No packages were available, and the Status page couldn't check for updates.
Since I was restoring a config from a backup, that's why I thought this might help.