Upgrade 2.2.3 to 2.2.4 - slow
-
I just upgraded from 2.2.3 on esxi 6 with latest patch from july as well build 2809209 with Zero issues very quickly.. Packages all installed just fine as well, freeradius2, LADVD, Open-Vm-tools, openvpn client export and vnstat2 - the upgrade was so fast I didn't even notice it go down while I was browsing.
Jul 27 07:01:10 shutdown: reboot by root:
Jul 27 07:07:13 sshlockout[40427]: sshlockout/webConfigurator v3.0 starting upLooks like about a total of 6 minutes to upgrade and reinstall all my packages, etc. etc..
-
Here it's been over 30 minutes. Command line stopped at starting NTP client.
Web GUI states its updating.
I am though typing here and on the internet.
Looks like an issue here. First time I have seen this on an update.
-
Gui Dashboard shows:
pfSense is booting then packages will be reinstalled in the background.
Do not make changes in the GUI until this is complete.
Console shows it loading NTP client.
Logging in to box via SSH appears normal.
Going to reboot it anyways…
-
Use a veeam backup to restore my 2.2.3 and removed pfblockerNG
NO ISSUE to updateThis package is a pain … (sometime reboot takes 30 minutes ... I'm force to delete aliases to make pFense boot)
-
A failure to reboot + can't load kernel usually means it ran out of disk space while upgrading. Not normally a problem on physical systems but if your VM has an unusually small disk it can lead to trouble in that area.
-
In my case 16 gig …
plenty of room -
This package is a pain … (sometime reboot takes 30 minutes ... I'm force to delete aliases to make pFense boot)
That's been actually fixed: https://redmine.pfsense.org/issues/4442
-
not implemented in the latest version downloadable through packages
or it's not working
or I'm dumb ;D
For the info booth of my pfsense upgraded flawlessly after restore from veeam backup then removed pfblockerNG
-
Its not the pfBNG package that is causing these issues at reboot. If the hardware is on Nano or Ramdisk, the /var folder is wiped at reboot and pfSense is trying to load the Alias file that doesn't exist in the /var/db/aliastable folder. There was a bug fix to reduce that timeout to a Minute per alias I believe.
The only workaround without some base pfSense code changes would be to Un-Install pfBlockerNG ( and only needed For Nano/Ramdisk Installs With "Keep Settings" checked ) before any pfSense Upgrades. Following the Upgrade, do an Install of pfBNG and follow with a "Force Update".
-
There was a bug fix to reduce that timeout to a Minute per alias I believe.
It's actually down to 5 secs now… so, really a non-issue even with tons of aliases.
-
not on nano or ramdisk
ESXI VM with 2gig of Ram and 16Gig of diskpfblockerNG gone … no more issue
-
not on nano or ramdisk
If you read the above bug - actually YES. Tested on multiple Alix boxes. The delay is down to 5 secs per URL table alias.
-
I think Jimp was correct and the VM ran out of Space. Packages like Squid and pfBNG can take some space depending on whats configured and if things like Squid Caching is enabled. On pfSense upgrade, it also has to pull down and extract the full pfSense image before it will upgrade the VM. Probably pushed it over the edge and caused that "Load kernel" issue when it ran out of space.
-
I just was saying that I wasn't on ram or nano
That I have disk spaceMy 2 pfsenses are not in those cases
