MariaDB 10.1 server won't start when MySQL 5.7 server has been previously installed

Bug #1806263 reported by Laurent Declercq on 2018-12-02
This bug affects 8 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
mariadb-10.1 (Ubuntu)
mysql-5.7 (Ubuntu)

Bug Description

If you purge MySQL 5.7 server, then install MariaDB 10.1, that last won't start due to wrong AppArmor profile.

CURRENT RESULT ON mariadb-server-10.1 package installation

Job for mariadb.service failed because a timeout was exceeded.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

# LANG=C systemctl status mariadb

* mariadb.service - MariaDB 10.1.34 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Sun 2018-12-02 17:26:09 UTC; 59s ago
     Docs: man:mysqld(8)
 Main PID: 23245 (code=exited, status=0/SUCCESS)

Dec 02 17:24:37 bionic systemd[1]: Starting MariaDB 10.1.34 database server...
Dec 02 17:24:37 bionic mysqld[23245]: 2018-12-02 17:24:37 139820621216896 [Note] /usr/sbin/mysqld (mysqld 10.1.34-MariaDB-0ubuntu0.18.04.1) starting as process 23245 ...
Dec 02 17:26:07 bionic systemd[1]: mariadb.service: Start operation timed out. Terminating.
Dec 02 17:26:09 bionic systemd[1]: mariadb.service: Failed with result 'timeout'.
Dec 02 17:26:09 bionic systemd[1]: Failed to start MariaDB 10.1.34 database server.


MariaDB 10.1 server starting as expected.


apt-get install mysql-server-5.7 mysql-client-5.7
apt-get purge mysql-server-5.7 mysql-client-5.7
apt-get install mariadb-server-10.1 mariadb-client-10.1


The mysql-server-5.7 package install an /etc/apparmor.d/usr.sbin.mysqld APPARMOR(7) profile:

# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld

When purging the mysql-server-5.7 server package get purged, the /etc/apparmor.d/usr.sbin.mysqld profile is also removed but, it is still loaded:

# aa-status | grep 'mysqld'

This lead to MariaDB 1.0 server not being able to start due to MySQL 5.7 APPARMOR(7) profile that is still loaded.

Furthermore, the mariadb-server-10.1 also comes with an APPARMOR(7) profile which as per it header comments is "intensionally empty to disable apparmor by default for newer versions of MariaDB".

This is a big mistake as such a profile is simply wrong in regard of APPARMOR_PARSER(8) and as such, won't be unloaded:

# apparmor_parser -v -R /etc/apparmor.d/usr.sbin.mysqld
# aa-status | grep 'mysqld'


# echo "/usr/sbin/mysqld { }" > /etc/apparmor.d/usr.sbin.mysqld
# apparmor_parser -v -R /etc/apparmor.d/usr.sbin.mysqld
Removal succeeded for "/usr/sbin/mysqld".
# aa-status | grep 'mysqld'


1. When mysql-server-5.7 package is being removed/purged, the APPARMOR(7) profile should be unloaded and removed ranther than be simply removed.
2. The profile provided by the mariadb-server-10.1 package should have correct syntax in regard of APPARMOR_PARSER(8)
3. The mariadb-server-10.1 package postinst/postrm maintainer scripts should handle apparmor profile (load/unload)

Env Ubuntu Bionic Beaver (18.04)

Ricardo (rjpinto) wrote :

Just hit this bug when trying to change from mysql to mariadb.

Solution: reboot after purging mysql and installing mariadb will load the correct AppArmor profile.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mariadb-10.1 (Ubuntu):
status: New → Confirmed
Faustin (fauust) wrote :

thank you for your report and your help making Ubuntu better!
This is not a bug but a problem with apparmor profile shipped with mysql still enabled.

You will find here various solutions to this:


Changed in mariadb-10.1 (Ubuntu):
status: Confirmed → Fix Released
quazgar (quazgar) wrote :

I agree that it's not a MariaDB bug, but it should be tagged as a bug of the MySQL Ubuntu package as long as that one does not disable the apparmor profile upon deinstallation.

Faustin (fauust) wrote :

Yes this is true, and I agree.

I understand the back and forth between the packages responsibility here.
In fact I was involved in a similar problem for ntp that was discussed here:


Bluntly applying the same to this case it would be a change to mariadb that would do something like

- if anything it would be the job of dh_appamor
- for security reasons it is intentionally not unloaded
- conflicting packages (rare edge cases) should NOT fix it by unloading on remove/purge
- conflicting packages (rare edge cases) should fix it by unloading in pre-inst if needed

Changed in mariadb-10.1 (Ubuntu):
status: Fix Released → New
Changed in mysql-5.7 (Ubuntu):
status: New → Won't Fix
Changed in apparmor (Ubuntu):
status: New → Won't Fix

Added an apparmor task for its similarity to bug 1689585 but set it immediately to Won't Fix (as we did there). But having apparmor people getting notified might help with the continuation of this discussion.

Alamy Liu (alamyliu) wrote :

Thank you so much for the solution.

Xubuntu 18.04.02. In the progress to install LAMP.
Decided to switch to MariaDB after install mysql-server/client with apt.
I forgot to purge mysql before "apt install mariadb-server/client", but it seems to be fine.
Trying to run "mysel_secure_installation" and found that the server is not up.
Hit this problem when trying to launch.

Thank you for the "apparmor_parser" solution so I don't have to reboot the system, and I could start the server.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mariadb-10.1 (Ubuntu):
status: New → Confirmed
Thommie Rother (t-rother) wrote :

I see no activities here since may 19 and just ran into this bug on two installations of 18.04.3. This is a major issue preventing the use of mariadb!

@Robie/@Lars (no on CC) - IIRC this was somewhat known and on your list - are there any updates to the overall case of co-existence (at least after one another)?

F. Alejandro Osso (faosso) wrote :

Just to thank you all. I just hit this problem, solved it and in the process learned something about apparmor.

Otto Kekäläinen (otto) wrote :

This is a duplicate of

This migration path is not supported. From Oracle MySQL 5.7 you need to upgrade to MariaDB 10.2 or newer.

Changed in mariadb-10.1 (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers