Performed all of the plugin updates. Checked the Environment one last time, and got this:
As yet, the link for more info is empty. Please advise.
What versions of PHP/Moodle do you have and on what platform (planet)?
Is there an environment.xml file in /admin/ of your moodle code?
You should have php extensions for xml and xmlreader as well as libxml.
php -m |grep xml
'SoS', Ken
Follow up ...
using command line and in the code directory, execute:
fgrep igbinary admin/environment.xml
That should return the following:
<CUSTOM_CHECK file="lib/upgradelib.php" function="check_igbinary322_version" level="optional">
<ON_CHECK message="igbinary322buggyversion" />
<CUSTOM_CHECK file="lib/upgradelib.php" function="check_igbinary322_version" level="optional">
<ON_CHECK message="igbinary322buggyversion" />
One more command from same location:
fgrep '$release' version.php
That will/should show with the code you have:
$release = '4.0dev (Build: 20210827)'; // Human-friendly version name
Note the 'bolded' above.
So if your intent is to upgrade whatever version you have of moodle to a 4.0dev version, that igbinary322 version check is right on target but see 'buggy' in there .... uhhh ... not good!
Maybe there will be a new requirement for 4.0 when released for igbinary, but if you are just trying to upgrade code to a supported version ... like 3.11.highest ... you need to acquire the 3.11.highest code.
'SoS', Ken
Thanks for responding Ken, I hoped you would! I apologize for the lack of environment details, I’m under the gun.
I’m @ 3.9.4, trying to get to 3.11 Stable. The error I received occurred from an ‘update component’ on the environment page with 3.11 selected. I had previously gone through several rounds of plugin updates, and was doing one last environment check/plug-in check. So I’m not understanding where 4.0dev comes into this. I am a greenhorn with Moodle/Git though.
3.4.9 Apache/Cent 7
Yes to the environment.xml
Yes to the xml files
fgrep returned nothing
3.9.4 for the $release
I’m @ 3.9.4, trying to get to 3.11 Stable. The error I received occurred from an ‘update component’ on the environment page with 3.11 selected. I had previously gone through several rounds of plugin updates, and was doing one last environment check/plug-in check. So I’m not understanding where 4.0dev comes into this. I am a greenhorn with Moodle/Git though.
3.4.9 Apache/Cent 7
Yes to the environment.xml
Yes to the xml files
fgrep returned nothing
3.9.4 for the $release
Hope you began this update/upgrade by making a minimal site backup of code and DB dump. 'Under the gun' sounds like you did this on production server without first testing on a dev instance/clone of your production. :|
Have a 3.9.highest and just now did environment check and updated component. No such error nor recommendation for igbinary in the check for 3.11.
The only place I can find such a check is in the case of having 4.0Dev code. The environment check updated in my 3.9.highest does list a 4.0 version, but when selecting that, no igbinary check or warning. None for the drop down set to 3.11 either.
Since you are using git, mind describing how you are trying to upgrade from your 3.9.x to 3.11.highest using git? And was the 3.9.x you have originally installed via git?
The actual git commands (hint: command line 'history' command might help you re-call).
Do these commands however ... and share back what you see ...
cd /path/to/moodlecode/
fgrep '$release' version.php
That will show us what version of code you have.
git branch -a |grep '*'
will show what branch your git is currently tracking.
'SoS', Ken
Never! Under the gun, but with smart planning. I did a backup and a dump, but on a test server. I'm trying to keep my process tight so that I can turn right around and upgrade the production server next.
I'm not sure if it was originally updated/installed through Git, this is a project I inherited. As for my process: I go to plugins overview and choose to install updates on all, select 'update moodle database', keep checking until no more updates. Move to Environment check, and select 3.11 in dropdown (4.0 dev was not there until this morning). I stop here because of the error I posted up top. However, before I knew about the 'update component' on the env. check page I thought all items were good, so I proceeded to the CLI upgrade:
$ cd /path/to/your/webroot
$ git clone git://git.moodle.org/moodle.git
$ cd moodle
$ git branch -a
$ git branch --track MOODLE_311_STABLE origin/MOODLE_311_STABLE
$ git checkout MOODLE_311_STABLE
$git pull - which gives me:
remote: Counting objects: 664, done.
remote: Compressing objects: 100% (146/146), done.
remote: Total 664 (delta 479), reused 663 (delta 478)
Receiving objects: 100% (664/664), 142.65 KiB | 0 bytes/s, done.
Resolving deltas: 100% (479/479), completed with 140 local objects.
From git://git.moodle.org/moodle
$release = '3.9.4 (Build: 20210118)'; // Human-friendly version name
git branch -a | grep '*'
* MOODLE_39_STABLE
I'm not sure if it was originally updated/installed through Git, this is a project I inherited. As for my process: I go to plugins overview and choose to install updates on all, select 'update moodle database', keep checking until no more updates. Move to Environment check, and select 3.11 in dropdown (4.0 dev was not there until this morning). I stop here because of the error I posted up top. However, before I knew about the 'update component' on the env. check page I thought all items were good, so I proceeded to the CLI upgrade:
$ cd /path/to/your/webroot
$ git clone git://git.moodle.org/moodle.git
$ cd moodle
$ git branch -a
$ git branch --track MOODLE_311_STABLE origin/MOODLE_311_STABLE
$ git checkout MOODLE_311_STABLE
$git pull - which gives me:
remote: Counting objects: 664, done.
remote: Compressing objects: 100% (146/146), done.
remote: Total 664 (delta 479), reused 663 (delta 478)
Receiving objects: 100% (664/664), 142.65 KiB | 0 bytes/s, done.
Resolving deltas: 100% (479/479), completed with 140 local objects.
From git://git.moodle.org/moodle
$release = '3.9.4 (Build: 20210118)'; // Human-friendly version name
git branch -a | grep '*'
* MOODLE_39_STABLE
If the site was already installed using git and a 3.9.something, one would NOT need to use the following:
$ git clone git://git.moodle.org/moodle.git
$ cd moodle
You've already the code and just need to update or upgrade.
To update
cd /path/to/moodlecode/
git branch -a
php admin/cli/cron.php;
php admin/cli/maintenance.php --enable;
git pull;
php admin/cli/upgrade.php --non-interactive;
php admin/cli/maintenance.php --disable;
The git pull above should show something like (just did this a minute ago):
remote: Counting objects: 4475, done.
remote: Compressing objects: 100% (1900/1900), done.
remote: Total 4475 (delta 2628), reused 3581 (delta 2405)
Receiving objects: 100% (4475/4475), 3.73 MiB | 2.89 MiB/s, done.
Resolving deltas: 100% (2628/2628), done.
From git://git.moodle.org/moodle
c66c1a0..089f5bb MOODLE_39_STABLE -> origin/MOODLE_39_STABLE
3a3060a..3e69001 MOODLE_310_STABLE -> origin/MOODLE_310_STABLE
605ce278..7fdf72a MOODLE_311_STABLE -> origin/MOODLE_311_STABLE
0d0e66d..443a980 master -> origin/master
Updating c66c1a0..089f5bb
Fast-forward
.github/workflows/push.yml | 8 +
admin/environment.xml | 10 +
admin/tests/behat/behat_admin.php | 7 +-
admin/tool/dataprivacy/tests/behat/manage_data_requests.feature | 6 +-
admin/tool/log/stores.php | 2 +
admin/tool/log/tests/behat/logstore_store_visibility_change.feature | 19 +
auth/tests/behat/login.feature | 4 +-
backup/controller/backup_controller.class.php | 9 +
backup/controller/restore_controller.class.php | 9 +
backup/moodle2/restore_stepslib.php | 5 +-
backup/tests/roles_backup_restore_test.php | 179 +++++
backup/util/plan/base_plan.class.php | 13 +
backup/util/ui/tests/behat/duplicate_activities.feature | 6 +-
blocks/site_main_menu/tests/behat/edit_activities.feature | 4 +-
blocks/social_activities/tests/behat/edit_activities.feature | 4 +-
course/tests/behat/activities_visibility_icons.feature | 4 +-
course/tests/behat/activity_navigation.feature | 4 +-
course/tests/behat/add_activities.feature | 19 +-
course/tests/behat/course_relativedatesmode.feature | 13 +-
course/tests/behat/course_request.feature | 6 +-
install/lang/es/install.php | 12 +-
install/lang/fi/admin.php | 1 +
install/lang/pt/admin.php | 4 +-
install/lang/sl/install.php | 1 +
lang/en/admin.php | 1 +
lib/db/access.php | 3 +
lib/tests/behat/behat_general.php | 11 +-
lib/upgradelib.php | 53 ++
mod/feedback/tests/behat/anonymous.feature | 8 +-
mod/h5pactivity/tests/behat/result_fillin.feature | 6 +-
mod/h5pactivity/tests/behat/result_longfillin.feature | 6 +-
npm-shrinkwrap.json | 1422 ++++++++++++++++++++--------------
package.json | 6 +-
report/participation/tests/behat/message_participants.feature | 23 +-
user/tests/behat/user_grade_navigation.feature | 8 +-
version.php | 4 +-
36 files changed, 1224 insertions(+), 676 deletions(-)
create mode 100644 admin/tool/log/tests/behat/logstore_store_visibility_change.feature
create mode 100644 backup/tests/roles_backup_restore_test.php
Note 2 things ... second line of git pull shows it acquired a new environment.xml
admin/environment.xml
and the last line shows an update to version.php
The summary:
36 files changed, 1224 insertions(+), 676 deletions(-)
create mode 100644 admin/tool/log/tests/behat/logstore_store_visibility_change.feature
create mode 100644 backup/tests/roles_backup_restore_test.php
If you did this for a 3.9 site, you should be getting the highest available 3.9 which is $release = '3.9.9+ (Build: 20210902)'
To upgrade an existing 3.9 ... the following shows just one hop up to 310.
php admin/cli/maintenance.php --enable;
git branch --track MOODLE_310_STABLE origin/MOODLE_310_STABLE
git checkout MOODLE_310_STABLE
php admin/cli/upgrade.php --non-interactive;
php admin/cli/maintenance.php --disable;
And then check:
fgrep '$release' version.php
I have a preference for not doing hyperjumps ... skipping versions to a destination version ... but rather 'marching' .... up one version at a time ... checking site/acquiring updates to plugins, site backup again, then next hop.
Takes a little longer, but better me thinks.
'SoS', Ken
git branch -a
MOODLE_310_STABLE
* MOODLE_39_STABLE
master
remotes/origin/HEAD -> origin/master
remotes/origin/MOODLE_13_STABLE
remotes/origin/MOODLE_14_STABLE, etc...
php admin/cli/cron.php;
Server Time: Thu, 02 Sep 2021 10:46:26 -0700
Ran 0 adhoc tasks found at Thu, 02 Sep 2021 10:46:26 -0700
Cron script completed correctly
Cron completed at 10:46:26. Memory used 18.7MB.
Execution took 0.058206 seconds
php admin/cli/maintenance.php --enable
== Maintenance mode (https://elearntest.mcoe.org) ==
Your site is currently in CLI maintenance mode, no web access is allowed.
git pull;
Updating de301d4..089f5bb
error: Your local changes to the following files would be overwritten by merge:
Gruntfile.js
TRADEMARK.txt
admin/cli/mysql_collation.php
admin/cli/mysql_compressed_rows.php
admin/environment.xml
admin/tests/behat/behat_admin.php, etc.....
...
blocks/activity_results/tests/behat/lowscoreswithoutgroups.feat
Aborting
And that's as far as I get. I did not see a /moodle subdir of the wwwroot on production server. I suppose that means it was not upgraded with git. Same was true for test server until I ran the commands I shared earlier with the git clone...
Upon running the second stack of commands I get as far as git checkout... with this result:
admin/tool/log/tests/privacy_test.php
admin/tool/log/upgrade.txt
admin/tool/log/v
Aborting
MOODLE_310_STABLE
* MOODLE_39_STABLE
master
remotes/origin/HEAD -> origin/master
remotes/origin/MOODLE_13_STABLE
remotes/origin/MOODLE_14_STABLE, etc...
php admin/cli/cron.php;
Server Time: Thu, 02 Sep 2021 10:46:26 -0700
Ran 0 adhoc tasks found at Thu, 02 Sep 2021 10:46:26 -0700
Cron script completed correctly
Cron completed at 10:46:26. Memory used 18.7MB.
Execution took 0.058206 seconds
php admin/cli/maintenance.php --enable
== Maintenance mode (https://elearntest.mcoe.org) ==
Your site is currently in CLI maintenance mode, no web access is allowed.
git pull;
Updating de301d4..089f5bb
error: Your local changes to the following files would be overwritten by merge:
Gruntfile.js
TRADEMARK.txt
admin/cli/mysql_collation.php
admin/cli/mysql_compressed_rows.php
admin/environment.xml
admin/tests/behat/behat_admin.php, etc.....
...
blocks/activity_results/tests/behat/lowscoreswithoutgroups.feat
Aborting
And that's as far as I get. I did not see a /moodle subdir of the wwwroot on production server. I suppose that means it was not upgraded with git. Same was true for test server until I ran the commands I shared earlier with the git clone...
Upon running the second stack of commands I get as far as git checkout... with this result:
admin/tool/log/tests/privacy_test.php
admin/tool/log/upgrade.txt
admin/tool/log/v
Aborting
Follow up:
Does it matter if git was not used previously?
Does it matter if git was not used previously?
Does it matter? Yes.
The git branch -a command shows at the top which branch is being tracked ... marked with a *.
In the code directory ... which on centos 7 is probably in /var/www/html/ ... there should be a hidden .git directory.
cd /var/www/html/
ls -ld .git
Inside that hidden directory:
cd .git
ls -l
drwxr-xr-x. 2 root root 4096 Jun 22 2020 branches
-rw-r--r--. 1 root root 338 Jun 22 2020 config
-rw-r--r--. 1 root root 73 Jun 22 2020 description
-rw-r--r--. 1 root root 3339 Sep 2 11:57 FETCH_HEAD
-rw-r--r--. 1 root root 33 Jun 22 2020 HEAD
drwxr-xr-x. 2 root root 4096 Jun 22 2020 hooks
-rw-r--r--. 1 root root 2375232 Sep 2 11:57 index
drwxr-xr-x. 2 root root 4096 Jun 22 2020 info
drwxr-xr-x. 3 root root 4096 Jun 22 2020 logs
drwxr-xr-x. 4 root root 4096 Jun 22 2020 objects
-rw-r--r--. 1 root root 41 Sep 2 11:57 ORIG_HEAD
-rw-r--r--. 1 root root 38716 Jun 22 2020 packed-refs
drwxr-xr-x. 5 root root 4096 Jun 22 2020 refs
Your other posting that aborted and complained about merge would change ... then it listed files ...
Git does track every file ... including it's bite size ... it knows if a file has been edited. So did the former admin hack any core code?
'SoS', Ken
Sent you a private message here in these forums - contains my cell number.
I see that both production and your test instance are in maintenance mode. So is your entity expecting the production instance to be upgraded soon?
Using forums is delayed ... and communications can be behind in sequence ... in this case, a voice call might be 'just in time' support.
'SoS', Ken
Hi.
The same thing happened to me with Moodle 3.10+.When I entered "Environment", Moodle showed no error. But when I clicked on "update component", the error appeared.
Anyway, when I switched to 3.11 or 4.0 the error message disappeared:
So there should be no problem in updating to 3.11
Same here. I did an 'update component' and now see this same error message on the 3.10 branch, where I did not before. Switching to 3.11 and 4.0 and the message goes away.
So, according to this page (https://tracker.moodle.org/browse/MDL-72312), the fact that I'm running 7.4 and installed igbinary 3.2.6, I should not be having this issue. However, this comment a few weeks ago has me wondering, since I'm using this version: https://tracker.moodle.org/browse/MDL-72312?focusedCommentId=871256&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-871256
Hello Brian,
I have the same issue as you and when I change the Moodle version to 3.11 and 4 upwards in the Environment the error disappears can I still go ahead with the upgrade or do I need to clear the error first in version 3.10.1+(Build:20210204).
I have the same issue as you and when I change the Moodle version to 3.11 and 4 upwards in the Environment the error disappears can I still go ahead with the upgrade or do I need to clear the error first in version 3.10.1+(Build:20210204).
Thank you and kind regards,
Eno Otuokon
Hi Eno,
Unfortunately I was never able to find a solution to this problem. I ended up building a new server with 3.11, and migrated my database over.
Hello Brian,
Thank you for the feedback and an alternative solution to the issue. I will rebuild a new server on my test server.
Kind regards,
Eno Otuokon