Latest snap warning

maverick_slo

DO NOT UPGRADE TO 23 SEPT SNAPSHOT.
IT WILL BREAK THINGS AT LEAST IT DID FOR ME TWICE.

BBcan177

Did you check the syslog logs or resolver log for any error messages?

Not sure if it's the same issue, but on 2.4 DEV, I was always getting a no route to host (try to ping 8.8.8.8 )

After a lot of fiddling, I found that system_gateways.php "Apply" errs when its not in the table… the only way to fix it, is to manually run the route add default command.... Then all worked as expected.

route change -inet default x.x.x.x
```route: route has not been found
change net default: gateway x.x.x.x fib 0: not in table

route add default x.x.x.x

add net default: gateway x.x.x.x

maverick_slo

In my case it pings it ok.
But hosts are not able to get to internet, web iface is not reachable, ping and ssh from local to pfsense box works too.
Weird, I upgraded like 30 times so far but this one broke system completely…

DigitalDeviant

I'm in the same boat. I've downloaded a snapshot from 9.21 but can't figure out how to get the update from console to prompt ne to upgrade from file. Any help would be appreciated.

maverick_slo

It won`t work this way.
You have to:

1. Backup your config file
2. Download full install from here (this one is 64 bit and for me from 21.9. works): https://snapshots.pfsense.org/amd64/pfSense_RELENG_2_3/installer/
3. Install pfsense like first time
4. Restore config and don`t update :)

Full restore from backup or manual install of tgz files is not supported in 2.3.X any more.

jimp

Snapshot from the 22nd is fine, 23rd broken. We're looking into it. Different symptoms seem to be due to PHP or other processes segfaulting at different times, leaving inconsistent parts of the system unconfigured or otherwise not running.

https://redmine.pfsense.org/issues/6813

DigitalDeviant

@maverick_slo:

It won`t work this way.
You have to:

1. Backup your config file
2. Download full install from here (this one is 64 bit and for me from 21.9. works): https://snapshots.pfsense.org/amd64/pfSense_RELENG_2_3/installer/
3. Install pfsense like first time
4. Restore config and don`t update :)

Full restore from backup or manual install of tgz files is not supported in 2.3.X any more.

I was afraid of this. Thanks. Maybe I'll wait and see if it's fixed soon and just do a git update.

jimp

Due to the erratic behavior you might be able to get things working by trying again or varying things slightly.

I was able to get my VM online again by resetting PHP and nginx a couple times and restarting whatever had crashed. It wasn't too far gone, though, and had basic connectivity on that reboot at least.

maverick_slo

So you can replicate and confirm that it is not working as it should?

EDIT:
Sorry was too fast, thanks for confirming :)

JorgeOliveira

I've poked around a bit with 20160923-0440 version and that seems work from my testing. Can anyone confirm that one works on their end?

maverick_slo

Tested on work pfsense too…
Broke that one too, so 2 broken for me

chpalmer

2.3.3-DEVELOPMENT (amd64)
built on Fri Sep 23 11:34:50 CDT 2016
FreeBSD 10.3-RELEASE-p8

Working here.

JorgeOliveira

Confirmed! OpenVPN servers work on 20160923-0440 but not on 20160923-1134.

I'll stick with the working version and gitsync any webGUI updates until this core system issue is sorted.

Edit: Mon Sep 26 09:29:52 CDT 2016 version is working like a charm!

DigitalDeviant

I was able to restore my connection by deleting the openvpn server from my config and rebooting.

jimp

Looks like we have a lead on the source of the problem:

https://svnweb.freebsd.org/base?view=revision&revision=306336

We'll get a new snap built with that soon.

rbgarga

New snaps built today fixed it for me. Please test and let us know.

brianc69

Confirmed. Obvious error and boot problem fixed. Further testing under way.

doktornotor

2.3.3-DEVELOPMENT (amd64) built on Mon Sep 26 09:29:52 CDT 2016 works.

maverick_slo

Yup same here.

doktornotor

I think this whole boot process needs to get whole lot more robust/failsafe. You have /etc/rc.bootup script and almost the entire boot process is plopped into loads of function calls in that one script. When the script crashed somewhere at the top of the calls stack (as happens to be the case with the OpenVPN setup), it rendered the system very much useless.

So, the core of the issue doesn't seem to be resolved at all, can happen anytime again, with amount of breakage depending on how early in the script it happens.

https://redmine.pfsense.org/issues/6813#note-9