You are right.
Thank you  :-*

@JorgeOliveira:

Your PHP error messages are incomplete due to a bug that was recently fixed.

Also some of those messages have striking similarity with those here:
forum.pfsense.org/index.php?topic=110698.0;all
by hitting the issue on get_configured_interface_with_descr()

I'd recommend a gitsync to the latest RELENG_2_3 version which contains the following fix:
https://github.com/pfsense/pfsense/pull/2922/files

And applying this, might help as well:
https://github.com/pfsense/pfsense/pull/2925/files

Are these automatic if I’m on the snapshot branch?

@JorgeOliveira:

Do you have any packages installed?

Sure, a whole bunch…
…anything in particular you’re interested in?

It is fixed now… see rm ticket

Still this same phenomenon with Latest Base System 2.3.1.a.20160508.0101.

Due to 2 PID's of dhcp6c [Why?], WAN(igb0) cannot succeed, and/then LAN(igb1) is appointed but not effective.
To get rid of the ISP-IPv6 over igb1, a reboot is necessary.

This time I saw PPPoE(IPv4) was not established. So, is it eventually necessary that IPv6 should wait for IPv4 to finish successfully?

We always do. Even back further, 1.2.3, 2.0, 2.1 and 2.2.x were all tested direct upgrade to 2.3 successfully before release.

It's a matter of catching the specific circumstances that are a problem between versions. All the config upgrade issues are confirmed fixed, and the issues from old package files that may still be on the system is partially fixed.

Check your computer to see if it's transferring 2.5Mb/s?

nano's been there for a while.

Agreed. It is correct as-is. Capital=default action.

Sorry I missed this conversation. I'll address it later tonight.

It was an easy fix. Look for it in the next snapshot.

Scratch that, I had some spare time before escaping for the day so I updated to the development branch and the issue (with growl notifications) does appear to have been fixed. The password field in the webui is still indicating the wrong length (intentionally perhaps?), but it is authenticating correctly and sending notifications.

The fix broke the build of cryptostats so it was reverted. It'll come back once that issue is addressed.

nope

https://forum.pfsense.org/index.php?topic=111150.0

@phil.davis:

That is weird. The code is a foreach over all the interfaces:

foreach ($config['interfaces'] as $if => $ifdetail) {

It could have an "if is_array()" to protect it - that will stop those warning messages - but actually $config['interfaces'] MUST always have at least 1 interface in it. So something is going wrong with the global $config

Exactly what I was thinking.

IMO, the only way for that to ever happen is config.cache to be corrupted for whatever reason, so I've submitted the following PR:
https://github.com/pfsense/pfsense/pull/2925

Additionally, with regards to truncation of crash report, I've submitted another PR:
https://github.com/pfsense/pfsense/pull/2922

You mean the "wrote 3 leases to lease file" part? Probably has a third that dates back prior to your log. Check /var/dhcpd/var/db/dhcpd.leases

@Blade1:

I also notice that the CPU is stuck at 99%.

If you run 'top', or Diag>System Activity in the GUI, what process is chewing up the CPU?

Did you reboot after changing the timezone from UTC? Guessing not, some things will be on the old timezone until a reboot, php.ini among those. If I set my tz to America/Vancouver, and either reboot or run rc.php_ini_setup, I correctly get:

: grep timez /usr/local/etc/php.ini date.timezone="America/Vancouver"

@Steve_B:

Unable to reproduce this. What version are you running?

I can add/move/delete rules anywhere and the separators seem to stay where they belong.

Ditto.

That only tells you if an update is available not if a reboot is required.