On sam., 2015-11-28 at 15:59 +0000, Robie Basak wrote: > Hi, > > Do you have steps to reproduce this please? What makes you think it > is a bug in the packaging as opposed to a configuration problem on > your system? >
The system was perfectly OK before the upgrade, I upgrade at least once a week on that "unstable" machine to always use the latest versions. > On Sun, Nov 22, 2015 at 10:02:05PM +0100, jpp wrote: > > The /var/lib/mysql is a symlinj to another location on another > > disk. > > I'm not aware of any path in the maintainer scripts that will create > this as a symlink. Is this something you have configured yourself? Yes, I configure that symlink some years ago to put the mysql datafiles out of my system's SSD which was small. > > > /etc/mysql/mysql.cnf [Errno 2] No such file or directory: > > u'/etc/mysql/mysql.cnf' > The install complains about /etc/mysql/conf.d, not mysql.cnf, original error message was : ----------------------------------------------------------------------- /usr/sbin/mysqld: Can't read dir of '/etc/mysql/conf.d/' (Errcode: 2 - No such file or directory) ----------------------------------------------------------------------- Before that try I uninstall (apt-get remove --purge) all mysql stuff, so the "/etc/mysql" directory was not even existing when I re-install. A small remark : that directory doesn't contain any file after the install and no file today. > Again I'm not aware of a path that would cause this to not exist. > IIRC it is a conffile shipped by mysql-server-5.6. > > > 2015-11-22 21:53:53 4936 [ERROR] Fatal error: Can't open and lock > > privilege tables: Table 'mysql.user' doesn't exist > > This I have seen. I think upstream know more about it, but I don't > recall the details. Have you ever installed MariaDB? Because the > migration path from MySQL back to MariaDB isn't automatic. I never install MariaDB on that machine. As mysql was not OK it couldn't find some direcctories/files at least for InnoDB. > > Severity: critical > > Justification: causes serious data loss > The database was unusable and Mysql wouldn't reinstall properly until I create the /etc/mysql/conf.d directory. Then the install went OK and it was possible to import all backuped data. > I don't think this is justified until we can determine that this is > really a bug. For that we need steps to reproduce please. You said > thatyou found this on a test server. Can you restore the test server > to find out what the state of the system was before you attempted the > upgrade? > The "test" server is my personal machine and I didn't have things to restore the system at a state just before the problem. I save only my personnal data and all system parameters (mainly /etc). I regret I can't give more elements as I was not prepared to get into troubles with a fresh install after having troubles with an upgrade. As the machine has two bootable disks I re-install on the second system disk but I create /etc/mysql/conf.d and didn't have any trouble with it, remove --purge and reinstall without problems on that disk. I didn't try the upgrade on that disk. Regards JP P