[debian-mysql] Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Otto Kekäläinen]

Hi Andreas!

Thanks for reporting and looking into this.

> Here apt choses a suboptimal removal order: mariadb-server-10.5 gets
> removed (and therefore stopped, but that fails) only after
> mariadb-client-10.5 and mariadb-client-core-10.5 are already gone.

You are right. The /usr/bin/mysqladmin command is gone and thus the
'$MYADMIN shutdown' will always fail in /etc/init.d/mariadb when
removal happens in this order.

The history here is that I submitted
https://github.com/MariaDB/server/pull/2299/commits/a7fb9f80af6f6aa2e5ca2f36a79d325358b40e00
upstream in a PR that got squashed (against my recommendation) and
thus got applied upstream as
https://github.com/MariaDB/server/commit/f4adf3547420cced027d26ee8b8190be8a2bdea2.
Upstream bug tracker was https://jira.mariadb.org/browse/MDEV-28640
and is still open, and this was filed now in Debian as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035949 but I recall
there was duplicates earlier as well. Anyway, clearly this isn't fully
fixed yet.

> I have tried the early upgrade scenario only with one other package that
> needs it (icinga2-ido-mysql), and there it worked flawless.
> Some bits from the log:
>
> ...
>   Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ...
>   Unpacking mariadb-common (1:10.11.2-1) over (1:10.5.19-0+deb11u2) ...
>   Preparing to unpack .../default-mysql-server_1.1.0_all.deb ...
>   Unpacking default-mysql-server (1.1.0) over (1.0.7) ...
>   Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ...
>   invoke-rc.d: could not determine current runlevel
>   Stopping MariaDB database server: mariadbd.
>   Removing mariadb-client-10.5 (1:10.5.19-0+deb11u2) ...
>   Removing mariadb-client-core-10.5 (1:10.5.19-0+deb11u2) ...
>   Removing mariadb-server-core-10.5 (1:10.5.19-0+deb11u2) ...
> ...
>
>
> Do you have a test in you CI that does something equivalent to
>
> * apt-get install default-mysql-server
> * sed s/bullseye/bookworm/ sources.list
> * apt-get install default-mysql-server # early upgrade
> * apt-get dist-upgrade

I was able to reproduce this on my laptop in a Docker container with simply:

./test-prepare-container
apt-get install default-mysql-server zoph
sed s/bullseye/bookworm/g -i /etc/apt/sources.list
apt update
apt-get install default-mysql-server

NOTE: Installing 'zoph' here is key. It will pull in dbconfig-common
etc and create this interaction. Removing 'zoph' makes the upgrade
pass just fine. This is similar to what we discovered with Cacti in
Bug#1031116

I added this 'zoph' update as a new Salsa-CI job in commit 2 of
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/26
(result in https://salsa.debian.org/otto/mariadb-server/-/jobs/4213540).


One way to mitigate this would be to backport
https://github.com/MariaDB/server/pull/2299/commits/a7fb9f80af6f6aa2e5ca2f36a79d325358b40e00
to MariaDB 10.5 in Debian. However it would not fix the fact that the
client library is removed too early.

I need to play around with this to find out a proper solution.