mysql maintainer scripts fail if files in /etc/mysql have been deleted locally

[Robie Basak]

A common report is that MySQL-related maintainer scripts have failed after files in /etc/mysql/ have been deleted. This is expected behaviour since policy is that users' modifications of conffiles (for example, files in /etc/mysql/) should be preserved.

The logic is that if you have modified /etc/mysql/, it is presumed that those modifications are what you want. Packaging cannot fix up any broken customizations for you, so for example if you have deleted those files, then packaging will be broken.

Before attempting to fix this up, make sure to take a full backup of your system and in particular any databases (by default in /var/lib/mysql) in case your attempt results in destruction of your data.

To fix this situation up, you could try purging all mysql-related packages (particularly mysql-common, mariadb-server-* and/or mysql-server-*) and reinstalling them. Note that just removing the packages will not work since dpkg will preserve your local modifications to /etc/mysql/ as designed.

Since this behaviour is by design, this is not a bug in Ubuntu that will be fixed and so this bug's status is set to Invalid to reflect this. Please note that the bug tracker is not a support forum. Although you are welcome to communicate with other affected users here, please do not expect help here since the community doesn't generally monitor bugs for this purpose.

If you are still having problems, then you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community

[Calabacin (raulgarciag)]

In my case I had MySQL and wanted to install MariaDB. After using MariaDB for some time I decided it was not for me and tried to go back to MySQL. That's when hell started. There is no way to recover what I had before and everything I try seems to fail. I thought I had it finally working but I now get these MySQL crashes all the time.

[Robie Basak (racb)]

On Fri, Jun 17, 2016 at 10:49:28AM -0000, Calabacin wrote:
> In my case I had MySQL and wanted to install MariaDB. After using
> MariaDB for some time I decided it was not for me and tried to go back
> to MySQL. That's when hell started. There is no way to recover what I
> had before and everything I try seems to fail. I thought I had it
> finally working but I now get these MySQL crashes all the time.

I'm afraid this expected behaviour. MariaDB is drop-in compatible with
MySQL, but then it changes your database in a way that MySQL does not
understand. You cannot switch back to MySQL after this without
restoring from backup.

I believe our MariaDB packaging warns you of this before you switch. If
it did not, please file a bug against MariaDB. Further, the MySQL
packaging should have stopped you from switching back. The only
supported path is to purge all MySQL/MariaDB -related packages, remove
/etc/mysql and /var/lib/mysql, and either start again or restore from
MySQL (not MariaDB) backup.

Also relevant is bug 1490071. IMHO, there should be a path in packaging
by which the user can use MariaDB but in a different data location so
that going back to MySQL is possible later (albeit by effectively
winding the database back). But this requires extensive work and
coordination and I don't expect to have it ready any time soon.

[Riccardo (riccardo-cicuto)]

In my case the problem is a missing /etc/mysql/my.cnf.fallback configuration file.

Possible workaround:

In /var/log/apt/history.log

Start-Date: 2017-01-20 10:42:27
Commandline: aptdaemon role='role-commit-packages' sender=':1.126'
Upgrade: mysql-server-5.7:amd64 (5.7.16-0ubuntu0.16.04.1, 5.7.17-0ubuntu0.16.04.1), mysql-server:amd64 (5.7.16-0ubuntu0.16.04.1, 5.7.17-0ubuntu0.16.04.1), mysql-client:amd64 (5.7.16-0ubuntu0.16.04.1, 5.7.17-0ubuntu0.16.04.1), libmysqlclient20:amd64 (5.7.16-0ubuntu0.16.04.1, 5.7.17-0ubuntu0.16.04.1), libmysqlclient20:i386 (5.7.16-0ubuntu0.16.04.1, 5.7.17-0ubuntu0.16.04.1), mysql-server-core-5.7:amd64 (5.7.16-0ubuntu0.16.04.1, 5.7.17-0ubuntu0.16.04.1)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2017-01-20 10:42:27

In /var/log/apt/term.log

Log started: 2017-01-20 10:42:27
Setting up mysql-common (5.7.17-0ubuntu0.16.04.1) ...
update-alternatives: error: alternative path /etc/mysql/my.cnf.fallback doesn't exist
dpkg: error processing package mysql-common (--configure):
 subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
 mysql-common
Log ended: 2017-01-20 10:42:27

So the problem for me seems to be the missing the /etc/mysql/my.cnf.fallback file.

ll /etc/myql
drwxr-xr-x 4 root root 4096 gen 20 10:59 ./
drwxr-xr-x 189 root root 12288 gen 19 12:44 ../
drwxr-xr-x 2 root root 4096 gen 20 09:43 conf.d/
-rw------- 1 root root 317 nov 19 10:57 debian.cnf
-rwxr-xr-x 1 root root 120 ott 24 17:13 debian-start*
lrwxrwxrwx 1 root root 24 nov 18 21:12 my.cnf -> /etc/alternatives/my.cnf
-rw-r--r-- 1 root root 3028 nov 18 21:27 my.cnf.migrated
-rw-r--r-- 1 root root 682 lug 11 2016 mysql.cnf
drwxr-xr-x 2 root root 4096 nov 18 22:24 mysql.conf.d/

So, because the symlink:

my.cnf -> /etc/alternatives/my.cnf

points back to:

/etc/alternatives/my.cnf -> /etc/mysql/mysql.cnf

i assumed (crossing my fingers) that /etc/mysql/mysql.cnf should be eligible as alternative fallback:

sudo cp /etc/mysql/myslq.cnf /etc/mysql/my.cnf.fallback

Run again apt tool to complete the upgrade.

This worked for me.

[Andrew (am-public-o)]

I have my machine installed with MariaDB 10. Just booted and saw "There was a problem with mysql 5.7...."

Weird, I don't have mysql-server 5.7 installed. Maybe some half-configuration lying around...?

andy@andy-virtual-machine:~$ sudo apt policy mariadb-server
mariadb-server:
  Installed: 10.0.28-0ubuntu0.16.04.1
  Candidate: 10.0.28-0ubuntu0.16.04.1
  Version table:
 *** 10.0.28-0ubuntu0.16.04.1 500
...

andy@andy-virtual-machine:~$ sudo apt policy mysql-server
mysql-server:
  Installed: (none)
  Candidate: 5.7.17-0ubuntu0.16.04.1
  Version table:
     5.7.17-0ubuntu0.16.04.1 500
...

[WhyteHorse (whytehorse)]

OMFG this bug is HELL!!!! OH OHHHHHH!!!! FIX IT!!!!! EVERY OTHER PACKAGE WORKS FINE IF YOU CHANGE THE CONFIG FILES!!!!!!! THIS COMPLETELY BREAKS UPDATES ON MY SERVERS!!!!!!! IT KEEPS HAPPENING OVER AND OVER!!!!!!! OHHH OHHHHHHHHH!!!!!

[Mathis Kruse (zainless)]

For anyone coming across this: apt will mention something with --fix-broken and that actually fixes it. In my case I did purge mysql-server-<version> and then reinstalled it, which naturally did not work.
apt-get --fix-broken install mysql-server
worked, however.
Hope this helps.

[Jan Bauer (jbauersmt)]

The package installer should check for any missing files in /etc/mysql and recreate them if they are completely missing.

[Robie Basak (racb)]

On Thu, Jun 07, 2018 at 12:45:36PM -0000, Jan Bauer wrote:
> The package installer should check for any missing files in /etc/mysql
> and recreate them if they are completely missing.

I don't agree. The user "owns" /etc and the system is designed to
preserve all modifications to it. Trying to automatically guess the
user's intent sounds like a recipe for confusion. The provided mechanism
to recreate the files is to purge and install the packages again.

In any case, it's not up to the package maintainer to change the
behaviour of the package manager or disregard Debian and/or Ubuntu
policy.

[Majisi Jitendrasinh (jitendrasinh)]

I have same issue. Thanks in advance for any help.

 mysql-common
 mysql-client-5.7
E: Sub-process /usr/bin/dpkg returned an error code (1)
I have tried above suggestions but that don't work.
My question is can I copy the file
/etc/mysql/myslq.cnf
and create new one and paste it in new file
/etc/mysql/mysql.cnf and save it ?
Let's resolve this.

[Giles Birch (giles-h)]

"This is expected behaviour since policy is that users' modifications of conffiles (for example, files in /etc/mysql/) should be preserved." makes absolutely no sense when the problem is that /etc/mysql has been deleted. In the case where there is no config to overwrite, the script should reinstall default values, and there is no danger in doing so. What the package maintainers seem to be saying is "hey, too bad your attempts to fix bad config went wrong and you decided to start again, we won't help you at all."

[Robie Basak (racb)]

On Tue, Jun 02, 2020 at 01:28:58PM -0000, Giles Birch wrote:
> "This is expected behaviour since policy is that users' modifications of
> conffiles (for example, files in /etc/mysql/) should be preserved."
> makes absolutely no sense when the problem is that /etc/mysql has been
> deleted. In the case where there is no config to overwrite, the script
> should reinstall default values, and there is no danger in doing so.

There is no such guarantee. A user might have customized the mysql
service to look somewhere else for configuration, for example, but
some clients may still look in /etc/mysql, find nothing, and continue as
normal. Re-adding /etc/mysql with a different configuration would break
that arrangement, and a user affected like that could quite rightly
complain that special casing MySQL packaging against established
packaging policy was surprising and wrong.

There are other (not-MySQL) cases where removing a file from /etc does
correctly adjust a service rather than completely break it (for example
as a mechanism to switch to upstream defaults rather than packaging
defaults).

We cannot both deal with this special case and also behave correctly for
other users who expect the general rules to be followed.

> What the package maintainers seem to be saying is "hey, too bad your
> attempts to fix bad config went wrong and you decided to start again, we
> won't help you at all."

I have no objection to heuristic detection and pointing users to a
solution, if you want implement and contribute that. For example, this
could detect the situation and print a message along the lines of "if
you deleted /etc/mysql in the hope of restoring defaults, actually you
need to purge the packages and reinstall them".