note that the temporary start of the server needs to prevent plugin initialization.

Scenario:

MariaDB 10.2 installed.Then 10.3 installed with spider (e.g) package as well.

Like all plugins a plugin-load-add option in a configuration file is dropped and will auto-install on startup.

From https://mariadb.com/kb/en/install-plugin/ is appears skip-grant-tables isn't sufficient to prevent it loading. plugin_dir=/dev/null maybe.

Please update the Description why we have to run mysql_upgrade BEFORE we install spider (or other plugins).

It would good if an Description starts with describing the problem and then updated with all the possible solutions for it.

The title and description of this issue is wrong/misleading. Debian maintainer scripts (postinstall/preinstall) do not run mariadb-upgrade nor mysql_upgrade. All the references to those commands are inside comments or in reference to temporary data directory /var/lib/mysql-upgrade. The Debian packaging does not call mariadb-upgrade.

± grep mariadb-upgrade debian/*

debian/changelog:  * Move mariadb-upgrade to same package as mysql-upgrade and manpage

debian/mariadb-server-10.6.postinst:    # perform mariadb-upgrade, (MDEV-22678).  To keep the impact minimal, we

debian/mariadb-server-core-10.6.install:usr/bin/mariadb-upgrade

debian/mariadb-server-core-10.6.install:usr/share/man/man1/mariadb-upgrade.1

debian/mariadb-server-core-10.6.links:usr/bin/mariadb-upgrade usr/bin/mysql_upgrade

± grep mysql_upgrade debian/*

debian/changelog:  * Automate renaming MySQL auth_socket correctly in mysql_upgrade

debian/changelog:  * Prevent mysql_upgrade from being triggered on every server restart

debian/changelog:  * Move mysql_upgrade to server core package so that Akonadi and similar

debian/changelog:  * New upstream release. Fixed the server crash caused by mysql_upgrade

debian/mariadb-server-10.6.postinst:    mysql_upgradedir=/var/lib/mysql-upgrade

debian/mariadb-server-10.6.postinst:      savelink="$mysql_upgradedir/$dir.link"

debian/mariadb-server-10.6.postinst:	    rmdir $mysql_upgradedir 2>/dev/null || true

debian/mariadb-server-10.6.postinst:    # mysql_upgrade, called from the /etc/init.d/mariadb start script, will

debian/mariadb-server-10.6.postinst:        echo "[mysql_upgrade]"                                           >>$dc

debian/mariadb-server-10.6.preinst:mysql_upgradedir=/var/lib/mysql-upgrade

debian/mariadb-server-10.6.preinst:    mkdir -pZ "$mysql_upgradedir"

debian/mariadb-server-10.6.preinst:    cp -dT "$checkdir" "$mysql_upgradedir/$dir.link"

debian/mariadb-server-10.6.README.Debian:There should not be any need to run 'mysql_upgrade' manually, as the upgrade

debian/mariadb-server-core-10.6.install:usr/share/man/man1/mysql_upgrade.1

debian/mariadb-server-core-10.6.links:usr/bin/mariadb-upgrade usr/bin/mysql_upgrade

debian/not-installed:usr/bin/mysql_upgrade

The only thing that runs the upgrade is the startup scripts (systemd or init.d) which are largely inherited from how the server upstream wants to be started, and there is no Debian specific thing to fix about mariadb-upgrade.

mysql_upgrade or mariadb-upgrade is run from debian/additions/debian-start.inc.sh included into debian/additions/debian-start, which in turn is run from debian/mariadb-server-10.8.mariadb.init.

Which was the source of the original problem (you'll see it if you walk the issue links up) — on every mariadb startup, debian runs mysql_upgrade in the background in parallel with any other user load. This was causing deadlocks and unpredictable results. That's why the issue subject is "not run mariadb-upgrade at the same time as anything"

rpm packages do not run mysql_upgrade or mariadb-upgrade at all, so this is very much debian-specifc issue.

rpm packages aren't perfect — not running mariadb-upgrade is also bad, but differently.