package mysql-server-5.7 5.7.23-0ubuntu0.18.04.1 failed to install/upgrade: installed mysql-server-5.7 package post-installation script subprocess returned error exit status 1

Status changed to 'Confirmed' because the bug affects multiple users.

From your log I see:
  Setting up mysql-server-5.7 (5.7.23-0ubuntu0.18.04.1) ...
  locale: Cannot set LC_CTYPE to default locale: No such file or directory
  locale: Cannot set LC_MESSAGES to default locale: No such file or directory
  locale: Cannot set LC_ALL to default locale: No such file or directory
  Error occurred: Cannot select database.
  mysql_upgrade failed with exit status 1

And in the mysql error log related to that:
  2018-08-06T18:45:33.244519Z 0 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist

I've seen a few cases were this was related to overlayfs [1], but most others like [2] are certain variations on deleted or permission-changed DB files.

It seems to me that the DB config was modified breaking the service start, that in turn will break the package upgrade/install.

[1]: https://serverfault.com/questions/870568/fatal-error-cant-open-and-lock-privilege-tables-table-storage-engine-for-use
[2]: https://stackoverflow.com/questions/9083408/fatal-error-cant-open-and-lock-privilege-tables-table-mysql-host-doesnt-ex

Thank you for taking the time to report this bug and helping to make Ubuntu better.

On upgrading a service this service has to be restarted to pick up the fixes.
Rather rarely a real issue occurs that the newer version does e.g. fail with the formerly working configuration.
But most of the time what happens is, that a service was installed, but stays unconfigured or experimented with but left in a broken state.

Now on any update of the related packages that service has to be restarted, but since its config is incomplete/faulty it fails to restart.
Therefore the update of that package has to consider itself incomplete.

Depending on your particular case there are two solutions:
- either remove the offending package if you don't want to continue using it.
- Or if you do want to keep it please fix the configuration so that re-starting the service will work.

Since it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New.

[Expired for mysql-5.7 (Ubuntu) because there has been no activity for 60 days.]

hey! please give some solution tech experts....?

I found that this error could be consistently reproduced on bionic. The problem occurs if /var/lib/mysql already exists before installing the packages.

Steps to reproduce, from a bare install of Ubuntu server:

  1) sudo mkdir /var/lib/mysql
  2) sudo apt install mysql-server

The annoying thing is that even if you then run "sudo chown mysql:mysql /var/lib/mysql" (after the first attempt created the user and group), and re-run the install, it still doesn't work even though it creates some files in /var/lib/mysql .

The use case for why you would want to pre-create /var/lib/mysql is when you want it on a separate filesystem. The required steps to achieve this are as follows; if necessary, ensure you purge the package and delete the contents of /var/lib/mysql (except lost+found) first.

    sudo umount /var/lib/mysql
    sudo rmdir /var/lib/mysql
    sudo apt install mysql-server
    sudo service mysql stop
    sudo mv /var/lib/mysql /var/lib/mysql.tmp
    sudo install -m 0 -d /var/lib/mysql # Create mount point with no permissions
    sudo mount /var/lib/mysql # Assumes filesystem is created and listed in /etc/fstab
    sudo sh -c 'mv /var/lib/mysql.tmp/* /var/lib/mysql'
    sudo rmdir /var/lib/mysql.tmp/
    sudo service mysql start

Thanks Alastair for the additional information. The issue you report is likely different from the one this report was initially opened for, so if you believe you actually found a bug it would be better to file a new report.

However I tried to reproduce the issue you are reporting, but I can't. Here is the full transcript of the session, starting from a clean Bionic LXD container:

  https://paste.ubuntu.com/p/bDCv25xvsn/

I'm marking this report as Incomplete for now. If you think it should be discussed further please feel free to comment and then set the bug status back to New. Thanks!

A very similar issue happened with 5.7.27-0ubuntu2 which needs to upgrade the database; in my setup, the datadir was not in the default folder /var/lib/mysql.
This means that the variable datadir describing a non-default location in /etc/mysql/mysql.cnf pointed by /etc/mysql/my.cnf has been overlooked.

A workaround is to:
- stop mysql.service
- rsync all data located in the folder pointed by datadir into /var/lib/mysql
- upgrade mysql-server-5.7
- stop mysql.service
- rsync all upgraded data back to its original non-default location
- restart mysql.service

Et voilà!

Hi,

This seems to be yet a different issue. In order to try to reproduce the problem you faced we need at least to know the following things:

 - Which version were you upgrading *from*?
 - Was the upgrade part of a release-upgrade to Eoan?
 - How exactly did you reconfigure AppArmor to allow
   the mysql datadir to be in a location different
   from /var/lib/mysql?

Anyway I attempted to reproduce in an upgrade from Disco (mysql-server 5.7.27-0ubuntu0.19.04.1) to Eoan (mysql-server 5.7.27-0ubuntu2) and wasn't able to. My alternate datadir was /mysql, and I added the following line:

  alias /var/lib/mysql/ -> /mysql/,

to /etc/apparmor.d/tunables/alias, and restarted the apparmor service.

Awaiting for further information I'm marking this report as Incomplete again. If you believe this is an actual bug in Ubuntu I encourage you to file a separate report, as it would be almost certainly an issue unrelated with the one this report was originally opened for. Should you follow-up here instead, please set the bug status back to New after replying, and we'll look at it again. Thanks!

Thanks!