[bitnami/moodle] Use Moodle 4.4, Image show Version 4.4.3, but Moodle show Version 4.4.1

[pleibling]

Name and Version

bitname/moodle/4.4

What architecture are you using?

amd64

What steps will reproduce the bug?

I use in docker compose bitnami/moodle:4.4 and :latest - docker inspect show me image.re.name: 4.4.3-debian-12-r2, but when i log in to moodle and check Version, they show me 4.4.1 Build 20240610.

So i shut down container, docker system prune -a and renew with docker compose pull and start the container. But the stay all the time on the same version.

I need to upgrade, cause there are any critical Security fixes in the new release.

How can i upgrade, did i make mistakes?

What is the expected behavior?

Get updatest to 4.4.3

What do you see instead?

Version 4.4.1 Build 20240610

Additional information

No response

[energyexperts]

I'm having the same issue.

[thiagomennezes]

Me too

[gongomgra]

Hi @pleibling @energyexperts @thiagomennezes,

Thanks for using Bitnami and for reporting this issue. Unfortunately I have not being able to reproduce your issue. I have moved to the bitnami/moodle/4.4/debian-12 folder in our repo, removed all the related images and then run docker-compose up. It has automatically pulled the latest images and started Moodle 4.4.3 without issues. I have checked it via the admin panel and it is mentioned I'm running the correct version

Can you try downloading the images again?

[pleibling]

Hi, thanks for your help. But this doesn't work for me.

I take this:

• docker compose down
• docker system prune -a (delete the moodle Images)
• change docker compose from latest to 4.4-debian-12
• docker compose pull (new images are pulled)
• docker compose up -d
• use other Browser and delete cache

But it doens't work - i hava all the time the same version.

Maybe the files are not refreshed in the local folders (filesystem instead of volumes)?

[gongomgra]

@pleibling can you set docker.io/bitnami/moodle:4.4 for the Moodle image instead of the :4.4-debian-12 tag you are using? I don't think that's one of our images, or at least it is missing some information in the tag format. We also recommend you to ensure you are removing the moodle image from your computer with the docker rmi command.

[pleibling]

Same problem - i do this:

• change docker-compose to docker.io/bitname/moodle:4.4
• docker image ls -a
• docker rmi
• docker system prune -a
• docker compose pull (pull longer then before)
• docker compose up -d
• clear browsercache

Same version like before.

[gongomgra]

@pleibling what does the docker inspect command return?

$ docker inspect bitnami/moodle:4.4 | head
[
    {
        "Id": "sha256:b1d7de3c38fa62aec11ea430c4ac54977421779e7fb2e122330ebc9c9a398d88",
        "RepoTags": [
            "bitnami/moodle:4.4"
        ],
        "Parent": "",
        "Comment": "[{\"created\":\"2024-09-05T00:12:56.503576797Z\",\"comment\":\"from Bitnami with love\"}
(...)

[pleibling]

Looks like this:

[energyexperts]

Hi @gongomgra, I did the same steps of @pleibling and I got the same error. This is my docker inspect:

[ThomasRasmussen]

From my debugging the problem is rather that moodle is installed on a volume after initial version (which copies /opt/bitnami/moodle to /bitnami/moodle.

If I understand the "magic" involved in the run.sh script, it will detect that a version is already installed in /bitnami/moodle and remove /opt/bitnami/moodle and replace the directoy with a symlink to /bitnami/moodle.

From my investigation there is nothing the the moodle scripts that will attemt to perform an upgrade of the files in /bitnami/moodle therefore the image is infact the "new version" however the files that is used is still the old moodle version.

[pleibling]

Ok, so we have to wait until this is fixed - right?

[ThomasRasmussen]

I was "fortunate" enough to be able to just rebuild my env using the latest image... But you might be able to try (in a dev env) to scratch the moodledata volume (which is mounted in /bitnami/moodle) and then it will re-install the moodle files using the new version... BUT I have not tested that.

[pleibling]

Ok, i try this:

• create SnaphotVM
• docker compose down
• cd /docker-data/install/moodle
• cp -R moodle_data moodle_data.save
• cd moodle_data
• rm -R *
• cd
• docker system prune -a
• docker compose pull
• docker compose up -d

This doesn't worked for me. The moodle_data folder is empty and doesn't get the 4.4.3 files.

So i shutdown the container, remove the moodle_data, rename moddle_data.save and restart comtainer - so i went back to my 4.4.1 System.

[gongomgra]

@pleibling thank you for sharing the output. I also think your issue is related to volumes. Can you try to create a database backup of your app data for version 4.4.1, start version 4.4.3 from scratch (with fresh empty volumes) and then restore the database backup into it? Be careful to not override your current information for version 4.4.1 by mistake. Rename the volumes and point them to a different path on your host's filesystem.

[thiagomennezes]

I have followed the steps for backing up and restoring available in https://hub.docker.com/r/bitnami/moodle. I backed up the production volume and database. After, create another container with version 4.5.0. Then I have restored both backups in this new container. The container has updated but data seems to be partially lost. For example, my user is admin is production container with version 4.4.3, but in this new one I lost my privileges.

[gongomgra]

@thiagomennezes I understand that the volume backup that you mention has replaced some of the new Moodle files with the previous ones. Can you try to create a database backup with mysqldump and then restore it in the new instance? For the Moodle files, please try to only move the custom data (like icons, uploads, etc) to the new version filesystem.

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions[bot]]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.