apt slaps at the problem; dpkg solves it.

Keep that in mind as you learn of my recent experience trying to uninstall MariadB.  After playing with and repeatedly reconfiguring a Galera cluster, I decided I wanted to start over with a clean slate.

Naturally, I did this:

apt -y remove mariadb-server
apt -y purge mariadb-server

But then I discovered many files remaining in /etc/mysql after doing this.

Here’s what the apt-get(8) man page says:

remove
remove is identical to install except that packages are removed instead of installed.
Note that removing a package leaves its configuration files on the system. If a plus
sign is appended to the package name (with no intervening space), the identified package
will be installed instead of removed.

purge
purge is identical to remove except that packages are removed and purged (any
configuration files are deleted too).

Now imagine the following scenario:

• Freshly-installed debian 11
• You install mariadb-server but don’t touch any config files and immediately shut it down
• You apt remove and apt purge all MariaDB/MySQL-related packages on the box

Having read that man page excerpt, wouldn’t you conclude that with those steps, all MariaDB-related config files on the system would be removed?

Not so.

Even worse, after doing a simple rm -rf on /etc/mysql and then doing an apt-install mariadb-server, many important config files in /etc/mysql were missing and the instance wouldn’t start.  I was expecting that my remove/purge/install commands would return me to a time when the world was new, but no – I ended up in a broken universe.

So how to completely remove a package such that apt understands you’re standing on empty ground and it should install the config files on a reinstall?  In my experience, apt is not enough and you have to call in the Heavy Thunder.

Here’s the journey – or just skip to the part in red if you want the answer.

We Start at the Genesis Moment

Or at least my first login as root.  I’m using a Vultr server (you might be able to get one for free) and of course, the Summit of All Operation Systems, Debian.  I should caveat that it’s a Vultr template and providers do screwy things sometimes but the apt settings are normal.

So literally my first command on this freshly installed VM:

# dpkg -l | grep mariadb
#

As expected, just making sure.  Now:

# apt update
<yadda yadda>
# cat /etc/debian_version 
11.6

Yes, I am waiting for bookworm at this point, though I have tried just doing a s/bullseye/bookworm/g and after a reboot to pick up the new kernel it worked fine.  I haven’t extensively tested it.

Back to this.  Vultr does an apt upgrade at first boot so no need for that.  Proceeding to MariaDB:

# apt -y install mariadb-server
<the usual>
# ls -l /etc/mysql/
total 24
drwxr-xr-x 2 root root 4096 Mar 18 19:51 conf.d
-rw------- 1 root root 544 Mar 18 19:51 debian.cnf
-rwxr-xr-x 1 root root 1731 Feb 18 2022 debian-start
-rw-r--r-- 1 root root 1126 Feb 18 2022 mariadb.cnf
drwxr-xr-x 2 root root 4096 Mar 18 19:51 mariadb.conf.d
lrwxrwxrwx 1 root root 24 Mar 18 19:51 my.cnf -> /etc/alternatives/my.cnf
-rw-r--r-- 1 root root 839 Feb 8 2021 my.cnf.fallback

So those are the config files at time of install.  mariadb is automatically started.  I prefer debian defaulted to disabled.  There are ways to prevent this behavior using systemd presets, but we’ll leave that for another day.  Here we’ll just:

systemctl stop mariadb

So what’s installed package-wise?

# dpkg -l | grep maria
ii libdbd-mariadb-perl 1.21-3 amd64 Perl5 database interface to the MariaDB/MySQL databases
ii libmariadb3:amd64 1:10.5.18-0+deb11u1 amd64 MariaDB database client library
ii mariadb-client-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB database client binaries
ii mariadb-client-core-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB database core client binaries
ii mariadb-common 1:10.5.18-0+deb11u1 all MariaDB common configuration files
ii mariadb-server 1:10.5.18-0+deb11u1 all MariaDB database server (metapackage depending on the latest version)
ii mariadb-server-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB database server binaries
ii mariadb-server-core-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB database core server files
# dpkg -l | grep mysql
ii mysql-common 5.8+1.0.7 all MySQL database common files, e.g. /etc/mysql/my.cnf

All right, let’s go scorched Earth:

apt -y remove mariadb-server mariadb-client mariadb-common mysql-common
apt -y purge mariadb-server mariadb-client mariadb-common mysql-common

So we’re clean as a mountain stream now, right?  Removed and purged?  We never touched a config file.

We’ve Been Tricked, Bamboozled, and Hornswoggled

# ls -l /etc/mysql/
total 12
-rw------- 1 root root 544 Mar 18 19:51 debian.cnf
-rwxr-xr-x 1 root root 1731 Feb 18 2022 debian-start
drwxr-xr-x 2 root root 4096 Mar 18 19:51 mariadb.conf.d

So it retained some config files? dpkg says:

# dpkg -l | grep maria
rc mariadb-client-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB database client binaries
rc mariadb-server-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB database server binaries
# dpkg -l | grep mysql
#

rc = “removed but config files linger”.

So there’s purge and then there’s purge apparently.  apt slaps at the problem; dpkg solves it.

# dpkg --purge mariadb-server-10.5

Oh, it’s getting real now…

Of course, this will remove your database files, so pay attention to that if you care about them.

Note that with dpkg you need to use the full package name with version (“mariadb-server-10.5”).

And to be thorough:

# dpkg --purge mariadb-client-10.5

And now:

# ls -l /etc/mysql
ls: cannot access '/etc/mysql': No such file or directory
# ls -l /var/lib/mysql
ls: cannot access '/var/lib/mysql': No such file or directory
# apt -y install mariadb-server
<yeah, yeah, we've seen it>
# ls -l /etc/mysql
total 24
drwxr-xr-x 2 root root 4096 Mar 18 20:00 conf.d
-rw------- 1 root root 544 Mar 18 20:00 debian.cnf
-rwxr-xr-x 1 root root 1731 Feb 18 2022 debian-start
-rw-r--r-- 1 root root 1126 Feb 18 2022 mariadb.cnf
drwxr-xr-x 2 root root 4096 Mar 18 20:00 mariadb.conf.d
lrwxrwxrwx 1 root root 24 Mar 18 20:00 my.cnf -> /etc/alternatives/my.cnf
-rw-r--r-- 1 root root 839 Feb 8 2021 my.cnf.fallback

I have no idea why things are this way, but there you have the full nuke’em.

• Author
• Recent Posts

raindog308

Dread Lord of LowEnd Content at LowEndBox

I'm raindog308, techno polymath and long-time LowEndTalk community Administrator. My technical interests include all things Unix, perl, python, golang, shell scripting, vintage operating systems such as MVS, and relational database systems such as Oracle, PostgreSQL, and MySQL.

I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.

I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308

Latest posts by raindog308 (see all)

• Crunchbits Discontinuing Popular Annual Plans – The Community Mourns! - November 20, 2024
• RackNerd’s Black Friday 2024: Bigger, Better, and Now in Dublin! - November 19, 2024
• It’s the Season of Giving and CharityHost Has Deals for You! - November 18, 2024