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 mariadb-errmsg-10.2.17-1.fc28.x86_64 mariadb-gssapi-server-10.2.17-1.fc28.x86_64 mariadb-config-10.2.17-1.fc28.x86_64 mariadb-tokudb-engine-10.2.17-1.fc28.x86_64 mariadb-server-10.2.17-1.fc28.x86_64 mariadb-backup-10.2.17-1.fc28.x86_64 mariadb-cracklib-password-check-10.2.17-1.fc28.x86_64 mariadb-server-utils-10.2.17-1.fc28.x86_64 mariadb-connector-c-3.0.6-1.fc28.x86_64 mariadb-common-10.2.17-1.fc28.x86_64 mariadb-rocksdb-engine-10.2.17-1.fc28.x86_64 How reproducible: Steps to Reproduce: 1. mysql_upgrade -u root -p 2. 3. 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:
# rpm -qf /usr/bin/mysqlcheck community-mysql-5.7.22-1.fc28.x86_64 # 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?
Oh, I see there's an update to community-mysql-5.7.23-1.fc28.x86_64 but it also fails.
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.
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.
I don't have anything to add other than I'm curious how community-mysql survived through the dependency checks...
(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: https://fedoraproject.org/wiki/MariaDB_software Didn't knew this page? :) There's more: https://fedoraproject.org/wiki/Category:Package_MariaDB