Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#993219: mariadb-server-core: Akonadi database - mysql_upgrade fails always with "FATAL ERROR: Can't execute 'mysqlcheck'"
31 views
Skip to first unread message
Ulrich Beckmann
Aug 28, 2021, 2:00:03 PM8/28/21
to
Package: mariadb-server-core-10.5
Version: 1:10.5.11-1
Severity: normal
File: mariadb-server-core
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.
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mariadb-server-core-10.5 depends on:
ii libaio1 0.3.112-9
ii libc6 2.31-13
ii libcrypt1 1:4.4.18-4
ii liblz4-1 1.9.3-2
ii libpcre2-8-0 10.36-2
ii libsnappy1v5 1.1.8-1
ii libssl1.1 1.1.1k-1+deb11u1
ii libstdc++6 10.2.1-6
ii libsystemd0 247.3-6
ii mariadb-common 1:10.5.11-1
ii zlib1g 1:1.2.11.dfsg-2
mariadb-server-core-10.5 recommends no packages.
mariadb-server-core-10.5 suggests no packages.
-- no debconf information
Version: 1:10.5.11-1
Severity: normal
File: mariadb-server-core
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.
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mariadb-server-core-10.5 depends on:
ii libaio1 0.3.112-9
ii libc6 2.31-13
ii libcrypt1 1:4.4.18-4
ii liblz4-1 1.9.3-2
ii libpcre2-8-0 10.36-2
ii libsnappy1v5 1.1.8-1
ii libssl1.1 1.1.1k-1+deb11u1
ii libstdc++6 10.2.1-6
ii libsystemd0 247.3-6
ii mariadb-common 1:10.5.11-1
ii zlib1g 1:1.2.11.dfsg-2
mariadb-server-core-10.5 recommends no packages.
mariadb-server-core-10.5 suggests no packages.
-- no debconf information
Otto Kekäläinen
Aug 28, 2021, 7:50:03 PM8/28/21
to
Control: tags -1 moreinfo
Hello!
This is not a bug in the Debian packaging and not really an upstream bug either.
The error message seems pretty clear:
> [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.3.27.
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.
Hello!
This is not a bug in the Debian packaging and not really an upstream bug either.
The error message seems pretty clear:
> [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.3.27.
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.
Ulrich Beckmann
Sep 3, 2021, 4:00:04 PM9/3/21
to
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
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
Otto Kekäläinen
Sep 4, 2021, 6:00:03 PM9/4/21
to
> 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.
Maybe they should, or at least take a backup before a big upgrade so
> normally does not know, whether the database was shut down correctly or not.
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
Ulrich Beckmann
Sep 11, 2021, 10:30:04 AM9/11/21
to
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.
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.
Otto Kekäläinen
Oct 9, 2021, 10:30:03 PM10/9/21
to
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.
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.
Ulrich Beckmann
Oct 15, 2021, 11:10:03 AM10/15/21
to
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/
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
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:~$
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Can't execute 'mysqlcheck'
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
Ulrich Beckmann
Nov 20, 2021, 2:00:04 PM11/20/21
to
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
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
0 new messages