Hosted on Cent OS7: I am trying to upgrade from 7.9.2 to 7.9.5 using the built in upgrade wizard. As soon as I go into the wizard, it begins on step 5: Confirm Layouts. I am unable to start at step 1. Is there any way to force the update to start at step 1 as would be expected?
Thank you!
Hi, that is strange…
you can try
Renaming the upload/upgrades folder to something different. This will eliminate left-overs from previous upgrades and make SuiteCRM recreate it. (later you can delete the renamed folder, when you are sure it’s safe).
Checking suitecrm.log and upgradeWizard.log for errors.
So I tried renaming both the upload, as well as the upgrades folder. Then I clicked on the upgrade wizard once again. Once again, it took me right to step 5. It did however re-create the upgrades folder as you said it would.
Contents of upgradeWizard.log from today are:
Wed, 20 Sep 2017 12:50:59 +0000 [UpgradeWizard] - setting session variables...
Wed, 20 Sep 2017 12:50:59 +0000 [UpgradeWizard] - Upgrade Wizard At Layout Commits
Wed, 20 Sep 2017 12:50:59 +0000 [UpgradeWizard] - Layout Commits about to show selection table
Wed, 20 Sep 2017 12:52:03 +0000 [UpgradeWizard] - setting session variables...
Wed, 20 Sep 2017 12:52:03 +0000 [UpgradeWizard] - Upgrade Wizard At Layout Commits
Wed, 20 Sep 2017 12:52:03 +0000 [UpgradeWizard] - Layout Commits about to show selection table
Wed, 20 Sep 2017 12:52:08 +0000 [UpgradeWizard] - setting session variables...
Wed, 20 Sep 2017 12:52:18 +0000 [UpgradeWizard] - setting session variables...
Wed, 20 Sep 2017 12:52:18 +0000 [UpgradeWizard] - Upgrade Wizard At Layout Commits
Wed, 20 Sep 2017 12:52:18 +0000 [UpgradeWizard] - Layout Commits about to show selection table
Wed, 20 Sep 2017 12:53:40 +0000 [UpgradeWizard] - setting session variables...
Wed, 20 Sep 2017 12:53:40 +0000 [UpgradeWizard] - Upgrade Wizard At Layout Commits
Wed, 20 Sep 2017 12:53:40 +0000 [UpgradeWizard] - Layout Commits about to show selection table
Contents from today from install.log are:
2017-03-20 12:20:26...installerHook: Could not find custom/install/install_hooks.phpYou shouldn’t rename the entire “upload” folder, only the “upload/upgrades” subfolder, like I told you.
The upload folder contains other stuff, like images and document attachments you’ve uploaded.
Can you try a Quick Repair and Rebuild? And any other repairs on the list that sound remotely related to caching.
And maybe try from another browser, there seems to be something stuck in your process and it could be some caching issue.
Thank you. I renamed upgrades as you said, then did a quick repair and rebuild, as well as other rebuilds that mentioned caching in the name. I also tried another browser completely, and then just for good measure, from another computer/browser altogether. Still goes right to step 5. Does it matter if I have the old SuiteCRM-7.9.2.zip file in the upload folder? Contents of upload below.
drwxrwxr-x. 9 apache apache 4096 Sep 20 09:15 .
drwxr-xr-x. 18 root root 4096 Sep 20 08:53 ..
-rw-r--r--. 1 apache apache 16285 Apr 5 15:39 3f39ff7a-0442-d38f-045b-58e5471b4cd9_photo
-rw-r--r--. 1 apache apache 215254 Mar 14 2017 bec55509-8c7b-d841-c962-58c836d77d95_photo
-rw-r--r--. 1 apache apache 2603 Mar 14 2017 ccd63fb9-7359-7d46-2639-58c83511e742
-rw-r--r--. 1 apache apache 13329 Jul 14 08:13 f1b802e4-98ac-fd7b-6832-58caa6d03560_photo
drwxrws---. 2 apache apache 4096 Mar 16 2017 import
-rw-r--r--. 1 apache apache 19324 Mar 16 2017 IMPORT_Account_1
-rw-r--r--. 1 apache apache 32558 Mar 16 2017 IMPORT_Contact_1
-rw-r--r--. 1 apache apache 56806 Mar 15 2017 IMPORT_Lead_1
-rw-r--r--. 1 apache apache 11999 Mar 16 2017 IMPORT_Opportunity_1
-rwxr-xr-x. 1 apache apache 56 Feb 27 2017 index.html
-rw-r--r--. 1 apache apache 44977017 Jul 18 20:55 SuiteCRM-7.9.2.zip
drwxrws---. 2 apache apache 33 Mar 14 2017 tmp_logo_company_upload
drwxr-x---. 7 apache apache 69 Sep 20 09:15 upgrades
drwxr-x---. 7 apache apache 69 Sep 20 08:53 upgrades.bak2
drwxr-x---. 7 apache apache 69 Sep 20 09:08 upgrades.bak3
drwxr-x---. 7 apache apache 69 Sep 20 09:12 upgrades.bak4
drwxr-x---. 7 apache apache 69 Mar 17 2017 upgrades.bakup
It doesn’t hurt to remove the installation zip from there, or rename it so it doesn’t have zip extension anymore. I know the installer scans for zips, though I would expect it to be only under upload/upgrades.
Maybe we can try some more generous permissions, and add the sticky bit.
Try (from your root of SuiteCRM)
chmod 2775 upload
And delete upload/upgrades directory once again, the retry.
If that still doesn’t work, I wonder if the installer “step” might be saved somewhere in the database, and it’s left in an inconsistent state from something that went wrong earlier…
Did all of those steps. Still goes right to step 5. I think you’re on to something…maybe it is stored somewhere in the DB. I do see 1 entry in the upgrade_history table in mysql. It refers to the old upgrade I did. There is a column names “installed” and it is set to 1. I would make a guess that means it was marked as successfully installed, but that’s only a guess.
The strange thing is, I don’t remember having this issue last time. The upgrade appeared to complete successfully last time.
It’s not in the database, but in a file
But that is located in
upload/upgrades/temp/upgrade_progress.php
so it should be cleared when you deleted the entire directory. But have a look at that file, check it’s permissions and ownership, etc.
Another thing: I checked my upgrade_history table in the database and all rows have a “status” column filled with the value “installed”.
I mistyped on the one post. I have an enabled column, that is set to 1 for the last upgrade. I also have a status column that is set to installed.
Also, I do not have the upload/upgrades/temp/upgrade_progress.php file. In fact, there is not temp file at all under the upload/upgrades/ directory.
I don’t have that temp directory either, it’s probably… temporary.
Maybe you have it while you are within the wizard? But I don’t know.
I’m running out of ideas. Unless you are a developer and are able to debug the code by stepping through it with a debugger…
Did you ever play with Silent Upgrades? If you did, maybe something needs cleaning up. If you didn’t, maybe you could try that now.
Ok, finally got this figured out. The solutions was similar to your original instruction to delete the upgrade folder. However, the folder was not at the path suggested. The upgrade folder that I deleted this time was /var/www/html/cache/upgrades. Deleting this folder, allowed the upgrade to proceed as normal.
Thank you for your help on this. You definitely led me down the right path.
BTW, I’ve been reading through your blog for the past couple weeks. Nice to talk to the author. 
Thanks again.
Glad you sorted things out.
It makes sense to clear that cached folder, I just wonder why the repairs didn’t take care of that. Oh well…
Yeah, I’ll add this to my notes in case it happens again on the next upgrade.
Thanks again.
I have a similar situation with upgrade from 7.9.1 --> 7.9.5 I get a blank screen during upgrade with no progress after that and logs show the following. (I have tried posting as a separate posting with no success) Can you help and point me in the right direction?
Wed, 20 Sep 2017 11:45:23 -0400 [UpgradeWizard] - setting session variables…
Wed, 20 Sep 2017 11:45:30 -0400 [UpgradeWizard] - [At end.php]
Wed, 20 Sep 2017 11:45:30 -0400 [UpgradeWizard] - About to repair the database.
Wed, 20 Sep 2017 11:45:44 -0400 [UpgradeWizard] - database repaired
Wed, 20 Sep 2017 11:45:44 -0400 [UpgradeWizard] - Start Rebuilding the config file again
Wed, 20 Sep 2017 11:45:44 -0400 [UpgradeWizard] - Finish Rebuilding the config file again
Wed, 20 Sep 2017 11:45:44 -0400 [UpgradeWizard] - Begin upgrade_connectors
Wed, 20 Sep 2017 11:45:44 -0400 [UpgradeWizard] - End upgrade_connectors
I have run into that similar problem before. It is most of the time related to incorrect permissions. Make sure that apache has the proper permissions on the entire SuiteCRM directory.
Let’s not hijack this thread.
Let’s all continue this on the other thread