mysql fails to start because 5.6.16-64.1-563.wheezy has changed the location of errmsg.xyx

[Jeff Armstrong]

== broken server - after upgrade dpkg info ==
ii percona-server-server-5.6 5.6.16-64.1-563.wheezy amd64 Percona Server database server binaries

== mysqld fails to start after upgrade ==
/var/log/daemon.log
[ERROR] Can't find messagefile '/usr/share/mysql/errmsg.sys'
[Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.16-64.1 started; log sequence number 1532365
[ERROR] Aborting

>locate errmsg.sys
/usr/share/percona-server/bulgarian/errmsg.sys
/usr/share/percona-server/czech/errmsg.sys
/usr/share/percona-server/danish/errmsg.sys
/usr/share/percona-server/dutch/errmsg.sys
/usr/share/percona-server/english/errmsg.sys

== on a working server that is not upgraded ==
dpkg info for 5.6.15
ii percona-server-server-5.6 5.6.15-rel63.0-519.w amd64 Percona Server database server binaries

locate errmsg.sys
/usr/share/mysql/bulgarian/errmsg.sys
/usr/share/mysql/czech/errmsg.sys
/usr/share/mysql/danish/errmsg.sys
/usr/share/mysql/dutch/errmsg.sys
/usr/share/mysql/english/errmsg.sys

Of course I can create symlink manually - but package upgrade should not do this.
Maybe you should add /etc/mysql/conf.d/upgrade_5.6.16-64.1-563.wheezy.cnf containing
lc-messages-dir = /usr/share/percona-server

TIA
Jeff

[Hrvoje Matijakovic (hrvojem)]

Hi Jeff,

Can you please tell me where is the config file that has that value located? I mean is it in /etc/mysql/my.cnf or somewhere else?

Thank you

[Timur Bakeyev (timur.bakeyev)]

I'm going to file a separate bug on it, but as I can see, the root of the problem is in the dependency on mysql-common, which overwrote /etc/mysql/my.cnf, hence the location of the error log file.

[Timur Bakeyev (timur.bakeyev)]

Filed bug #1294211

[mig5 (mig5)]

This one sounds like a duplicate of #1293867. Your my.cnf has settings pointing to /usr/share/mysql and this upgrade renames that dir. In my case, the upgrade also silently modified my my.cnf for me, but Puppet restored the original setting and hence breakage.

[mig5 (mig5)]

Timur I am not sure this issue is related to mysql-common. The modification of my.cnf regarding /usr/share/percona-server is done in the preinst file of percona-server in just this upgrade. Yes this and the previous release of Percona, result in mysql-common which *prompts* about a my.cnf change, but you can say 'No' to that. In this case here, the user doesn't even get the choice to accept this change.

[Jeff Armstrong (n-launchpa7-f)]

I have discovered that this was because we had included an explicit directive in our main my.cnf

  lc-messages-dir = /usr/share/mysql

If I remove this setting first, then the upgrade succeeds.

Looks like a case of us being excessive and setting variables that work fine if you leave them alone.

My revised opinion is that this mainly is an issue with our configuration, and not really a packaging issue.

If you really want a gold star, you might warn that an explicit lc-messages-dir setting will cause an upgrade failure.

Or grep for the presence of lc-messages-dir and if it is found and does not match the correct value, abort the upgrade with a warning about incompatible lc-messages-dir.

Ok - for a real out-perform you could modify the my.cnf and comment out the offending directive - but please WARN as our next release of my.cnf would re-introduce the problem.

Regards
Jeff

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-3108