[MDEV-8394] Upgrade from Version: '10.0.20-MariaDB' corrupted Created: 2015-06-29  Updated: 2015-08-30  Resolved: 2015-08-30

Status: Closed
Project: MariaDB Server
Component/s: Platform SUSE
Affects Version/s: 10.1.5
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Andy Lavarre Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: need_feedback
Environment:

Linux openSUSE 13.1, 13.2



 Description   

Automatic upgrade from Version: '10.0.20-MariaDB under OpenSuse 13.1-64 to Version 10.1.5-5.1 results in 'service mysql restart' failure:

  • lavarre:~ # rcmysql status gives the same as above:
    ExecStartPre=/usr/lib/mysql/mysql-systemd-helper upgrade default (code=exited,
    status=1/FAILURE)*

I downgraded the installation to Version: '10.0.20-2.1-x86_64' and it now functions correctly.

This upgrade also fails under openSUSE 13.2. In that case I restored the upgrade to
10.0.20-2.1-x86_64. This works correctly.



 Comments   
Comment by Elena Stepanova [ 2015-06-30 ]

alavarre@gmail.com,

Please attach or paste the contents of the MariaDB error log.

For better understanding what's going on, could you please clarify how the automatic upgrade happens? As I understand, the official repo on openSUSE provides MariaDB 5.5, so how did 10.0 made it into the system, and even more surprisingly, where does it get upgraded from – 10.1 is not even a GA yet, it cannot possibly be in openSUSE repositories?

Comment by Vladimir Sachek [ 2015-07-14 ]

I seem to have similar problem on fresh OpenSuse 13.2 installation. Here is my log file

linux-6xbt:/var/log/mysql # rcmysql start
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Job for mysql.service failed. See "systemctl status mysql.service" and "journalctl -xn" for details.
linux-6xbt:/var/log/mysql # systemctl status mysql.service
mysql.service - MySQL server
Loaded: loaded (/usr/lib/systemd/system/mysql.service; disabled)
Active: failed (Result: exit-code) since Tue 2015-07-14 22:03:30 EEST; 2min 4s ago
Process: 10215 ExecStartPre=/usr/lib/mysql/mysql-systemd-helper upgrade default (code=exited, status=1/FAILURE)
Process: 10206 ExecStartPre=/usr/lib/mysql/mysql-systemd-helper install default (code=exited, status=0/SUCCESS)
Main PID: 1089 (code=exited, status=1/FAILURE)

Jul 14 22:02:30 linux-6xbt.site mysql-systemd-helper[10215]: Checking MySQL configuration for obsolete options...
Jul 14 22:02:30 linux-6xbt.site mysql-systemd-helper[10215]: Trying to run upgrade of MySQL databases...
Jul 14 22:02:30 linux-6xbt.site mysql-systemd-helper[10215]: Stale files from previous upgrade detected, cleaned them up
Jul 14 22:02:30 linux-6xbt.site mysql-systemd-helper[10215]: Running protected MySQL...
Jul 14 22:02:30 linux-6xbt.site mysql-systemd-helper[10215]: Waiting for MySQL to start
Jul 14 22:02:30 linux-6xbt.site mysql-systemd-helper[10215]: 150714 22:02:30 [Warning] option 'group_concat_max_len': unsigned value 0 adjusted to 4
Jul 14 22:02:30 linux-6xbt.site mysql-systemd-helper[10215]: 150714 22:02:30 [Note] /usr/sbin/mysqld (mysqld 10.0.20-MariaDB) starting as process 10234 ...
Jul 14 22:03:30 linux-6xbt.site mysql-systemd-helper[10215]: MySQL is still dead
Jul 14 22:03:30 linux-6xbt.site mysql-systemd-helper[10215]: MySQL didn't start, can't continue
Jul 14 22:03:30 linux-6xbt.site systemd[1]: Failed to start MySQL server.

Comment by Vladimir Sachek [ 2015-07-14 ]

By running mysql_safe i got an actual error: File '/var/lib/mysql/aria_log_control' not found (Errcode: 13 "Permission denied")

150714 22:33:15 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150714 22:33:15 [Note] /usr/sbin/mysqld (mysqld 10.0.20-MariaDB) starting as process 12161 ...
150714 22:33:15 [ERROR] mysqld: File '/var/lib/mysql/aria_log_control' not found (Errcode: 13 "Permission denied")
150714 22:33:15 [ERROR] mysqld: Got error 'Can't open file' when trying to use aria control file '/var/lib/mysql/aria_log_control'
150714 22:33:15 [ERROR] Plugin 'Aria' init function returned error.
150714 22:33:15 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
150714 22:33:15 [Note] InnoDB: Using mutexes to ref count buffer pool pages
150714 22:33:15 [Note] InnoDB: The InnoDB memory heap is disabled
150714 22:33:15 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
150714 22:33:15 [Note] InnoDB: Memory barrier is not used
150714 22:33:15 [Note] InnoDB: Compressed tables use zlib 1.2.8
150714 22:33:15 [Note] InnoDB: Using Linux native AIO
150714 22:33:15 [Note] InnoDB: Using CPU crc32 instructions
150714 22:33:15 [Note] InnoDB: Initializing buffer pool, size = 128.0M
150714 22:33:15 [Note] InnoDB: Completed initialization of buffer pool
150714 22:33:15 [ERROR] InnoDB: ./ibdata1 can't be opened in read-write mode
150714 22:33:15 [ERROR] InnoDB: The system tablespace must be writable!
150714 22:33:15 [ERROR] Plugin 'InnoDB' init function returned error.
150714 22:33:15 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
150714 22:33:15 [ERROR] Unknown/unsupported storage engine: InnoDB
150714 22:33:15 [ERROR] Aborting

Comment by Elena Stepanova [ 2015-07-15 ]

vladimir.sachek, did you run mysqld_safe as a superuser?

Comment by Vladimir Sachek [ 2015-07-15 ]

Yes run that as superuser.
First I removed aria_log_control file, rerun mysql_safe. Then some other file from that folder was not accessible. And so on until I started to get errors like [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure.

In the end I uninstalled mysql, removed /var/lib/mysql directory and install mysql again. This solved the problem.

Comment by Elena Stepanova [ 2015-08-01 ]

Files in the datadir should be writable by mysql user. If it so happens that, for example, the server was once started under root rather than mysql and created these files with the root ownership, the problem could have happened. It did not necessarily have to be a human error, could be a bug in the installation process of 10.1. In case of vladimir.sachek, it would be interesting to find out what caused this, but I suppose it's impossible since the second installation attempt went all right.

Due to the lack of information, it's still unclear whether the initial case from alavarre@gmail.com was the same, logs could have clarified it.

Comment by Elena Stepanova [ 2015-08-30 ]

If you have more information, please comment to re-open the issue.

Generated at Thu Feb 08 07:26:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.