2.0.1 -> 2.0.2 Update Issues

jimp

That's the i386 update url.

The amd64 update url ends with amd64/

tim.mcmanus

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. :)

jimp

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.

tim.mcmanus

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.

biggsy

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.

![2012-12-22 08-46-00.png](/public/imported_attachments/1/2012-12-22 08-46-00.png)
![2012-12-22 08-46-00.png_thumb](/public/imported_attachments/1/2012-12-22 08-46-00.png_thumb)

Guest

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 amd64

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

jimp

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.

Guest

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.

jimp

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.

Guest

Just reverted back to i386 2.0.2 via the firmware update page. thanks

michaelvv

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

Jon

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

jimp

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.