2.1-release [Update - Success]
-
Just started a series of updates on some of the production systems (2.0.3 –> 2.1-release)
Thus far nothing bad seems to be happening and all is well.
I wonder if others are also crazy enough to do this kind of updates, remotely, on a Sunday afternoon, and having only an out-dated config backup that was made half a year ago ;)enjoy your sunday
-
It's never a good idea to do an upgrade without getting a backup first. :) We frequently hear about situations where systems fail after upgrade, because of a hardware failure that prevents it from booting, no problem with the software.
I upgrade systems on every corner of the planet many times every week. I've only bricked one production firewall, and that was because the RAID card flipped out after the reboot (it had ~3 years uptime, was an ~8 year old server) and it refused to complete POST. Dead RAID card, but no problem until a reboot. I've heard of cases from other customers where a system was up for a long period, and after a reboot the disk was so dead it was unbootable.
That's really the only reason why it's occasionally dangerous to upgrade remotely, because things go wrong with hardware after a reboot sometimes. Most of those scenarios are people using really old hardware, and it's relatively uncommon, but it happens more than I would have thought a few years ago.
-
Yep, I have done 2 test then another 6 Alix systems over VPNs today. Most were already running the Sep 8 2.1-RC2 snap, which was almost the same as 2.1-RELEASE anyway. And these updates have been going fine by remote control for a while now. Of course, I have a current config backup of each of them:)
At first, the dashboard told me "You are on the latest version". Now they all tell me "Unable to check for updates". It takes ages to show the System, Firmware, Updater Settings. When it finally displays (maybe 2 minutes) the first dropdown box that is normally there is not shown. So looking up somewhere to get that list of firmware options/architectures is timing out for some reason.
Addendum: I guess this is related to the other post, where cmb is fixing stuff on the update server.
I did some by auto update some time ago (2G nanobsd) and some by manual update with a local copy of the update file downloaded from one of the mirrors. Both were OK for me. -
The auto update is hanging seriously and I cannot find Jimp's post on the retired 2.1. Snapshot Problems Forum on the settings to put in AFTER we upgrade to 2.1 Release.
Downloading the 2.1 Release file and doing a manual update works fine.
CONGRATS AND THANKS TO ALL THE PFSENSE DEVELOPERS FOR A GREAT JOB!
-
I cannot find Jimp's post on the retired 2.1. Snapshot Problems Forum on the settings to put in AFTER we upgrade to 2.1 Release.
It is here: http://forum.pfsense.org/index.php/topic,66457.0.html
-
No problems at all to report on an upgrade from 2.03 to 2.1 RELEASE using a NanoBSD 2G image on an ALIX 2D3 board on a 4GB Compact Flash card. Worked perfectly using the WebGUI's manual firmware upgrade page.
Thanks for all your continued hard work on this project! I bought a gold membership today for our company under a different username (it wouldn't let me log into the portal using my current forums name). The new book is a very welcome value-added item for the membership!
-
Successful upgrade on an Atom D525 (Jetway NF99).
Minor issues:
- Diagnostics -> System Activity page is stuck at "Gathering CPU activity, please wait…"
- System -> Firmware page, the Update Settings tab hangs.
That's it for now, will have more to report as it happens.
-
- System -> Firmware page, the Update Settings tab hangs.
This is due to the Update server being down.
-
I've made a successful upgrade (Alix 2D13, 4G flash) from 2.0.3 (4g) to 2.1 via manual update, with the upgrade process handling my configuration upgrade.
After reading the release notes, I don't see anything about needing to reinstall packages … but my package list is now empty, resulting in errors like the following:
Status->OLSR:
Warning: fopen(/usr/local/pkg/olsrd.xml): failed to open stream: No such file or directory in /etc/inc/xmlparse.inc on line 175 Warning: Invalid argument supplied for foreach() in /usr/local/www/pkg_edit.php on line 435
Firewall->pfBlocker:
Warning: fopen(/usr/local/pkg/pfblocker.xml): failed to open stream: No such file or directory in /etc/inc/xmlparse.inc on line 175 Warning: Invalid argument supplied for foreach() in /usr/local/www/pkg_edit.php on line 435
This effect appears to be similar to the one reported in April 2012 during the -RC process, for which a fix was apparently pushed then.
http://forum.pfsense.org/index.php/topic,48373.msg255424.html#msg255424
I will reinstall my packages to see if that cures the problem.
UPDATE:
I see that pfBlocker is only supported on 2.0.I'm not sure why OLSR (which I do not use) is producing its error.UPDATE: pfBlocker works fine on 2.1. My issue is likely because of only having 256M of RAM in my Alix, as phil.davis noted. The workaround is to simply reinstall your packages.
-
UPDATE: I see that pfBlocker is only supported on 2.0.
Hmmm? Using it on loads of 2.1 boxes for quite some time. Incl. nanobsd ones.
-
No widescreen package anymore for 2.1?
-
UPDATE: I see that pfBlocker is only supported on 2.0.
Hmmm? Using it on loads of 2.1 boxes for quite some time. Incl. nanobsd ones.
Whoops – I thought only 2.0 was supported because the local Packages list (pkg_mgr.php) lists the supported platform as "2.0". Perhaps that should read 2.x? Do the package maintainers have to update their own compatibility lists themselves (like Firefox extensions)? If so, I guess there will be a trickle of updates coming now that 2.1 is out.
All that being said, my pfBlocker was broken by the upgrade. In /var/log/system.log, I can see that pfBlocker tried to refresh its blocklists on boot after the upgrade, but the fetches all failed, zeroing out the lists in /var/db/aliastables. This rendered my pfBlocker useless upon upgrade from 2.0 to 2.1. The pfBlocker GUI is also unavailable, throwing the error mentioned earlier in the thread.
I suspect that a reinstall of pfBlocker will fix the issue -- but this is something that some sites will need to be operationally aware of, because it could impact their security posture.
UPDATE: My local pfBlocker customized lists have also been zeroed out. That's a big bummer. I backed up my pfSense config, but did not back up these files. :( My own fault, but it does seem like a POLA violation.
UPDATE: The zero-length files in /var/db/aliastables have no effect on pfBlocker's storage of local lists, so my lists are actually still intact. Whew!UPDATE: Be aware, however, that if you have 256M like I do, pfBlocker may not carry forward after an upgrade. Until you reinstall it, your blocklists (both stock and customized) will be inactive.
-
During the 2.1-RCn sequence, I often ended up with no packages installed after upgrading to a new snapshot. That was due to memory shortages on the 256MB Alix platform, and I often got "killed" problems. Fix is to install the packages yourself after the upgrade.
Curiously, all the 8 upgrades to 2.1-RELEASE that I did today have reinstalled the packages correctly and come up running first time. Why is this? - just dumb luck, or maybe something in the "disable state killing" change in 2.1-RELEASE has helped. I guess now the package file downloads can chug away happily without having their state killed while other site-to-site OpenVPN links are coming up… Anyway, that has definitely been a good thing for me so far. -
Whoops – I thought only 2.0 was supported because the local Packages list (pkg_mgr.php) lists the supported platform as "2.0". Perhaps that should read 2.x? Do the package maintainers have to update their own compatibility lists themselves (like Firefox extensions)? If so, I guess there will be a trickle of updates coming now that 2.1 is out.
Uhm… whatever's visible in the packages list should to at least some degree work on 2.1. The number in there is supposed to be the minimum required version. Now of course, there are tons of packages untouched for years, the alpha/beta/stable etc. does not really mean anything usually, plus generally the thing could do with quite a bit of cleanup.
No idea about your upgrade troubles, the packages survives just fine on snapshot updates. (Requires manual onetime saving of any lists after upgrade to fetch the lists, unless you want to wait for the cron to trigger it.)
And yeah, reinstall the packages should sort everything out, worst case.
-
During the 2.1-RCn sequence, I often ended up with no packages installed after upgrading to a new snapshot. That was due to memory shortages on the 256MB Alix platform, and I often got "killed" problems.
We recently changed things so APC isn't enabled unless you have at least 512 MB RAM. That frees up a chunk of RAM with an ALIX, and might be enough it prevents that scenario for you.
-
Successful upgrade on an Atom D525 (Jetway NF99).
Minor issues:
- Diagnostics -> System Activity page is stuck at "Gathering CPU activity, please wait…"
- System -> Firmware page, the Update Settings tab hangs.
That's it for now, will have more to report as it happens.
For me just the CPU activity part and the traffic graph not showing the IP info for now…
-
-
Have the same board as you D525 and everything is working just great at least for me…
-
Just updated a pair of live production CARP boxes. Smooth upgrade so far. Many thanks to all who contributed to pfsense.
-
ALIX2D13 - upgraded from 2.0 to 2.1 and have now lost all installed packages in the list. Clicking on items such as Avahi in the Services tabe result in an error.
I saw nothing in the upgrade guide / release notes that said I would lose all packages.