2.0.1 -> 2.0.2 Update Issues
-
Just updated to 2.0.2 from 2.0.1 a few minutes ago and am receiving the following error:
kernel: interrupt storm detected on "irq19:"; throttling interrupt source
It was working just fine before the update.
Version: 2.0.2-RELEASE (i386) built on Fri Dec 7 16:30:38 EST 2012 FreeBSD 8.1-RELEASE-p13
What's interesting is that the version I have install was"
2.0.1 router (2.0.1-RELEASE (amd64) built on Mon Dec 12 18:16:13 EST 2011 FreeBSD 8.1-RELEASE-p6)
I used the Auto-Update feature in the web UI. It may have a bug in either it's reporting the wrong version (32-bit and not the 64-bit) or the auto-installed deployed the wrong version.
-
ntpd is also down and will not start up.
Dec 21 15:54:11 kernel: pid 19752 (ntpd), uid 0: exited on signal 11 (core dumped)
Dec 21 15:54:11 php: /status_services.php: NTPD is starting up. -
Could be due to the architecture change you made. The full update files are correct on the server, I upgraded using both earlier.
Is this NanoBSD? If so, what size? Full install?
What is your update URL set to in the firmware settings?The default upgrade URL for 2.0.1 was not correct, it was set to the snapshot server which doesn't hold release images. If you manually set an upgrade URL for the wrong architecture, it would just be doing what it was told to do…
-
HI..
Exactly the same happened here , running in KVM , so i rolled back
to my close up to date backup , cause too many problems with
binaries not running anymore..darkstar,snort,squid,squidguard failed.
Trying to update package manual but after a while the system just
started to not route traffic anymore , gave up…/Michael
-
Could be due to the architecture change you made. The full update files are correct on the server, I upgraded using both earlier.
Is this NanoBSD? If so, what size? Full install?
What is your update URL set to in the firmware settings?Not sure of any of this. I grabbed a mirror URL for a full update and am now updating through the console. This was a clean 2.0.1 AMD64 installation, and I usually don't muck around with any settings that I don't need to.
If/when it reboots after the update I'll check these settings.
<firmware><alturl><enable><firmwareurl>http://updates.pfsense.org/_updaters</firmwareurl></enable></alturl></firmware> <gitsync><repositoryurl><branch></branch></repositoryurl></gitsync>No, it was not a NanoBSD update. I usually do full installations on this box. It's got an i3 w/4GB of RAM in it and plenty more headroom for expansion if need be.
-
That's the i386 update url.
The amd64 update url ends with amd64/
-
Not sure how that got that way. I'm not one to change update URLs from their defaults.
I think my upgrade on top of the upgrade failed. I'm going to download the 2.0.1 installer AMD64 installer and do a clean install. I was fortunate enough to not lose network connectivity and could backup my settings and still download the installer images.
After I do the install I'll go check the update URL to see if it's putting the i386 URL there or the AMD64 by default.
Does it make sense for the system to check to see if the URL and packages are correct before installing? I am a pretty good idiot test, so it might make sense to put something in there to make it a bit more idiot-proof. :)
-
Well cross-architecture upgrades are technically (somewhat) supported so it was just doing what it thought you wanted it to do :-)
We don't put a default URL in config.xml, it's determined in /etc/inc/globals.inc and automatically includes the architecture when it figures it out. The user setting overrides that default.
Packages can only be installed from the current architecture as well. So i386 only ever gets i386 packages. But if the old ones were left over from the "wrong" architecture it could cause issues.
-
Well, the 2.0.2 clean install went well. And when I loaded my settings back in it obviously repopulated with the wrong URL. Not sure how that got in there….
But, everything seems to be working okay now.
Note to people like me; validate your update URL (System->Firmware->Updater Settings) before you update. There is no indication on the index.php page that you're getting one or the other update (feature request: Put an idiot message in there for folks like me--Do you REALLY want to update your AMD64 firmware with i386?) :)
Thanks again for the quick replies.
-
2.0.2 update hung during re-install of postfix.
Had to do a clean install of 2.0.2, restore config, delete all packages and re-install.
 -
I used to have the 2.0.1-RELEASE (i386) version on a system, I did the auto update, and now the system is "2.0.2-RELEASE (amd64) "
The full version info is:
2.0.2-RELEASE (amd64)
built on Fri Dec 7 22:39:43 EST 2012
FreeBSD router.tetch.com 8.1-RELEASE-p13 FreeBSD 8.1-RELEASE-p13 #1: Fri Dec 7 23:07:32 EST 2012 root@snapshots-8_1-amd64.builders.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 amd64The cpu type of the system is: Intel(R) Atom(TM) CPU D2550 @ 1.86GHz
Is this version listing info wrong? Did it change versions?
The only problem I have is that Ntop(4.1.0_3 v2.3 ) and squid(2.7.9 pkg v.4.3.1) don't start anymore. -
If you go to System > Firmware, and check the update URL, what does it show?
If you uninstall all the packages and then reinstall them it may be OK, or you may just want to upgrade it again using an i386 firmware.
-
I think I figured my problem out.
I installed an i386 version, I restored settings from another amd64 system, it must've changed the firmware upgrade path.
I'm changing it back to i386 and having to do a manual firmware install update, see if I can do that. thanks. -
Now that you're on 2.0.2 you can uncheck the box on the firmware page to use a different URL. The stock update URL will work correctly for the current architecture.
-
Just reverted back to i386 2.0.2 via the firmware update page. thanks
-
Hi…
Last nigth auto update everything messed up.
Restored my Backup , today manual update amd64 , and
things are working fine....
Will stick with the manuel update in the future , just to
be sure...../Michael
-
I also had a weird issue when using auto update to upgrade a set of firewalls. I upgraded the backup fail over member without issue, but when upgrading the primary the upgrade left a old php module dir in place and caused php to not be able to load any modules after the reload. I had to remove the 2009 module Dir to get the primary server up and running again. It was a odd experience since both of them have had the exact same software/versions installed.
-Jon
-
Sounds like you accidentally upgraded that to a 2.1 snapshot then went down to 2.0.2. There is no way you could have gotten a 2009* php dir from a 2.0.x image.
