Upgrade 2.2.3 to 2.2.4 - slow

pete

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.

pete

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…

stanthewizard

Use a veeam backup to restore my 2.2.3 and removed pfblockerNG
NO ISSUE to update

This package is a pain … (sometime reboot takes 30 minutes ... I'm force to delete aliases to make pFense boot)

jimp

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.

stanthewizard

In my case 16 gig …
plenty of room

doktornotor

@stanthewizard:

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

stanthewizard

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

BBcan177

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".

doktornotor

@BBcan177:

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.

stanthewizard

not on nano or ramdisk
ESXI VM with 2gig of Ram and 16Gig of disk

pfblockerNG gone … no more issue

doktornotor

@stanthewizard:

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.

BBcan177

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.

stanthewizard

I just was saying that I wasn't on ram or nano
That I have disk space

My 2 pfsenses are not in those cases