Having just upgraded from 7.6.x to 7.7 and seeing lots of errors related to strict reporting, now fixed thanks, I decided to check the “upgradewizzard.log” file for the 7.7 to 7.7.1 log, and as well as 1 onscreen error, found a few more. Strangely, or fortunately the log is incremental and shows the results from the 7.6.x to 7.7 and that had no errors.
Anyway on the screen the following was reported:
Warning: Invalid argument supplied for foreach() in /var/sites/c/crm.xyz.com/public_html/modules/UpgradeWizard/commit.php on line 640
no entry in the upgrade log file matches this (any reason for that?)
The only notable thing that happened during the upgrade was after the upload and preflight checks, before the commit, the session timed out (I had a visitor and had to leave my desk for half an hour). Logged back in and continued the upgrade from the commit step onwards, which generated the error. (not sure if the session timeout / auto logged out is critical or relevant?!)
the 2 errors in the log file were:
Thu, 11 Aug 2016 13:22:47 +0100 [UpgradeWizard] - *** ERROR: Schema change script [/var/sites/c/crm.xyz.com/public_html/cache/upgrades/temp/5heOns/scripts/65x_to__mysql.sql] could not be found!
Thu, 11 Aug 2016 13:23:01 +0100 [UpgradeWizard] - *** ERROR: no sugar_version.php file location found! - cannot complete upgrade...
The “sugar_version.php” file does exist in the root directory, so not sure of the problem (permissions are 0644)
The “/cache/upgrades/temp/” is empty post the upgrade so checked the Install zip file and found “/65x_to_mysql.sql” but not the double “_” version, so assume a typo has crept in?
Will this mysql script not running have caused a fatal problem with the database structures from 7.7 to 7.7.1? (ie do I need to roll back or do a fresh install) ?
If any of this should have been posted to GIT please let me know and I’ll put it up there instead.
Thanks, but think you’ve mis understood, “The “sugar_version.php” file does exist in the root directory, so not sure of the problem (permissions are 0644)”
It does exist and is unchanged from original (47 lines, and used a “Diff” to compare 7.1.1 Full install file verse the file on the server root.
So it’s not sorrupt and with permissions 0644 think that can’t be the source of the problem either?
Is there another location the file should be in, or is this an error / typo in the upgrade scripts?
On the SQL error realised that the file in the upgrade zip is in fact empty, so unless the upgrade dynamically populates the file during the process, then am I safe to assume it not running has zero impact?
The SQL error “65x_to__mysql.sql” relates, I think, to this file “65x_to_65x_mysql.sql”, rather than double “" it’s missing the second “65x” between the double "” - Anyone able to clarify this?
The concerning thing is the install was fresh under 7.6.x and then upgraded to 7.7 and finally 7.7.1 so somehwere in the install (I suspect here), or upgrades the permissions were either not setup correctly or were modified … but the only thing that could would be the installer or upgrader.
Could/Should the preflight checks include a permission check?
I have propogated 0755 permissions to all files in this subdomain, if this is incorrect please let me know!
but it depends on the system that you have, usually apach ein ubuntu uses www-data as apache group. Yes the system should have warn you about bad file permissions, I have a batch that I execute every time that I modify/update something in Suite, with the above code. Notice that 755 folder settings.
