Databases

How to upgrade Mariadb Ver 10.x to 11.x on Debian 12 with Virtualmin – the nightmare

Background

This article started off with as “how to upgrade MariaDB 10.11.14” on a fresh Debian 12 installation that also has Virtualmin on. I use Virtualmin a lot and I don’t want to go through the pain of upgrading it later and additionally cPanel has a new feature whereby 10.x can be upgraded to 11.x using the UI.

This article ended of scrapping the upgrade part. Between version 10.x and 11.x it seems it’s just too complicated for the busy sysadmin. I did actually have more success upgrading between 11.x versions using this command, `apt upgrade mariadb-server`, but I’m not going to guarantee any funny issues.

On a vanilla setup (with Virtualmin on already) it’s easier to share the joy of cutting out the old and putting in the new.

The steps are basically:

Find out latest LTS version
Purge the old
Set up the new repo
Install the new
Fix Webmin in two places
Re-check configuration

Let’s get started:

Prerequisites

First Google what is the latest LTS version of MariaDB?

The latest release series is MariaDB 12.1, with MariaDB 12.1.1 RC being the most recent development release as of September 2025. The latest stable LTS (Long-Term Support) version is MariaDB 11.8, and the latest stable rolling release is MariaDB 11.7.

SSH to the server

$ mariadb -V
mariadb Ver 15.1 Distrib 10.11.14-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper

Somehow on Debian sudo -i doesn’t work, so do this:

su -

Purge the old

Warning, you’ll loose database access and if you so choose, all your databases will be deleted also. The instructions in this article is for a vanilla setup.

apt remove --purge 'maria*';apt remove --purge 'mysql*';apt autoremove;

Refresh Webmin

You’ll notice this in Webmin see MySQL which can be fixed by refreshing modules, twice, once after purge, and once after re-installation.

Activate the new repo

Next from what’s you’ve learned about the latest LTS, run the command below substituting `–mariadb-server-version` with whatever Google spat out:

curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="11.8"

Install a newer version

apt install mariadb-server

Webmin Fixes

Refresh Webmin modules again to see ‘MariaDB Database Server” displayed under Server instead of MySQL.

If you click the Server / MariaDB menu, the first error you’ll get is this:

The MariaDB client program /usr/bin/mysql does not accept passwords passed using the MYSQL_PWD environment variable. To ensure that Webmin is able to fully communicate with MariaDB, this option should be turned off on the module configuration page. Alternately, you can remove any password set in the root user’s .my.cnf file.

Follow the module configuration link and exactly as per the instructions and set that to “No”.

Next you’ll get this:

Fatal Error!
/usr/bin/mysqlshow: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-show' instead

Find the little cogsheel for module settings (it’s hard the first time, but check top left when you click on the module). There you can fix the deprecation issue:

Here is the next problem:

Fatal Error!
SQL select table_schema,table_name from information_schema.views where table_schema = ? failed : Webmin cannot parse the output from the <tt>mysql</tt> command due to the nature of data in your database. You will need to install the <tt>DBI</tt> and <tt>DBD::mysql</tt> Perl modules to solve this problem.

To fix it, navigate to Perl modules and from Cpan section, type exactly this:

DBD::mysql

At this point Webmin is happy. I typically re-run the Virtualmin installation wizard and the re-check configuration wizard but I’m not sure if that’s needed.

Why is upgrading such a mission?

It seems with every new major release of MySQL and MariaDB there is always an issue. Here are some of the problem you’ll encounter and why we’ve simply given up on trying this on complex systems:

The upgrade might warn you about new configuration files and overwriting them. This is risky on a production server, or is it?
The log file might be full of these errors:
- “Access denied for user ‘root’@’localhost’ (using password: NO)”
  - Trying to solve something as “trivial” as that can take hours
Virtualmin might be referring to old my.cnf locations and the upgrade might break this
On one 10.x system, we have a lot of `provider_` files causing further upgrade isssues

The ‘root’@’localhost’ can be particularly damning sending you into a rabbit hole like this:

mariadbd-safe –skip-grant-tables –skip-networking &

Then random commands like:

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED VIA unix_socket;
ERROR 1290 (HY000): The MariaDB server is running with the --skip-grant-tables option so it cannot execute this statement
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)

and

UPDATE mysql.user SET plugin='unix_socket', password='' WHERE user='root' AND host='localhost';
ERROR 1348 (HY000): Column 'plugin' is not updatable

and

UPDATE user SET plugin='', authentication_string=PASSWORD('YourStrongPassword!') WHERE user='root' AND host='localhost';

All I can say, if you go that way, is good luck!

Let me know in the comments if you have a different experience of upgrading MariaDB from 10.x to 11.x.