2.3.b.20160326.1954 Not g2g?
-
Updated from 2.3-BETA (amd64) built on Thu Mar 17 13:01:48 CDT 2016
to
2.3.b.20160326.1954 via the GUI.Got a normal boot up and received a WAN IP with no errors. Unable to connect to GUI again and no connection to internet.
Reverted back to the 17th Snap by memstick and was back in business.
Anyone else having a problem with the snap from the 26th?
Is the Traffic Shaper still causing issues? I'm using the Traffic Shaper by Interface (Codelq) and the Limiter function as well.
-
I upgraded our production and test systems to that snapshot today, no issues.
The shaper issues are largely resolved, and I don't believe they would impact codelq. Wouldn't make the GUI completely unusable regardless.
Going to need something more to go on. SSH in and get logs, see if php-fpm and nginx are running, does option 11+16 at console bring back the GUI, anything else you can provide.
-
Restarting both option 11 and 16 worked for me in console menu but internet was still unavailable with this workaround. Had to use ip address, then restart dhcp, gateway monitoring, ntp, and dns at gui; although UPnP was the only one that was stopped and would not start at all (unlike the others). Can confirm that once the CE started (March 25 snap) the problem exist.
-
Having spoken with crisdavid, he stated to me he is also using the Traffic Shaper and Limiter function as well so it would appear something is blocking both our systems from running properly while an older snap resolves all issues. Apparently with a clean config, the system can run fine but once a config is uploaded with traffic shaper and limiter options set then pfSense loses connectivity to GUI and internet.
I'm currently running the Limiter as setup in this post
https://forum.pfsense.org/index.php?topic=63531.0
and a simple Traffic Shaper for WAN and LAN with CODELQ setup as the Scheduler Type.
-
As stated above; pfSense 2.3 beta running the latest version runs fine on a clean install or upgrade. Once you start to create a queue in the traffic shaper or either upload a config file with a set queue though. Pfsense then throws up an error as such (refer to first attachment).
When uploading a config file now; upon booting pfsense the following error will be thrown on the console(refer to second attachment). pfSense will now be unable to provide the GUI interface as DHCP, UPnP, Gateway Monitoring, and before (unsure now)DNS Resolver have not started. Refer to the third Attachment.
At the console you'd select option 16 to Restart PHP-FPM and option 11 to restart webConfigurator. Now you can access the web GUI using the ip address of the LAN interface. The only problem is that now UPnP will never start back up and I unfortunately don't find anything noticeable in regards to any issues on starting up in the logs.
I have the Same configuration as AhnHEL. I'm also running this pfSense instance on a VirtualBox virtual machine; as this shows the exact problems I had when running the same build on my physical pfSense Box before. I have now had to reverting back to the stable release 2.2.6 prior to having learned of all of this. Now you can revert back before you made the changes to the traffic shaper or restore to a previous config file you have and just exclude traffic shaper. Only now you lose your configuration and the functionality of traffic shaper you have set up.
I will include attachments of the crash reports down below as well and have already sent to the development team.
-
There were some changes there today, but not fully verified yet. Is that the most recent that's currently available?
-
Snap from early this evening:
Crash report begins. Anonymous machine information:
amd64
10.3-RELEASE
FreeBSD 10.3-RELEASE #489 51f8df0(RELENG_2_3): Mon Mar 28 16:41:34 CDT 2016 root@pfs23-amd64-builder:/usr/home/pfsense/pfsense/tmp/obj/usr/home/pfsense/pfsense/tmp/FreeBSD-src/sys/pfSenseCrash report details:
PHP Errors:
[28-Mar-2016 18:00:42 America/New_York] PHP Fatal error: Call to undefined method dnqueue_class::SetRoot() in /etc/inc/shaper.inc on line 3525
[28-Mar-2016 18:00:42 America/New_York] PHP Stack trace:
[28-Mar-2016 18:00:42 America/New_York] PHP 1. {main}() /etc/rc.bootup:0
[28-Mar-2016 18:00:42 America/New_York] PHP 2. filter_configure_sync() /etc/rc.bootup:268
[28-Mar-2016 18:00:42 America/New_York] PHP 3. filter_generate_dummynet_rules() /etc/inc/filter.inc:293
[28-Mar-2016 18:00:42 America/New_York] PHP 4. read_dummynet_config() /etc/inc/shaper.inc:4706
[28-Mar-2016 18:00:42 America/New_York] PHP 5. dnpipe_class->add_queue() /etc/inc/shaper.inc:4598
-
Snap from early this evening:
Those line numbers show it's prior to Monday's changes. gitsync or upgrade again and give it another shot.
-
Those line numbers show it's prior to Monday's changes. gitsync or upgrade again and give it another shot.
Can confirm that updating to the latest snapshot (March 29th 01:50) resolved this issue for me. Updated using a memstick from 2.2.6 to 2.3 beta snapshot (March 17th) then updated from GUI to the latest snapshot (March 29th 01:50). Although ntp was not started on boot and after trying to start it the second time from the GUI it started and everything seems to be going well afterward.
Thank you for assisting in this issue ;D
