Latest snap warning
-
So you can replicate and confirm that it is not working as it should?
EDIT:
Sorry was too fast, thanks for confirming :) -
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?
-
Tested on work pfsense too…
Broke that one too, so 2 broken for me -
2.3.3-DEVELOPMENT (amd64)
built on Fri Sep 23 11:34:50 CDT 2016
FreeBSD 10.3-RELEASE-p8Working here.
-
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!
-
I was able to restore my connection by deleting the openvpn server from my config and rebooting.
-
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.
-
New snaps built today fixed it for me. Please test and let us know.
-
Confirmed. Obvious error and boot problem fixed. Further testing under way.
-
2.3.3-DEVELOPMENT (amd64) built on Mon Sep 26 09:29:52 CDT 2016 works.
-
Yup same here.
-
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
-
The core of this issue was the OpenSSL library problem that has been fixed. There is a separate issue where certain processes crashing can cause failures of the boot script as a whole, but it's not directly related. PHP itself was also crashing out, but neither PHP nor OpenVPN are crashing now like they were when the original problem happened.
It would be great if the process was a lot more robust, with exception handling everywhere to ensure errors are trapped and handled gracefully. That's a much larger task though, not one we're likely to see even in 2.4 at this point.