Hi Fi, 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. >From your logs I see: 2018-04-26T08:23:00.237766Z 0 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 11 2018-04-26T08:23:00.237807Z 0 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files. 2018-04-26T08:23:00.237830Z 0 [Note] InnoDB: Unable to open the first data file 2018-04-26T08:23:00.237850Z 0 [ERROR] InnoDB: Operating system error number 11 in a file operation. 2018-04-26T08:23:00.237865Z 0 [ERROR] InnoDB: Error number 11 means 'Resource temporarily unavailable' 2018-04-26T08:23:00.237875Z 0 [Note] InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html 2018-04-26T08:23:00.237887Z 0 [ERROR] InnoDB: Cannot open datafile './ibdata1' 2018-04-26T08:23:00.237898Z 0 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! 2018-04-26T08:23:00.237909Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Cannot open a file So in your case the restart after upgrade fails, due to these issues. That might indicate the DB wasn't shut down cleanly and the lock still is on the file OR that another mysql service is running at the same time having it already locked. If you have no resonable data in your mysql anyway the quickest might just to reinstall it like [1]. Otherwise you might want to look which process has the file open and resolve that as in [2] Setting to incomplete as it appears to be more a misconfig or support request than a bug in ubuntu for now, but I'll subscribe myself to see what you find following the above. [1]: https://askubuntu.com/questions/341943/how-to-uninstal-mysql-5-6-and-reinstall-5-5/428515 [2]: https://serverfault.com/questions/477448/mysql-keeps-crashing-innodb-unable-to-lock-ibdata1-error-11 ** Changed in: mysql-5.7 (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1767085 Title: package mysql-server-5.7 5.7.22-0ubuntu0.16.04.1 failed to install/upgrade: podproces zainstalowany skrypt post-installation zwrócił kod błędu 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1767085/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
