Upgrade failed - issue unclear?

stilez

Possible diagnostic info below:

From the package installer GUI:

>>> Upgrading pfSense-base... 
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	pfSense-rc: 2.3.a.20151223.0535 [pfSense-core]

Installed packages to be UPGRADED:
	pfSense-base: 2.3.a.20151114.0155 -> 2.3.a.20151223.0535 [pfSense-core]

The process will require 727 KiB more space.
24 MiB to be downloaded.
Fetching pfSense-base-2.3.a.20151223.0535.txz: .......... done
Fetching pfSense-rc-2.3.a.20151223.0535.txz: . done
Checking integrity... done (0 conflicting)
[1/2] Installing pfSense-rc-2.3.a.20151223.0535...
[1/2] Extracting pfSense-rc-2.3.a.20151223.0535: . done
[2/2] Upgrading pfSense-base from 2.3.a.20151114.0155 to 2.3.a.20151223.0535...
===> Keeping a copy of current version mtree
[2/2] Extracting pfSense-base-2.3.a.20151223.0535: .. done
===> Removing schg flag from base files
===> Extracting new base tarball
tar: Failed to set default locale

GUI and upgrader seems to have then failed/died 'silently'.
Nothing further displayed; 2nd session showed no evidence of background activity related to background install activity

From the GUI PHP crash reporter:

[27-Dec-2015 20:33:35 Europe/***] PHP Stack trace:
[27-Dec-2015 20:33:35 Europe/***] PHP   1\. {main}() /usr/local/www/pkg_mgr_install.php:0
[27-Dec-2015 20:33:35 Europe/***] PHP   2\. require() /usr/local/www/pkg_mgr_install.php:66
[27-Dec-2015 20:33:35 Europe/***] PHP Fatal error:  require_once(): Failed opening required 'classes/autoload.inc.php' (include_path='.:/etc/inc:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg:/usr/local/www/classes:/usr/local/www/classes/Form') in /usr/local/www/guiconfig.inc on line 85
[27-Dec-2015 20:33:35 Europe/***] PHP Stack trace:
[27-Dec-2015 20:33:35 Europe/***] PHP   1\. {main}() /usr/local/www/pkg_mgr_install.php:0
[27-Dec-2015 20:33:35 Europe/***] PHP   2\. require() /usr/local/www/pkg_mgr_install.php:66

Filename: /var/crash/minfree
2048

I can easily open the 'classes/autoload.inc.php' file using GUI->Diagnostic->Edit; the file that loads also has the same content as on Github (no truncation, no error on loading).
I can also run the code require_once('classes/autoload.inc.php'); echo "ok\n"; in the GUI command prompt. It works correctly.
So it's not clear whether the error message's significance is as obvious as it first seems.
/var/crash/minfree has size zero.

From the system log and SMART diagnostic GUI:

Dec 27 20:34:18  pkg   pfSense-base upgraded: 2.3.a.20151114.0155 -> 2.3.a.20151223.0535  
Dec 27 20:33:56  kernel   pid 10856 (sh), uid 0: exited on signal 11 (core dumped)  
Dec 27 20:33:19  kernel   (ada0:ahcich3:0:0:0): Retrying command
Dec 27 20:33:19  kernel   (ada0:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error  
Dec 27 20:33:19  kernel   (ada0:ahcich3:0:0:0): READ_DMA. ACB: c8 00 8f 0a c7 40 00 00 00 00 00 00  
Dec 27 20:33:19  pkg   pfSense-rc-2.3.a.20151223.0535 installed  
Dec 27 20:32:54  check_reload_status   Syncing firewall  
Dec 27 20:31:59  php-fpm  ***  /index.php: Successful login for user 'admin' from: 192.*****

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

The report in the log, of a successful upgrade, seems incorrect.
Not clear what to read into the CRC messages, given that the file seems fine (above) and CRC status reports as "PASSED".
DMA/CRC seems to suggest some kind of hardware issue/glitch may have caused the silent failure of upgrade, but hard to go further.

Nonetheless the firmware DOES appear to have had some kind of upgrade, but that raises the question, given the above, whether the code was left in a consistent state, if upgrade was actually 'silently' aborted partway or whatever. Would a partial install/inconsistent state be detected?
For example, the file util.inc contains the updated code at this recent PR: @array_map("unlink", $to_do); which was only committed to Github a few days ago, on 21 December 2015.
But there wasn't any evidence of package reinstall or reboot as usual with a reinstall, etc.

It's hard to know if this is a firmware, hardware, or SMART issue. System is SSD based not HDD if that matters. What should I do to confirm or address SMART/HW as a cause?
Whether or not a SMART/CRC issue, should the failure to trap and report correctly be reported as an issue?
Is there a risk that the system was left in an undetected inconsistent/dirty state, with some upgrade code run (or files installed) and other upgrade code not run (or not installed)?
What other diagnostic info can I grab - from this run or on running it again - that would help? (before I try again or lose relevant logs)
From a practical perspective of trying to upgrade, what should I do at this point?