Dear Maintainer,

   The redo log was corrupted before upgrade to Debian bullseye. Akonadi would not start.
   see https://debianforum.de/forum/viewtopic.php?f=29&t=181760&start=15#p1280104 (German language)

   I invoked mysql_upgrade to check and repair the MariaDB system tables
-----------------------------------------------------------------------------------------------------------------------------------------------------
bequimao@bullseye-kde:~$ mysql_upgrade --defaults-file=/home/bequimao/.local/share/akonadi/mysql.conf --socket=/run/user/1000/akonadi/mysql.socket -v
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Can't execute 'mysqlcheck'
-----------------------------------------------------------------------------------------------------------------------------------------------------
  NB. I repeated the test in a fresh install of Debian 11 KDE Plasma in a VM (Qemu/KVM) and Debian testing.
      Always had the same error message.

Hello!

This is not a bug in the Debian packaging and not really an upstream bug either.

The error message seems pretty clear:

Before you upgrade, you need to ensure your database shuts down
correctly and cleanly. If it did not shut down cleanly on 10.3.27, you
need to start it again with 10.3.27, let the startup do the error
recovery, and then shut it down cleanly. Only after that can you
attempt to upgrade to 10.5 again.

Please do that and then tell me if you got the database started on 10.5.

The user in the forum has already  recovered his mails and data, so he won't
risk the test.

My point is, that in 2 of my 3 debian installations there are errors in the
MariaDB system tables (see mysql.err). Only the fresh Bullseye installation is
without errors. Akonadi/Contact/KMail works in any case.

Any attempt to check and correct the tables with mysql_upgrade fails, see the
attached files. I tested other distributions, ie openSUSE 15.3 e Fedora 34.
There you can invoke mysql_upgrade as a user without any problem.

Btw. a successful migration should also take care of  the redo logs. The user
normally does not know, whether the database was shut down correctly or not.

Regards,
Ulrich

Maybe they should, or at least take a backup before a big upgrade so
they can go back to the old version when they see an error message
like this in the upgrade?

This error message is from the MariaDB server and not from the Debian
packaging scripts. You will get the exact same result on any distro if
you crash the database and then proceed to start it with another
version.

The software is open source, so if you have an idea how to avoid this
(e.g. how to tell users if their database crashed or how to do
database recovery in every possible situation), feel free to open a
pull request upstream at MariaDB Server.

- Otto

Otto,

Let us concentrate on the migration program mysql_upgrade, as quoted in the
title.
I attach the output of the test in Fedora. So you see what I do expect. It is
the program to check and repair the database schema. It is a regression in
Debian, not an upstream issue.

Hello!

The output of `mysql_upgrade
--socket=/run/user/1000/akonadi/mysql.socket` in your log from a
Fedora machine is not relevant. The output is exactly the same as any
normal mysql_upgrade run in Debian or elsewhere.

Your Fedora example would only be relevant if you copy the crashed
database from the Debian host to Fedora, and prove that the exact same
database in a cracked state recovers on Fedora but does not recover on
Debian.

Otto,

I don't have the crashed database available. What I say is, that I have 3
working Akonadi databases, one in a fresh Bullseye install.

In any case the call of mysql_upgrade fails.
bequimao@bullseye-kde-vm:~$ mysql_upgrade --defaults-file=/home/
bequimao/.local/share/akonadi/mysql.conf --socket=/run/user/1000/akonadi/
mysql.socket -v
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Can't execute 'mysqlcheck'
bequimao@bullseye-kde-vm:~$

So any future database migration would fail. A database migration in the past
might have failed, see mysql.err in the attachments to message #17.

Ulrich

It's me again!

Otto,
I found out that it is an Akonadi problem: Akonadi uses Mariadb as default
database, but does not provide mysqlcheck through dependencies.
Now I could repair the table structure with that knowledge, see the attached
file.

Would you please add the Akonadi maintainer to this bug report?

Best regards
Ulrich

Dear submitter,

as the package mariadb-10.5 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1004944

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Hi Ulrich!

Since this seems not a MariaDB bug, can I kindly ask you to close it?

Otto did a "batch re-opening" because we did not want to loose any bug
report when 10.5 was replaced by 10.6 in Sid.

Regards,

Since there is nothing actionable here I will close this very old bug report.

If you want to contribute to MariaDB in Debian, please help testing
and polishing the latest MariaDB 1:10.11.1