[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

Bug 1676605 referred to this from comment 18:

> I found some other issues too when I tried reinstalling from scratch -
/etc/mysql/my.cnf has the line "!includedir /etc/mysql/conf.d/", but
/etc/mysql/conf.d no longer exists if you have purged mysql before
reinstalling, so the server won't start up and configuration therefore
fails. I had to comment the line out manually to get it to work.

I wondered if there was a bug here, but I couldn't figure out how to
reproduce this. Purging mysql-common does drop /etc/mysql/conf.d/, but
reinstalling it brings it back. If you can figure out how to reproduce
it, please file a separate bug for that.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[oscar]

ñ

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Christian Deligant]

@Robie Basak
The main problem is that all the packages that rely on an active mysql-server 
to upgrade themselves will stop and ask what to do, thus you anyway need to 
babysit them :)

At this point, having the upgrade of Mysql-Server stopping if it was on
and could not restart will only stop the upgrade once.

I don't think a release upgrade has to be done unattended...

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

On Tue, Oct 11, 2016 at 09:37:56AM -, Christian Deligant wrote:
> What happened is that mysql-server did not restart, probably throwing a
> complain but without stopping (and upgrading from 14.04 to 16.04 means
> 2900 MB of stuff to download, running on an SSD you really don't even
> notice what is passing on the screen!), the other packages complaining
> about not being able to connect to the socket... not exactly a good hint
> about the server being off. Only at the very end installation ended up
> with 2 packages misconfigured...

The upgrade does its best to upgrade everything that is unaffected.
Other package unable to connect to the socket should be correctable with
the same "sudo apt-get -f install" after you have fixed the problem
manually after your upgrade. If there is some reason that didn't work
for you, then that's a separate bug that can be fixed (whether in mysql
or the dependent packages).

> I suggest instead of that behaviour to hang the upgrade in case mysql-
> server is not restarting with a notification showing the offending
> settings in order for the sysadmin to understand what is going wrong and
> act before going on.

I don't think this would be acceptable. Say ten packages with similar
challenges follow your solution. Then it would become impossible for you
to complete your upgrade unattended. You'd need to babysit the whole
process. This would be incredibly tedious. Instead, why not fix all the
manual-intervention-required issues at once at the end?

Is there some reason why the solution I described above does not work
for you?

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Christian Deligant]

I understand your concern.

My installation had a separate cnf file in the conf.d directory with a
couple of personal settings affecting the mysqld, among them the old
slow-query variables.

This was done in order to have the my.cnf upgrade smoothly among time.

What happened is that mysql-server did not restart, probably throwing a
complain but without stopping (and upgrading from 14.04 to 16.04 means
2900 MB of stuff to download, running on an SSD you really don't even
notice what is passing on the screen!), the other packages complaining
about not being able to connect to the socket... not exactly a good hint
about the server being off. Only at the very end installation ended up
with 2 packages misconfigured...

I suggest instead of that behaviour to hang the upgrade in case mysql-
server is not restarting with a notification showing the offending
settings in order for the sysadmin to understand what is going wrong and
act before going on.

Hope this suggestion will be accepted

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Lars Tangvald]

Christian:
There are too many things that could go wrong for users if the server itself 
ignores something in the config file and uses what it considers a safe default.

For the packaging we are working on working around the issue of the
server not starting in cases where users have disabled the automatic
starting/stopping of services, and this could potentially be extended to
include cases where the config contains invalid options (i.e. print a
warning and don't try to run mysql_upgrade instead of throwing an
error).

But this might not cover all the use cases you mention, since some of
those packages might be expecting the server to be up and running.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Christian Deligant]

Why couldn't mysql-server just throw a warning on an unknown variable and start 
with a default?
Especially during a release update, mysql is critical when many packages rely 
on a DB-based content to upgrade themselves (Mediawiki, otrs, etc)

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Mohamed Hafez]

So, if I understand correctly, after the upgrade, I'll still have a
my.cnf file *exactly* as I left it, but the config file mysql will be
using will be a my.cnf.migrated file, which will be a best-guess at
auto-migrating my custom config. Is this correct?

After double-checking my.cnf.migrated and doing Workaround 3/3, can I
just rename my.cnf.migrated to my.cnf and discard the old version, and
be good to go?

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

@Rocko

Sounds like you have an issue unrelated to this bug. See
http://www.ubuntu.com/support/community for community support options,
or if you think there is a different bug in Ubuntu, then please file
that with full details.

@Mohamed

In short, yes. If you don't have a customised configuration, then the
upgrade should switch to the latest configuration automatically. If you
have a locally customised configuration, then you will end up with a
/etc/mysql/my.cnf.migrated file active containing your previous
configuration with those two options renamed. It is not necessary to
make any further changes, but I advise following "Workaround Option 3/3"
anyway to put you in the best place for future upgrades.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Mohamed Hafez]

Hi, so just to clarify, for those of us using do-release-upgrade from
14.04 to 16.04.1, we don't need to worry about manually renaming "key-
buffer-size" and "myisam-recover-options", and all that will
automatically be taken care of for us?

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Rocko]

I found that when it tried to install mysql-5.7 -
5.7.13-0ubuntu0.16.04.2, dpkg just hung forever at postinst (in this
case, forever means overnight). The only way around this was to kill -9
the two mysqld processes that ran (I think one was already running, and
then another ran when I killed the first).

Then I upgraded to yakkety and it installed mysql-
server-5.7_5.7.13-0ubuntu4_amd64.deb and I had exactly the same problem.
Killing the mysqld processes as before allowed dpkg to continue.

I found some other issues too when I tried reinstalling from scratch -
/etc/mysql/my.cnf has the line "!includedir /etc/mysql/conf.d/", but
/etc/mysql/conf.d no longer exists if you have purged mysql before
reinstalling, so the server won't start up and configuration therefore
fails. I had to comment the line out manually to get it to work.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Launchpad Bug Tracker]

This bug was fixed in the package mysql-5.7 - 5.7.13-0ubuntu0.16.04.2

---
mysql-5.7 (5.7.13-0ubuntu0.16.04.2) xenial-security; urgency=medium

  * SECURITY UPDATE: Update to 5.7.13 to fix security issues (LP: #1604796)
- 
http://www.oracle.com/technetwork/security-advisory/cpujul2016-2881720.html
- CVE-2016-3424
- CVE-2016-3459
- CVE-2016-3477
- CVE-2016-3486
- CVE-2016-3501
- CVE-2016-3518
- CVE-2016-3521
- CVE-2016-3588
- CVE-2016-3614
- CVE-2016-3615
- CVE-2016-5436
- CVE-2016-5437
- CVE-2016-5439
- CVE-2016-5440
- CVE-2016-5441
- CVE-2016-5442
- CVE-2016-5443
  * debian/patches/mysql-export-scramble.patch: removed, upstream.

 -- Marc Deslauriers   Wed, 20 Jul 2016
08:44:25 -0400

** Changed in: mysql-5.7 (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3424

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3459

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3477

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3486

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3501

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3518

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3521

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3588

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3614

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-3615

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-5436

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-5437

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-5439

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-5440

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-5441

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-5442

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-5443

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Wellington Torrejais da Silva]

Comment #14 Solved after remove and reinstall (Update not work).
Sorry #14 unnecessary comment.

Thanks!

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Wellington Torrejais da Silva]

This:
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides 
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' 
overrides LSB defaults (0 1 6).

Solved:
sudo update-rc.d  -f mysql remove  &&  sudo update-rc.d mysql defaults

But this still remains:
""
Configurando mysql-server-5.7 (5.7.12-0ubuntu1.2) ...
Renaming removed key_buffer and myisam-recover options (if present)
mysql_upgrade: Got error: 2002: Can't connect to local MySQL server through 
socket '/var/run/mysqld/mysqld.sock' (2) while connecting to the MySQL server
Upgrade process encountered error and will not continue.
mysql_upgrade failed with exit status 11
dpkg: erro ao processar o pacote mysql-server-5.7 (--configure):
 sub-processo script post-installation instalado retornou estado de saída de 
erro 1
dpkg: problemas com dependências impedem a configuração de mysql-server:
 mysql-server depende de mysql-server-5.7; porém:
  Pacote mysql-server-5.7 não está configurado ainda.

dpkg: erro ao processar o pacote mysql-server (--configure):
 problemas de dependência - deixando desconfigurado
Nenhum relatório apport escrito pois a mensagem de erro indica que é um erro de 
seguimento de um erro anterior.

   Erros foram encontrados durante o processamento 
de:
 mysql-server-5.7
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
""

Any ideas?

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Francisco José Cañizares Santofimia]

#12 You're still using the "old" package (5.7.12-0ubuntu1.1) that fails
but I'm talking about the one in proposed (see #10) (5.7.12-0ubuntu1.2).

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[maghfurin]

furin@furin-K43SD:~$ sudo apt-get install -f
[sudo] password for furin:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  linux-headers-4.4.0-22 linux-headers-4.4.0-22-generic
  linux-headers-4.4.0-24 linux-headers-4.4.0-24-generic
  linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic
  linux-image-extra-4.4.0-22-generic linux-image-extra-4.4.0-24-generic
  mysql-server-5.7 mysql-server-core-5.7
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up mysql-server-5.7 (5.7.12-0ubuntu1.1) ...
mysql_upgrade: Got error: 1045: Access denied for user 'root'@'localhost'
(using password: NO) while connecting to the MySQL server
Upgrade process encountered error and will not continue.
mysql_upgrade failed with exit status 11
dpkg: error processing package mysql-server-5.7 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 mysql-server-5.7
E: Sub-process /usr/bin/dpkg returned an error code (1)


On 18 July 2016 at 05:50, Francisco José Cañizares Santofimia <
telefranci...@gmail.com> wrote:

> Latest package in SUR doesn't solves the problem for me. Moreover, log
> in /var/log/mysql.log is empty. Can you tell me how can I provide debug
> info?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1571865
>
> Title:
>   mysql fails to start after upgrade if previous defaults were
>   customised
>
> Status in Release Notes for Ubuntu:
>   Fix Released
> Status in mysql-5.7 package in Ubuntu:
>   Fix Released
> Status in mysql-5.7 source package in Xenial:
>   Fix Committed
>
> Bug description:
>   In 14.04 (both in 5.5 and 5.6), the default /etc/mysql/my.cnf shipped
>   with options "key-buffer" and "myisam-recover". In 5.7, these option
>   names have been removed and replaced with "key-buffer-size" and
>   "myisam-recover-options" instead. If a user customised
>   /etc/mysql/my.cnf before, then the entire file is preserved, including
>   the removed options, causing mysqld to fail to start after upgrade to
>   5.7 (eg. when upgrading to 16.04).
>
>   [Impact]
>   Server will fail to start, causing upgrade/installation of MySQL to fail.
>
>   [Test case]
>   1. Install mysql-server in Ubuntu Trusty
>   2. Edit /etc/mysql/my.cnf and save it (can just add a comment)
>   3. Upgrade distro to Xenial
>
>   Expected behavior:
>   Server upgrades and starts normally
>
>   Actual behavior:
>   Server fails to upgrade, because it can't start, throwing an error about
> 'unknown option key_buffer'
>
>   [Regression Potential]
>   * If the sed command is faulty in some way it could mangle the options,
>   leading to the server not starting and installation failing
>
>   [Workarounds]
>
>   If your customisations were made in 15.04 or 15.10 and
>   /etc/mysql/my.cnf.migrated does not exist, then the workarounds below
>   are still essentially the same but with a couple of exceptions:
>
>   1. Instead of editing /etc/mysql/my.cnf.migrated, edit the file you
>   originally changed directly. This may be /etc/mysql/my.cnf (through
>   the symlink), or a file you changed or added in either
>   /etc/mysql/conf.d/ or /etc/mysql/mysql.conf.d/. The command "grep -Er
>   'key.buffer|myisam.recover' /etc/mysql" may help you in locating this.
>
>   2. No need to run update-alternatives to remove use of
>   /etc/mysql/my.cnf.migrated.
>
>   [Workaround Option 1/3]
>
>   To reset your MySQL configuration back to defaults, type "sudo update-
>   alternatives --remove my.cnf /etc/mysql/my.cnf.migrated" after the
>   upgrade. Then use "sudo service mysql start" to start the MySQL daemon
>   and "sudo apt-get -f install" to recover your system packaging state.
>
>   This option is not available if /etc/mysql/my.cnf.migrated doesn't
>   exist on your system, for example if your customisations were made on
>   15.04 or 15.10.
>
>   [Workaround Option 2/3]
>
>   For a quick fix while retaining your existing customised
>   configuration, edit the [mysqld] section /etc/mysql/my.cnf.migrated as
>   follows. But see the caveats detailed below and consider Workaround
>   Option 3/3 instead first.
>
>   1. Replace "key_buffer" with "key_buffer_size". Note that there is a
>   second occurrance of "key_buffer" under the [isamchk] section at the
>   end of the file; changing this second occurrance is not necessary.
>
>   2. Replace "myisam-recover" with "myisam-recover-options".
>
>   Then use "sudo service mysql start" to start the MySQL daemon again
>   and "sudo apt-get -f install" to recover your system packaging state.
>
>   However, this workaround does not put you in the best place for future
>   upgrades, since 

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Francisco José Cañizares Santofimia]

Latest package in SUR doesn't solves the problem for me. Moreover, log
in /var/log/mysql.log is empty. Can you tell me how can I provide debug
info?

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Adam Conrad]

Hello Joel, or anyone else affected,

Accepted mysql-5.7 into xenial-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.12-0ubuntu1.2 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: mysql-5.7 (Ubuntu Xenial)
   Status: In Progress => Fix Committed

** Tags added: verification-needed

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

Uploaded to Xenial. SRU team: you may find it easier to review if you
verify my uploaded delta is the same as
https://git.launchpad.net/~racb/ubuntu/+source/mysql-5.7/log/?h=mysql-5.7/ubuntu/xenial
and then use that.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

Thanks Mitch. I've updated the workaround accordingly.

** Description changed:

  In 14.04 (both in 5.5 and 5.6), the default /etc/mysql/my.cnf shipped
  with options "key-buffer" and "myisam-recover". In 5.7, these option
  names have been removed and replaced with "key-buffer-size" and "myisam-
  recover-options" instead. If a user customised /etc/mysql/my.cnf before,
  then the entire file is preserved, including the removed options,
  causing mysqld to fail to start after upgrade to 5.7 (eg. when upgrading
  to 16.04).
  
  [Impact]
  Server will fail to start, causing upgrade/installation of MySQL to fail.
  
  [Test case]
  1. Install mysql-server in Ubuntu Trusty
  2. Edit /etc/mysql/my.cnf and save it (can just add a comment)
  3. Upgrade distro to Xenial
  
  Expected behavior:
  Server upgrades and starts normally
  
  Actual behavior:
  Server fails to upgrade, because it can't start, throwing an error about 
'unknown option key_buffer'
  
  [Regression Potential]
  * If the sed command is faulty in some way it could mangle the options,
  leading to the server not starting and installation failing
  
  [Workarounds]
  
  If your customisations were made in 15.04 or 15.10 and
  /etc/mysql/my.cnf.migrated does not exist, then the workarounds below
  are still essentially the same but with a couple of exceptions:
  
  1. Instead of editing /etc/mysql/my.cnf.migrated, edit the file you
  originally changed directly. This may be /etc/mysql/my.cnf (through the
  symlink), or a file you changed or added in either /etc/mysql/conf.d/ or
  /etc/mysql/mysql.conf.d/. The command "grep -Er
  'key.buffer|myisam.recover' /etc/mysql" may help you in locating this.
  
  2. No need to run update-alternatives to remove use of
  /etc/mysql/my.cnf.migrated.
  
  [Workaround Option 1/3]
  
  To reset your MySQL configuration back to defaults, type "sudo update-
  alternatives --remove my.cnf /etc/mysql/my.cnf.migrated" after the
  upgrade. Then use "sudo service mysql start" to start the MySQL daemon
  and "sudo apt-get -f install" to recover your system packaging state.
  
  This option is not available if /etc/mysql/my.cnf.migrated doesn't exist
  on your system, for example if your customisations were made on 15.04 or
  15.10.
  
  [Workaround Option 2/3]
  
  For a quick fix while retaining your existing customised configuration,
  edit the [mysqld] section /etc/mysql/my.cnf.migrated as follows. But see
  the caveats detailed below and consider Workaround Option 3/3 instead
  first.
  
  1. Replace "key_buffer" with "key_buffer_size". Note that there is a
  second occurrance of "key_buffer" under the [isamchk] section at the end
  of the file; changing this second occurrance is not necessary.
  
  2. Replace "myisam-recover" with "myisam-recover-options".
  
  Then use "sudo service mysql start" to start the MySQL daemon again and
  "sudo apt-get -f install" to recover your system packaging state.
  
  However, this workaround does not put you in the best place for future
  upgrades, since packaging will continue to not be able to perfectly
  update this file while preserving your modifications. Additionally there
  may be parts of your previously customised configuration that still will
  not work with MySQL 5.7.
  
  To make future upgrades smoother in the future, consider following the
  next workaround option instead.
  
  [Workaround Option 3/3]
  
  Examine /etc/mysql/my.cnf.migrated for the customisations you made
  previously. You can find an original version of /etc/mysql/my.cnf as
  shipped with 14.04 at: http://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/trusty/mysql-5.5/trusty/view/head:/debian/additions/my.cnf
  
  Determine the changes you made to /etc/mysql/my.cnf. Taking only these
  changes and not the default contents of this file, add just your
- customisations into a new file at /etc/mysql/mysql.conf.d/local.cnf
+ customisations into a new file at /etc/mysql/mysql.conf.d/99local.cnf
  (preferred) and/or by editing /etc/mysql/mysql.conf.d/mysqld.cnf (to be
  avoided if possible) if necessary.
  
  Run: "sudo update-alternatives --remove my.cnf
  /etc/mysql/my.cnf.migrated" to switch to the new configuration scheme.
  
  Run: "sudo service mysql start" to start the MySQL daemon and "sudo apt-
  get -f install" to recover your system packaging state.
  
  [Original Description]
  
  Upgrading from 15.10 to 16.04 fails here
  Not sure if this is related to a bug report already reported.
  
  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: mysql-server-5.7 5.7.11-0ubuntu6
  ProcVersionSignature: Ubuntu 3.19.0-30.34-generic 3.19.8-ckt6
  Uname: Linux 3.19.0-30-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Mon Apr 18 18:13:33 2016
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationDate: Installed on 2014-04-18 (731 days ago)
  InstallationMedia:
  
  Logs.var.log.daemon.log:
  
  

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Lars Tangvald]

** Description changed:

  In 14.04 (both in 5.5 and 5.6), the default /etc/mysql/my.cnf shipped
  with options "key-buffer" and "myisam-recover". In 5.7, these option
  names have been removed and replaced with "key-buffer-size" and "myisam-
  recover-options" instead. If a user customised /etc/mysql/my.cnf before,
  then the entire file is preserved, including the removed options,
  causing mysqld to fail to start after upgrade to 5.7 (eg. when upgrading
  to 16.04).
  
  [Impact]
  Server will fail to start, causing upgrade/installation of MySQL to fail.
  
  [Test case]
  1. Install mysql-server in Ubuntu Trusty
- 2. Edit /etc/mysql/my.cnf and change the value of key_buffer
+ 2. Edit /etc/mysql/my.cnf and save it (can just add a comment)
  3. Upgrade distro to Xenial
- 3. Verify that upgrade of MySQL succeeds
- 4. Verify that in /etc/mysql/my.cnf, key_buffer and myisam-recover are 
renamed, with a comment about why it was done
  
- Alternately, install mysql-server in Xenial/Yakkety, then remove it and
- change key_buffer_size and/or myisam_recover_options to key_buffer and 
myisam_recover in /etc/mysql/mysql.conf.d/mysqld.conf
+ Expected behavior:
+ Server upgrades and starts normally
+ 
+ Actual behavior:
+ Server fails to upgrade, because it can't start, throwing an error about 
'unknown option key_buffer'
  
  [Regression Potential]
- * If the sed command is faulty in some way it could mangle the options, 
+ * If the sed command is faulty in some way it could mangle the options,
  leading to the server not starting and installation failing
  
  [Workarounds]
  
  If your customisations were made in 15.04 or 15.10 and
  /etc/mysql/my.cnf.migrated does not exist, then the workarounds below
  are still essentially the same but with a couple of exceptions:
  
  1. Instead of editing /etc/mysql/my.cnf.migrated, edit the file you
  originally changed directly. This may be /etc/mysql/my.cnf (through the
  symlink), or a file you changed or added in either /etc/mysql/conf.d/ or
  /etc/mysql/mysql.conf.d/. The command "grep -Er
  'key.buffer|myisam.recover' /etc/mysql" may help you in locating this.
  
  2. No need to run update-alternatives to remove use of
  /etc/mysql/my.cnf.migrated.
  
  [Workaround Option 1/3]
  
  To reset your MySQL configuration back to defaults, type "sudo update-
  alternatives --remove my.cnf /etc/mysql/my.cnf.migrated" after the
  upgrade. Then use "sudo service mysql start" to start the MySQL daemon
  and "sudo apt-get -f install" to recover your system packaging state.
  
  This option is not available if /etc/mysql/my.cnf.migrated doesn't exist
  on your system, for example if your customisations were made on 15.04 or
  15.10.
  
  [Workaround Option 2/3]
  
  For a quick fix while retaining your existing customised configuration,
  edit the [mysqld] section /etc/mysql/my.cnf.migrated as follows. But see
  the caveats detailed below and consider Workaround Option 3/3 instead
  first.
  
  1. Replace "key_buffer" with "key_buffer_size". Note that there is a
  second occurrance of "key_buffer" under the [isamchk] section at the end
  of the file; changing this second occurrance is not necessary.
  
  2. Replace "myisam-recover" with "myisam-recover-options".
  
  Then use "sudo service mysql start" to start the MySQL daemon again and
  "sudo apt-get -f install" to recover your system packaging state.
  
  However, this workaround does not put you in the best place for future
  upgrades, since packaging will continue to not be able to perfectly
  update this file while preserving your modifications. Additionally there
  may be parts of your previously customised configuration that still will
  not work with MySQL 5.7.
  
  To make future upgrades smoother in the future, consider following the
  next workaround option instead.
  
  [Workaround Option 3/3]
  
  Examine /etc/mysql/my.cnf.migrated for the customisations you made
  previously. You can find an original version of /etc/mysql/my.cnf as
  shipped with 14.04 at: http://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/trusty/mysql-5.5/trusty/view/head:/debian/additions/my.cnf
  
  Determine the changes you made to /etc/mysql/my.cnf. Taking only these
  changes and not the default contents of this file, add just your
  customisations into a new file at /etc/mysql/mysql.conf.d/local.cnf
  (preferred) and/or by editing /etc/mysql/mysql.conf.d/mysqld.cnf (to be
  avoided if possible) if necessary.
  
  Run: "sudo update-alternatives --remove my.cnf
  /etc/mysql/my.cnf.migrated" to switch to the new configuration scheme.
  
  Run: "sudo service mysql start" to start the MySQL daemon and "sudo apt-
  get -f install" to recover your system packaging state.
  
  [Original Description]
  
  Upgrading from 15.10 to 16.04 fails here
  Not sure if this is related to a bug report already reported.
  
  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: mysql-server-5.7 5.7.11-0ubuntu6
  ProcVersionSignature: Ubuntu 

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Lars Tangvald]

** Description changed:

  In 14.04 (both in 5.5 and 5.6), the default /etc/mysql/my.cnf shipped
  with options "key-buffer" and "myisam-recover". In 5.7, these option
  names have been removed and replaced with "key-buffer-size" and "myisam-
  recover-options" instead. If a user customised /etc/mysql/my.cnf before,
  then the entire file is preserved, including the removed options,
  causing mysqld to fail to start after upgrade to 5.7 (eg. when upgrading
  to 16.04).
+ 
+ [Impact]
+ Server will fail to start, causing upgrade/installation of MySQL to fail.
+ 
+ [Test case]
+ 1. Install mysql-server in Ubuntu Trusty
+ 2. Edit /etc/mysql/my.cnf and change the value of key_buffer
+ 3. Upgrade distro to Xenial
+ 3. Verify that upgrade of MySQL succeeds
+ 4. Verify that in /etc/mysql/my.cnf, key_buffer and myisam-recover are 
renamed, with a comment about why it was done
+ 
+ Alternately, install mysql-server in Xenial/Yakkety, then remove it and
+ change key_buffer_size and/or myisam_recover_options to key_buffer and 
myisam_recover in /etc/mysql/mysql.conf.d/mysqld.conf
+ 
+ [Regression Potential]
+ * If the sed command is faulty in some way it could mangle the options, 
+ leading to the server not starting and installation failing
+ 
+ [Workarounds]
  
  If your customisations were made in 15.04 or 15.10 and
  /etc/mysql/my.cnf.migrated does not exist, then the workarounds below
  are still essentially the same but with a couple of exceptions:
  
  1. Instead of editing /etc/mysql/my.cnf.migrated, edit the file you
  originally changed directly. This may be /etc/mysql/my.cnf (through the
  symlink), or a file you changed or added in either /etc/mysql/conf.d/ or
  /etc/mysql/mysql.conf.d/. The command "grep -Er
  'key.buffer|myisam.recover' /etc/mysql" may help you in locating this.
  
  2. No need to run update-alternatives to remove use of
  /etc/mysql/my.cnf.migrated.
  
  [Workaround Option 1/3]
  
  To reset your MySQL configuration back to defaults, type "sudo update-
  alternatives --remove my.cnf /etc/mysql/my.cnf.migrated" after the
  upgrade. Then use "sudo service mysql start" to start the MySQL daemon
  and "sudo apt-get -f install" to recover your system packaging state.
  
  This option is not available if /etc/mysql/my.cnf.migrated doesn't exist
  on your system, for example if your customisations were made on 15.04 or
  15.10.
  
  [Workaround Option 2/3]
  
  For a quick fix while retaining your existing customised configuration,
  edit the [mysqld] section /etc/mysql/my.cnf.migrated as follows. But see
  the caveats detailed below and consider Workaround Option 3/3 instead
  first.
  
  1. Replace "key_buffer" with "key_buffer_size". Note that there is a
  second occurrance of "key_buffer" under the [isamchk] section at the end
  of the file; changing this second occurrance is not necessary.
  
  2. Replace "myisam-recover" with "myisam-recover-options".
  
  Then use "sudo service mysql start" to start the MySQL daemon again and
  "sudo apt-get -f install" to recover your system packaging state.
  
  However, this workaround does not put you in the best place for future
  upgrades, since packaging will continue to not be able to perfectly
  update this file while preserving your modifications. Additionally there
  may be parts of your previously customised configuration that still will
  not work with MySQL 5.7.
  
  To make future upgrades smoother in the future, consider following the
  next workaround option instead.
  
  [Workaround Option 3/3]
  
  Examine /etc/mysql/my.cnf.migrated for the customisations you made
  previously. You can find an original version of /etc/mysql/my.cnf as
  shipped with 14.04 at: http://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/trusty/mysql-5.5/trusty/view/head:/debian/additions/my.cnf
  
  Determine the changes you made to /etc/mysql/my.cnf. Taking only these
  changes and not the default contents of this file, add just your
  customisations into a new file at /etc/mysql/mysql.conf.d/local.cnf
  (preferred) and/or by editing /etc/mysql/mysql.conf.d/mysqld.cnf (to be
  avoided if possible) if necessary.
  
  Run: "sudo update-alternatives --remove my.cnf
  /etc/mysql/my.cnf.migrated" to switch to the new configuration scheme.
  
  Run: "sudo service mysql start" to start the MySQL daemon and "sudo apt-
  get -f install" to recover your system packaging state.
  
  [Original Description]
  
  Upgrading from 15.10 to 16.04 fails here
  Not sure if this is related to a bug report already reported.
  
  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: mysql-server-5.7 5.7.11-0ubuntu6
  ProcVersionSignature: Ubuntu 3.19.0-30.34-generic 3.19.8-ckt6
  Uname: Linux 3.19.0-30-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Mon Apr 18 18:13:33 2016
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationDate: Installed on 2014-04-18 (731 days ago)
  InstallationMedia:

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

** Changed in: mysql-5.7 (Ubuntu Xenial)
Milestone: None => ubuntu-16.04.1

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Launchpad Bug Tracker]

This bug was fixed in the package mysql-5.7 - 5.7.13-0ubuntu3

---
mysql-5.7 (5.7.13-0ubuntu3) yakkety; urgency=medium

  * Automatically replace removed config options from 5.5 and old 5.6
installations (LP: #1571865). Cherry-picked from Debian VCS ef3f92b.
Thanks to Lars Tangvald.

 -- Robie Basak   Tue, 12 Jul 2016 17:45:00
+0100

** Changed in: mysql-5.7 (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

** Changed in: mysql-5.7 (Ubuntu Xenial)
   Status: Triaged => In Progress

** Changed in: mysql-5.7 (Ubuntu Xenial)
 Assignee: Lars Tangvald (lars-tangvald) => Robie Basak (racb)

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

** Changed in: mysql-5.7 (Ubuntu)
   Status: In Progress => Fix Committed

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Stephen Baker]

I had spent a few hours on this with no resolution.  Even with the mysql
service running as root, it failed to get permissions to write to a data
directory other than /var/lib/mysql (or whatever the default is if that's
wrong).  Even with apparmor configured to allow the new data directory, and
even in complain mode, it still failed to read/write files in the new
datadir or couldn't open a socket.

My fix was moving my data to the location; mounting a device to
/var/lib/mysql.

On Tue, Jun 21, 2016 at 11:43 AM, Mitch Claborn <1571...@bugs.launchpad.net>
wrote:

> Re: [Workaround Option 3/3]
>
> I tried this method, placing my local customizations in
> /etc/mysql/mysql.conf.d/local.cnf but mysqld did not pick those up. I
> had to name my file zzlocal.cnf. I'm guessing it reads those file in
> alpha order, with the later files overriding the earlier.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1573878).
> https://bugs.launchpad.net/bugs/1571865
>
> Title:
>   mysql fails to start after upgrade if previous defaults were
>   customised
>
> Status in Release Notes for Ubuntu:
>   Fix Released
> Status in mysql-5.7 package in Ubuntu:
>   In Progress
> Status in mysql-5.7 source package in Xenial:
>   Triaged
>
> Bug description:
>   In 14.04 (both in 5.5 and 5.6), the default /etc/mysql/my.cnf shipped
>   with options "key-buffer" and "myisam-recover". In 5.7, these option
>   names have been removed and replaced with "key-buffer-size" and
>   "myisam-recover-options" instead. If a user customised
>   /etc/mysql/my.cnf before, then the entire file is preserved, including
>   the removed options, causing mysqld to fail to start after upgrade to
>   5.7 (eg. when upgrading to 16.04).
>
>   If your customisations were made in 15.04 or 15.10 and
>   /etc/mysql/my.cnf.migrated does not exist, then the workarounds below
>   are still essentially the same but with a couple of exceptions:
>
>   1. Instead of editing /etc/mysql/my.cnf.migrated, edit the file you
>   originally changed directly. This may be /etc/mysql/my.cnf (through
>   the symlink), or a file you changed or added in either
>   /etc/mysql/conf.d/ or /etc/mysql/mysql.conf.d/. The command "grep -Er
>   'key.buffer|myisam.recover' /etc/mysql" may help you in locating this.
>
>   2. No need to run update-alternatives to remove use of
>   /etc/mysql/my.cnf.migrated.
>
>   [Workaround Option 1/3]
>
>   To reset your MySQL configuration back to defaults, type "sudo update-
>   alternatives --remove my.cnf /etc/mysql/my.cnf.migrated" after the
>   upgrade. Then use "sudo service mysql start" to start the MySQL daemon
>   and "sudo apt-get -f install" to recover your system packaging state.
>
>   This option is not available if /etc/mysql/my.cnf.migrated doesn't
>   exist on your system, for example if your customisations were made on
>   15.04 or 15.10.
>
>   [Workaround Option 2/3]
>
>   For a quick fix while retaining your existing customised
>   configuration, edit the [mysqld] section /etc/mysql/my.cnf.migrated as
>   follows. But see the caveats detailed below and consider Workaround
>   Option 3/3 instead first.
>
>   1. Replace "key_buffer" with "key_buffer_size". Note that there is a
>   second occurrance of "key_buffer" under the [isamchk] section at the
>   end of the file; changing this second occurrance is not necessary.
>
>   2. Replace "myisam-recover" with "myisam-recover-options".
>
>   Then use "sudo service mysql start" to start the MySQL daemon again
>   and "sudo apt-get -f install" to recover your system packaging state.
>
>   However, this workaround does not put you in the best place for future
>   upgrades, since packaging will continue to not be able to perfectly
>   update this file while preserving your modifications. Additionally
>   there may be parts of your previously customised configuration that
>   still will not work with MySQL 5.7.
>
>   To make future upgrades smoother in the future, consider following the
>   next workaround option instead.
>
>   [Workaround Option 3/3]
>
>   Examine /etc/mysql/my.cnf.migrated for the customisations you made
>   previously. You can find an original version of /etc/mysql/my.cnf as
>   shipped with 14.04 at: http://bazaar.launchpad.net/~ubuntu-
>
> branches/ubuntu/trusty/mysql-5.5/trusty/view/head:/debian/additions/my.cnf
>
>   Determine the changes you made to /etc/mysql/my.cnf. Taking only these
>   changes and not the default contents of this file, add just your
>   customisations into a new file at /etc/mysql/mysql.conf.d/local.cnf
>   (preferred) and/or by editing /etc/mysql/mysql.conf.d/mysqld.cnf (to
>   be avoided if possible) if necessary.
>
>   Run: "sudo update-alternatives --remove my.cnf
>   /etc/mysql/my.cnf.migrated" to switch to the new configuration scheme.
>
>   Run: "sudo service mysql start" to start the MySQL daemon and "sudo
>   apt-get -f install" to recover your system packaging state.
>
>   [Original Description]

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Mitch Claborn]

Re: [Workaround Option 3/3]

I tried this method, placing my local customizations in
/etc/mysql/mysql.conf.d/local.cnf but mysqld did not pick those up. I
had to name my file zzlocal.cnf. I'm guessing it reads those file in
alpha order, with the later files overriding the earlier.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

** Changed in: mysql-5.7 (Ubuntu)
Milestone: None => ubuntu-16.05

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

** Changed in: mysql-5.7 (Ubuntu)
 Assignee: (unassigned) => Lars Tangvald (lars-tangvald)

** Changed in: mysql-5.7 (Ubuntu Xenial)
 Assignee: (unassigned) => Lars Tangvald (lars-tangvald)

** Changed in: mysql-5.7 (Ubuntu)
   Status: Triaged => In Progress

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Doug Smythies]

In my case there was no customization. All 3 of my effected 16.04
servers were fresh installs of 16.04 during the development phase of
16.04. This was all two or three weeks ago. I finally sorted out the
mess, by re-installing mysql.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

** Also affects: mysql-5.7 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: mysql-5.7 (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: mysql-5.7 (Ubuntu Xenial)
   Status: New => Triaged

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Mathew Hodson]

** Changed in: mysql-5.7 (Ubuntu)
   Status: Fix Released => Triaged

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Stein Rune Risa]

This was wrongly marked as fixed by me. Please rollback that change.

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Stein Rune Risa]

** Changed in: mysql-5.7 (Ubuntu)
   Status: Triaged => Fix Released

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Mathew Hodson]

** Tags added: dist-upgrade

** Also affects: ubuntu-release-notes
   Importance: Undecided
   Status: New

** Changed in: ubuntu-release-notes
   Status: New => Fix Released

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1571865] Re: mysql fails to start after upgrade if previous defaults were customised

[Robie Basak]

** Description changed:

  In 14.04 (both in 5.5 and 5.6), the default /etc/mysql/my.cnf shipped
  with options "key-buffer" and "myisam-recover". In 5.7, these option
  names have been removed and replaced with "key-buffer-size" and "myisam-
  recover-options" instead. If a user customised /etc/mysql/my.cnf before,
  then the entire file is preserved, including the removed options,
  causing mysqld to fail to start after upgrade to 5.7 (eg. when upgrading
  to 16.04).
  
  If your customisations were made in 15.04 or 15.10 and
  /etc/mysql/my.cnf.migrated does not exist, then the workarounds below
  are still essentially the same but with a couple of exceptions:
  
  1. Instead of editing /etc/mysql/my.cnf.migrated, edit the file you
  originally changed directly. This may be /etc/mysql/my.cnf (through the
  symlink), or a file you changed or added in either /etc/mysql/conf.d/ or
  /etc/mysql/mysql.conf.d/. The command "grep -Er
  'key.buffer|myisam.recover' /etc/mysql" may help you in locating this.
  
  2. No need to run update-alternatives to remove use of
  /etc/mysql/my.cnf.migrated.
  
  [Workaround Option 1/3]
  
  To reset your MySQL configuration back to defaults, type "sudo update-
  alternatives --remove my.cnf /etc/mysql/my.cnf.migrated" after the
- upgrade. Then use "sudo service mysql start" to start the MySQL daemon.
+ upgrade. Then use "sudo service mysql start" to start the MySQL daemon
+ and "sudo apt-get -f install" to recover your system packaging state.
  
  This option is not available if /etc/mysql/my.cnf.migrated doesn't exist
  on your system, for example if your customisations were made on 15.04 or
  15.10.
  
  [Workaround Option 2/3]
  
  For a quick fix while retaining your existing customised configuration,
  edit the [mysqld] section /etc/mysql/my.cnf.migrated as follows. But see
  the caveats detailed below and consider Workaround Option 3/3 instead
  first.
  
  1. Replace "key_buffer" with "key_buffer_size". Note that there is a
  second occurrance of "key_buffer" under the [isamchk] section at the end
  of the file; changing this second occurrance is not necessary.
  
  2. Replace "myisam-recover" with "myisam-recover-options".
  
- Then use "sudo service mysql start" to start the MySQL daemon again.
+ Then use "sudo service mysql start" to start the MySQL daemon again and
+ "sudo apt-get -f install" to recover your system packaging state.
  
  However, this workaround does not put you in the best place for future
  upgrades, since packaging will continue to not be able to perfectly
  update this file while preserving your modifications. Additionally there
  may be parts of your previously customised configuration that still will
  not work with MySQL 5.7.
  
  To make future upgrades smoother in the future, consider following the
  next workaround option instead.
  
  [Workaround Option 3/3]
  
  Examine /etc/mysql/my.cnf.migrated for the customisations you made
  previously. You can find an original version of /etc/mysql/my.cnf as
  shipped with 14.04 at: http://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/trusty/mysql-5.5/trusty/view/head:/debian/additions/my.cnf
  
  Determine the changes you made to /etc/mysql/my.cnf. Taking only these
  changes and not the default contents of this file, add just your
  customisations into a new file at /etc/mysql/mysql.conf.d/local.cnf
  (preferred) and/or by editing /etc/mysql/mysql.conf.d/mysqld.cnf (to be
  avoided if possible) if necessary.
  
  Run: "sudo update-alternatives --remove my.cnf
  /etc/mysql/my.cnf.migrated" to switch to the new configuration scheme.
  
- Run: "sudo service mysql start" to start the MySQL daemon.
+ Run: "sudo service mysql start" to start the MySQL daemon and "sudo apt-
+ get -f install" to recover your system packaging state.
  
  [Original Description]
  
  Upgrading from 15.10 to 16.04 fails here
  Not sure if this is related to a bug report already reported.
  
  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: mysql-server-5.7 5.7.11-0ubuntu6
  ProcVersionSignature: Ubuntu 3.19.0-30.34-generic 3.19.8-ckt6
  Uname: Linux 3.19.0-30-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Mon Apr 18 18:13:33 2016
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationDate: Installed on 2014-04-18 (731 days ago)
  InstallationMedia:
  
  Logs.var.log.daemon.log:
  
  MySQLConf.etc.mysql.conf.d.mysql.cnf: [mysql]
  MySQLConf.etc.mysql.conf.d.mysqld_safe_syslog.cnf:
   [mysqld_safe]
   syslog
  MySQLConf.etc.mysql.conf.d.mysqldump.cnf:
   [mysqldump]
   quick
   quote-names
   max_allowed_packet   = 16M
  MySQLConf.etc.mysql.mysql.conf.d.mysqld_safe_syslog.cnf:
   [mysqld_safe]
   syslog
  MySQLVarLibDirListing: ['debian-5.7.flag', 'debian-5.5.flag', 
'debian-5.6.flag', 'ib_logfile1', 'drupal8', 'servermail', 'ib_logfile0', 
'auto.cnf', 'risenlif_risenlife2', 'dynazu_wiki', 'performance_schema', 
'ibdata1',