Comment 16 for bug 1571865

I've spent some time testing this fix in Xenial. It was broken for two reasons:

1) I failed to update the version string check in mysql-server-5.7.postinst in preparing the SRU, so the migration code never ran. This isn't a regression, just a failure to fix the problem as intended.

2) On an upgrade from Trusty to Xenial, mysql-server-5.7 itself isn't being upgrade, so again the migration code never ran.

The fix is to change the match to:
    if dpkg --compare-versions "$2" le "5.7.13-0ubuntu0~"; then

I tested 5.7.13-0ubuntu0.16.04.1 from ppa:ubuntu-security-proposed as follows:

I hacked the postinst in the binary package directly as above, to save time. I used "apt-get --download-only" to pull all the binaries generated from src:mysql:5.7, and placed the modified set (just mysql-server-5.7, the others were just straight copies) into a local repository, created Packages and Release with apt-ftparchive, and then pointed apt to using "deb [trusted=yes] file:///root/repo /". I then used this in place of the PPA for testing.

The cases I tested were:

Trusty to Xenial upgrade without local conffile modification: PASS
Trusty to Xenial upgrade with local conffile modification: PASS
Trusty to old Xenial package with local conffile modification (expected fail), then upgrade to new Xenial package: PASS
Xenial to new package upgrade without local conffile modification: PASS
Xenial to new package upgrade with local conffile modification: PASS
Fresh Xenial new package install: PASS

The fix is now working as expected.

Francisco, thank you for testing the proposed update. Please note that there are a variety of reasons that mysqld could fail to start. What I am tracking in this bug is the specific case of an unrelated customisation in 14.04 causing mysqld to fail to start after upgrade to 16.04 because previously valid default options will be preserved in the upgrade and are now deprecated.

This is what this proposed fix fixes: it detects those specific configuration directives and renames them, which should improve the situation for most users in this fairly common case.

If there are other root causes that impact users, then I'd like to fix them too, but we need to identify what those root causes are. To save confusion, we should track them sepearately in their own bugs.

Logs should be in /var/log/mysql/error.log. If this is not the case, you could be upgrading from a very old customised configuration where the default configuration did not provide this. You need "log_error = /var/log/mysql/error.log" directive. If your system is this old, it'll probably be in /etc/mysql/my.cnf.migrated unless you have updated your configuration to use the new scheme since. I hope this helps, but if you have a reproducible unrelated issue, please continue in a fresh bug report.