Bug 1628989

Summary: mysql_upgrade fails with mysqlcheck: [ERROR] unknown variable 'process-views=YES'
Product: [Fedora] Fedora Reporter: Alex Regan <mysqlstudent>
Component: mariadbAssignee: Michal Schorm <mschorm>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 28CC: dciabrin, hhorak, jstanek, mbayer, mkocka, mmuzila, mschorm, mysqlstudent, praiskup
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-09 12:15:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alex Regan 2018-09-14 15:04:13 UTC
Description of problem:
mysqlcheck: [ERROR] unknown variable 'process-views=YES' on attempt to perform mysql_upgrade

Version-Release number of selected component (if applicable):
# rpm -qva|grep mariadb

How reproducible:

Steps to Reproduce:
1. mysql_upgrade -u root -p

Actual results:
# mysql_upgrade -u root -p
Enter password: 
Phase 1/7: Checking and upgrading mysql database
# Connecting to localhost...
# Disconnecting from localhost...
mysql.column_stats                                 OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.general_log                                  OK
mysql.gtid_slave_pos                               OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.index_stats                                  OK
mysql.innodb_index_stats                           OK
mysql.innodb_table_stats                           OK
mysql.ndb_binlog_index                             OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.roles_mapping                                OK
mysql.servers                                      OK
mysql.slow_log                                     OK
mysql.table_stats                                  OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
Phase 2/7: Installing used storage engines... Skipped
Phase 3/7: Fixing views
mysqlcheck: [ERROR] unknown variable 'process-views=YES'
FATAL ERROR: Upgrade failed

Expected results:
mysql_upgrade should fix problem that appears to have resulted from upgrading from a previous version.

Sep 14 10:54:11 bwimail01 mysqld[1715]: 2018-09-14 10:54:11 140264890173184 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade

Additional info:

Comment 1 Alex Regan 2018-09-14 15:07:26 UTC
# rpm -qf /usr/bin/mysqlcheck

# mysqlcheck --version
mysqlcheck  Ver 2.5.1 Distrib 5.7.22, for Linux (x86_64)

Is it possible mysqlcheck-5.7.22 is incompatible with mariadb-10.2.17?

Comment 2 Alex Regan 2018-09-14 15:09:15 UTC
Oh, I see there's an update to community-mysql-5.7.23-1.fc28.x86_64 but it also fails.

Comment 3 Alex Regan 2018-09-14 15:35:52 UTC
It looks like this was the result of some weird dependency that left community-mysql installed and not the top-level mariadb package.

# rpm -e --nodeps community-mysql
# dnf install mariadb

This was perhaps an artifact from a previous upgrade from fc27 or older.

Comment 4 Michal Schorm 2018-09-24 11:36:23 UTC
As far as I understand, the issue was in "mysqlcheck" binary, which probably isn't applicable from MariaDB to MySQL and vice versa.

After some package cleanup you managed to get it working as expected.


I will take a brief look at the "mysqlcheck".

A check of version could be implemented in the "mysqlcheck" at the start, to warn user about such issue.

Fedora is - as far as I know - the only place where can be MariaDB and MySQL mixed (nor RHEL, CentOS, Debian, Ubuntu, nor MariaDB nor Oracle upstream packages).
So if you don't feel like contributing a fix to the MariaDB, I think no one will ever take found this as a issue.


If you don't have anything more to this issue, I'll close it as a WONTFIX.

Comment 5 Alex Regan 2018-10-09 01:36:19 UTC
I don't have anything to add other than I'm curious how community-mysql survived through the dependency checks...

Comment 6 Michal Schorm 2018-10-09 12:15:25 UTC
(In reply to Alex Regan from comment #5)
> I don't have anything to add other than I'm curious how community-mysql
> survived through the dependency checks...

As I said, in Fedora, I'm trying to keep MariaDB & MySQL cross installable (and cross usable). That means you can use on of those servers with the other client.

The goal is to let user develop and test his application with any combination on the same machine. In the internet the client ussually don't know or care to which release of the server they are connecting, as long as it works - thanks to the same API.


In the package, there are number of utilities, for server and client. While in the client remained mostly utils that are able to connect to the remote host.

mysqlcheck is one of them.


It should be pretty clear now, that this can happen pretty easily.


A fix for this issue could be moving mysqlcheck to the server part.
However since nobody does that (MariaDB or MySQL upstream, Fedora, RHEL, CentOS, Debian, Ubuntu ...) I don't see that as a smart move.

And since Fedora is the only place that can hit this problem - by maintaining unsupported configuration - none of the upstreams would care, I believe.


I added a warning and a link to this bugzilla to the wiki page:

Didn't knew this page? :)
There's  more: