New Installation / Database Schema Update 2013061000 Fails

[LeeThompson]

Prerequisites

• I have searched for duplicate or closed issues
• I can recreate the issue with all plugins disabled

Describe the issue

This is using the roundcube/roundcubemail:latest docker image installed today.

I setup MariaDB (MySQL compatible) and linked Roundcube to it.
I created the database as per the Roundcube's Github Wiki instructions (CREATE DATABASE roundcubemail CHARACTER SET utf8 COLLATE utf8_general_ci;)

When I started Roundcube's container up it connects to the database and starts working on the schema, but then fails for some reason and errors out.
Since it doesn't actually say what happened, it's impossible to troubleshoot this.
The docker hub distribution does not include a sql file with the schema, I'm going to download the regular distribution that includes it and hope I can recover that way.
Currently, out of the box, this doesn't seem to work with MySQL type installations.

2024/08/15 19:22:53 | stdout | Updating database schema (2013011000)... [OK]
2024/08/15 19:22:53 | stdout | Updating database schema (2013042700)... [OK]
2024/08/15 19:22:55 | stdout | Updating database schema (2013052500)... [OK]
2024/08/15 19:22:55 | stdout | Updating database schema (2013061000)... [FAILED]
2024/08/15 19:22:55 | stdout | ERROR: Error in DDL upgrade 2013061000: [1146] Table 'roundcubemail.cache' doesn't exist

What browser(s) are you seeing the problem on?

No response

What version of PHP are you using?

7.2 (whatever is in the official docker image)

What version of Roundcube are you using?

1.6.8

JavaScript errors

No response

PHP errors

No response

[alecpl]

Looks like it executes db schema upgrade instead of initialization, but I have no clue about docker images.

@pabzm I lost ability to transfer issues to roundcubemail-docker repo.

[pabzm]

@LeeThompson Please try with an up to date image. If the problem still exists, please show us more details about how you connect the containers, and the full log output.

@alecpl I'm not aware of any changes in this regard. Do you happen to know which setting this might be due to?

[LeeThompson]

@pabzm I am afraid I got it working by getting a hold of the schema files setting up the database using phpMyAdmin by hand so my installation no longer has this issue. It should be easy enough to test, though, just do a clean docker container setup.

[pabzm]

@LeeThompson Actually the instructions in the wiki do tell that you have to initialize the database like you did later.

And using fresh setups following the examples or docs I cannot reproduce this problem – only by using a manipulated DB.

Following the code brings me to the understanding that you somehow must have created a table system, but didn't populate it – the container entrypoint calls bin/initdb.sh with --update, so that script looks into the database if there's a system table, and only if so runs the DB update code, which fails because it expects a pre-populated DB.

Does that ring a bell?

Either way, this hasn't got much to do with using containers, I think.