I'm following the CLI upgrade process, and ran into the same error reported previously on this forum. My max execution time = 1200, so I'm not sure that's my fix. I'm more than happy to post anything you need.
What versions are you upgrading from and to?
3.9.4 Build 20210118 Going to 3.11
in addition to responding to Howard's question and might be right on target. First line of the debug output says the upgrade is trying to alter a table (change structure of it) ... make sure the DB user in config.php of site has the privliges to do so. And, the later lines suggest an additional plugin you've installed on instance might be incompatible.
Themes are plugins. The default theme for 3.9+> is boost. If you had a 3rd party theme, suggest editing config.php and adding a line to force the site to use 'boost':
$CFG-->theme="boost";
The local_sandbox plugin is an addon also!
Then try the command line upgrade again.
Always advised to do an environment check prior to updating/upgrading any moodle. Site Admin Menu, Server, Environment check ... no reds!
'SoS', Ken
I painstakingly went through every step laid out in Moodle's article on upgrading, so I did do the Environment check ,and all was good to go, no reds.
I will try your fixes, but not sure why the dbuser rights would have changed, and it appears that some tables were created successfully. Why would others fail if it were due to permission? That said, can you guide me on checking that the config.php dbuser 'moodle' has the necessary rights?
I will try your fixes, but not sure why the dbuser rights would have changed, and it appears that some tables were created successfully. Why would others fail if it were due to permission? That said, can you guide me on checking that the config.php dbuser 'moodle' has the necessary rights?
It's not unusual for an update or upgrade to alter tables ... and it's not all that unusual that db user may not have all privs.
Before we fall into what might be a rabbit hole, there are some CLI scripts in admin/cli/ that will provide a lot of info about DB, tables, and columns in those tables. And they use settings from config.php to do so (so it's like checking privs)
In admin/cli/ do a ls and any script that has mysql_ in beginning of the filename, run them. Issuing just php mysql_whatever.php will bring up help screen that shows other options to the script.
'SoS', Ken
There should be the error returned by MySQL/MariaDB before the part of the output you've posted, can you post that too?
It looks like this error concerns the H5P additional plugin mod_hvp (not to be confused with the H5P core plugin mod_h5p). However it looks like this is being installed for the first time, not upgraded. If the Moodle 3.8 site is still available can you check if this plugin is installed and which version?
Also, if this is Moodle 3.11 then it looks like the source code files are out of date as the line numbers in that stack trace don't match the current version. Working backwards:
- admin/cli/upgrade.php call to upgrade_noncore() should be line 202 not 193
- lib/upgradelib.php call to upgrade_plugins() should be line 1929 not 1917
So either you've got an older release of Moodle 3.11 for some reason, or there's some other problem with the Moodle source code you have.
Also: the advantage of using the CLI to upgrade is that the max_execution_time limit doesn't apply, so you don't need to change that.
This error could occur if the mod_hvp tables were present in the database but the mod_hvp plugin wasn't actually installed in Moodle. The upgrade process would try to create the plugin's tables and fail because they already exist. So possibly the fix is to drop (delete) all the mdl_hvp_XXX tables.
If this is the case, you'll need to find out if the Moodle 3.8 site did have mod_hvp installed. If it did then Moodle shouldn't be attempting to create mdl_hvp_XXX tables now. If it didn't then what's the reason for installing the additional mod_hvp plugin when upgrading to Moodle 3.11?
If you do make any database changes, ensure you have a database backup first.