Got it. Thank you so much for the help.

@cmb: @marvosa: Very interesting….  I, however, did not modify any update settings. System>Firmware, Updater Settings tab, you had "Use an unofficial server for firmware upgrades" set and a URL there. Often it's left over from when someone wants to follow snapshots. Then that config is restored to new hardware that's then running 64 bit, and on the next upgrade it obeys your update URL there and switches you to 32 bit. That setting no longer exists in 2.3, but verify it on other pre-2.3 systems before you upgrade. It's impossible to change architectures via auto-update if that box isn't checked. I've been running PFsense since 2009 on v1.2.3 and can tell you without a shadow of a doubt that I have never upgraded to a Alpha/beta/RC/Dev release ever, so there would've been no reason for the auto-update url to be on anything but default as I only run stable releases. Your explanation for how this issue could happen is completely rational, understandable and fits in the OP's case…. but I'm just saying if that is indeed what happened, the setting must have been flipped by some other process in the system because the auto-update URL was never modified manually in my case.

Finally we managed to sort things out. So conclusion it is possible to do this kind of configuration without paying hundreds of dollars to Haproxy. We are testing it at the moment to see if there is any problems.

@NOYB: @bblacey: Well, right about now, I am feeling about as stupid as one can… Been there done that.  Wash, rinse, repeat. Haha yup. Glad it worked out, bblacey!

I've had this issue, uploading the old config .xml backup resolved the issue. I didn't spend any time looking for the issue cause.

It's the same installer whether you do it from memstick or ISO. There isn't an upgrade ISO vs. a new install one. Definitely want to use 64 bit.

@tgharold: Not 100% true. It is true for valid configs. Your <ipaddrv6>FE80</ipaddrv6> isn't valid, that's not link local, it's a string that isn't a valid IP. Not permitted by the GUI and never has been at least in release versions. That was either manually edited into the config, or around from an early pre-2.1.0 beta version before all the proper input validation was in place. Packages that no longer exist can be edited out, but that's not strictly necessary. The worst you end up with there is log spam when restoring to a clean install. In 2.3.1, those are automatically uninstalled pre-upgrade, then those that still exist are reinstalled post-upgrade. If restored to a clean 2.3.0+ version, it'll just log that it can't reinstall packages that are missing. If they had cron entries in the config, those may need manual removal.

@tgharold: The workaround is to change those <ipaddrv6>FE80</ipaddrv6> to just <ipaddrv6>without the FE80 portion and then restore the configuration file.</ipaddrv6> only way that happened is if you manually edited that into the config to begin with. That's not a valid IPv6 address, and the GUI's input validation won't accept that.

you can try https://forum.pfsense.org/index.php?topic=105399.msg588219#msg588219 https://forum.pfsense.org/index.php?topic=105399.msg588787#msg588787

At the console, get to the shell (option 8) and /etc/rc.conf_mount_rw Then you should get better response from the webGUI. Disable the dashboard automatic update checks. Diag->nanoBSD set the system to permanent RW. Then (if convenient) reboot and check that it comes back RW and the dashboard/webGUI feels happier.

You decompressed then hashed. The published hash is on the .iso.gz file.

@jim0266: Running ALIX 2.3 with the same symptoms as Gloomrider. I cannot even get to the System>Update page. After about 3 minutes the page times out with a 504 Gateway Time-out. Diag>NanoBSD, switch to permanent rw.

Are you entering the keystrokes through the serial console? Or are you trying to use a physical keyboard? When using a serial console image, input would come from the serial terminal PC and not from a keyboard attached to the target device.

Just run a backup from your physical box (Diagnostics\Backup/Restore), edit the config file to allow for the possibly different NIC device IDs and import into a fresh install on your VM environment. So yeah, it's an OK idea.

The stack trace is entirely unhelpful! But maybe you are hitting a divide-by-zero problem that is fixed by: https://github.com/pfsense/pfsense/commit/883777874d3064fc9730a0d7e870bf0bc991ae0c and https://github.com/pfsense/pfsense/commit/6f069e921c0a2aabe66ee069c20148b4fcbb0918 Try putting the latest status_queues.php on your system. Or even update to 2.3.1-DEVELOPMENT to get all the good stuff that has been fixed since 2.3-RELEASE.