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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1571865
Title:
mysql fails to start after upgrade if previous defaults were
customised
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1571865/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
