2.3.2 Yes sir, one more botched install
-
Interesting- Ive got 7 boxes I maintain right now and not one of them failed. Slowest connection is 20mb down and of coarse that one took the longest but never hiccup'd in the least.
Its always been recommended that you uninstall any packages and reinstall them after a version upgrade as far as I remember. Might try that next time.
-
I'm on 2.3.1-RELEASE-p5 (amd64). System currently reports "Unable to check for updates"
Under Packages, it shows "No packages installed. Packages can be installed here."
This is simply unacceptable for such a mission critical piece of hardware. >:(
This is exactly what happened to my primary machine.
As I said, good coding always makes sure that even if the download servers are slow, even if the connection gets broken, even if the machine crashes while doing the updates, that all operations that were started, get finished.
This is the only thing that has kept me from using pfsense with customers. I have been using the free Untangle Router/UTM with a couple of customers (and myself at home too) and in the 5 or 6 years, none of them have ever failed on an upgrade.
Free IPSec VPN is really the only reason I have stayed with pfsense, but at some point, the time that I have to spent babysitting a pfsense upgrade (either by dealing with after upgrade issues or by uninstalling packages, upgrading and then reinstalling packages) is not free, and can be enough to justify paying the $200 dollars for IPSec in Untangle (or other firewall/router offerings).
Again, don't want to bash this great software or the team that produces it, but we need to start by admitting when something is not quite 'there', if we really want to make the best product.
Before 2.3.x, when I complained about package issues after upgrades, I was told that it would get much better (solved?) with the new pkg system in 2.3. Perhaps that is the case and the new pkg system works better, but obviously there is still some lose end somewhere.
Oh well, I'll work on my primary machine sometime today so I can have my CARP setup back up.
-
I didn't have any issues with the upgrade. Although the download of the packages took awhile. I did check through the forums first to see if anybody had show stoppers that may affect my set up. I held my breath and clicked on the upgrade button.
Then walked away to get some lunch. When I came back upgrade was successful after it rebooted itself. So far everything is working fine.
I didn't have this kind of success with WatchGuard last weekend when I upgraded it to their latest firmware only later to find out they borked the SPF modules which is what I use for HA so both the primary and secondary units kept fighting with each other since neither know the current state of each other. What a mess. Previous firmware didn't have this problem. This is not to bash WatchGuard but point is things happen even with a commercial paid product.
-
Ah.. now the pkg handler is taking lots of CPU.
I'll post a new thread I guess.last pid: 8314; load averages: 1.19, 1.11, 1.09 up 0+01:22:51 15:14:27
53 processes: 2 running, 51 sleeping
CPU: 22.8% user, 0.0% nice, 10.5% system, 0.0% interrupt, 66.8% idle
Mem: 1049M Active, 366M Inact, 413M Wired, 272M Buf, 2102M Free
Swap: 4096M Total, 4096M FreePID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
84788 root 1 102 0 45180K 9416K CPU0 0 66:13 98.97% pkg
29743 root 9 20 0 657M 541M uwait 2 0:44 0.00% suricata
31403 root 8 20 0 657M 540M uwait 2 0:43 0.00% suricata
31604 unbound 3 20 0 194M 165M kqread 1 0:05 0.00% unbound
57477 root 1 20 0 224M 35284K nanslp 2 0:03 0.00% php
33422 squid 17 20 0 165M 67184K uwait 2 0:03 0.00% squid
55818 root 1 20 0 101M 8544K select 1 0:02 0.00% vmtoolsd
85500 root 1 20 0 40260K 6556K kqread 2 0:01 0.00% lighttpd_pf
28445 root 1 20 0 39136K 7100K kqread 2 0:01 0.00% nginx
22981 root 5 20 0 15012K 2184K accept 0 0:01 0.00% dpinger
23577 root 5 20 0 15012K 2184K accept 2 0:01 0.00% dpinger
36545 squid 1 20 0 37752K 4096K select 1 0:01 0.00% pinger
39743 root 1 20 0 266M 39132K accept 1 0:01 0.00% php-fpm
28151 root 1 20 0 39136K 6940K kqread 0 0:00 0.00% nginx
83948 root 1 20 0 14508K 2312K select 2 0:00 0.00% syslogd
43532 root 1 52 20 17000K 2360K wait 0 0:00 0.00% shI'm on 2.3.1-RELEASE-p5 (amd64). System currently reports "Unable to check for updates"
Under Packages, it shows "No packages installed. Packages can be installed here."
This is simply unacceptable for such a mission critical piece of hardware. >:(
This is exactly what happened to my primary machine.
As I said, good coding always makes sure that even if the download servers are slow, even if the connection gets broken, even if the machine crashes while doing the updates, that all operations that were started, get finished.
This is the only thing that has kept me from using pfsense with customers. I have been using the free Untangle Router/UTM with a couple of customers (and myself at home too) and in the 5 or 6 years, none of them have ever failed on an upgrade.
Free IPSec VPN is really the only reason I have stayed with pfsense, but at some point, the time that I have to spent babysitting a pfsense upgrade (either by dealing with after upgrade issues or by uninstalling packages, upgrading and then reinstalling packages) is not free, and can be enough to justify paying the $200 dollars for IPSec in Untangle (or other firewall/router offerings).
Again, don't want to bash this great software or the team that produces it, but we need to start by admitting when something is not quite 'there', if we really want to make the best product.
Before 2.3.x, when I complained about package issues after upgrades, I was told that it would get much better (solved?) with the new pkg system in 2.3. Perhaps that is the case and the new pkg system works better, but obviously there is still some lose end somewhere.
Oh well, I'll work on my primary machine sometime today so I can have my CARP setup back up.
-
I have done coding and systems myself (including software testing) so I know first hand that it is not easy and that when things don't get tested properly, things get discovered after 'release'.
In my case, I have had issues with upgrades almost every single time. Which means this is not a one off bug, but simply that the upgrade process is not robust.
Is that your experience with WatcGuard (or any other free or paid router/firewall)?
I didn't have any issues with the upgrade. Although the download of the packages took awhile. I did check through the forums first to see if anybody had show stoppers that may affect my set up. I held my breath and clicked on the upgrade button.
Then walked away to get some lunch. When I came back upgrade was successful after it rebooted itself. So far everything is working fine.
I didn't have this kind of success with WatchGuard last weekend when I upgraded it to their latest firmware only later to find out they borked the SPF modules which is what I use for HA so both the primary and secondary units kept fighting with each other since neither know the current state of each other. What a mess. Previous firmware didn't have this problem. This is not to bash WatchGuard but point is things happen even with a commercial paid product.
-
I did talked with tech support at WatchGuard and been told they do test the new firmwares before releasing them to the wild. In our cause since we are the minority of using SPF they didn't catch this. I going to guess someone changed the code that broke the links to the SPF module libraries before compiling the firmware.
So for special setups may not take into account before releasing the updated firmware. Lucky I made an image backup of the firewall before I upgraded it. However, since only HA is just borked I left it as is since it's working. Just we don't have redundancy. They are working on an update.
WatchGuard have nothing to do with this thread so don't want to go off topic but wanted to point out that bad upgrades can happen with anything. Especially for complicated piece of software.
-
Sorry you are having such trouble with upgrades.
I like to follow this process. It seems to have served me well so far.
- remove installed packages (I rarely have any installed)
- disable ram disk (if enabled)
- reboot so everything is in a know clean state
- physical system console option 13 to upgrade
No doubt the upgrade process could be more robust. Given the wide variety of hardware and configurations though it's understandable. Maybe not desirable, and maybe should be even better, but understandable. Especially for "free".
Hope you get it sorted out.
-
I'm on 2.3.1-RELEASE-p5 (amd64). System currently reports "Unable to check for updates"
Under Packages, it shows "No packages installed. Packages can be installed here."
This is simply unacceptable for such a mission critical piece of hardware. >:(
Same problem here.
Used the CLI to complete the update, but it refused to boot after.Took a while to reinstall and restore the backup configuration. Not the first time I had to to this either.
-
I upgraded to 2.3.2 too thinking it would help with my Squid/Squidguard but I still have the same problem of it not blocking.
Problems started when I upgraded from 2.3.1 to 2.3.1_5 and continues to 2.3.2.
I had it working just fine on 2.3.1 -
Hi, pppfsense
I had the same - took aeons, but updated successfully. If you have huge fanbase, huge trafficsurge, so need much bandwith, what do you do:
You buy more. So, where does the money come from? think…And also this: Every single update i did on my pf-boxes allways (yes, i go with the 100% here, a very seldom but honored, valued 100%) went through, even remote, since i use pf, on first days and also later (second and thirday max).
Don't know what happend with yours, but from my end, it looks good here - you might want to consider your statement about robustness and testing...
And yes, with zyxel, sonicwall fortigate cisco .. name em...and so on, it can happen (too) now and then - even got briked several times, and payed for several times (resp. customers paid for). That why i ended up here.
