MariaDB upgrade fails due to corrupted/missing package


Sep 10, 2021
cPanel Access Level
Root Administrator
MariaDB upgrade fails due to corrupted/missing package.
When we run MySQL/MariaDB Upgrade in WHM, cPanel overwrites the Mariadb repo file each time we modify baseurl value.

Starting process with log file at /var/cpanel/logs/mysql_upgrade.20220823-193643/unattended_upgrade.log
Beginning “MariaDB 10.6” upgrade...
Obtained version information from system.
Ensuring the “MariaDB102” repository is available and working.
distro does not use package modules; ignoring request to disable mysql
distro does not use package modules; ignoring request to disable mariadb
checkyum version 22.3 (excludes: bind-chroot)
Ensuring that the package “MariaDB-client” with version matching “10.2” is available.
Restarting mysql service.
Waiting for “mysql” to restart ……waiting for “mysql” to initialize ………finished.

Service Status
mysqld (/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/ is running as mysql with PID 9368 (systemd+/proc check method).

Startup Log
Aug 23 19:36:50 systemd[1]: Starting MySQL Server...
Aug 23 19:36:51 systemd[1]: Started MySQL Server.

Log Messages
2022-08-23T17:36:51.651933Z 0 [Note] /usr/sbin/mysqld: ready for connections.
2022-08-23T17:36:50.743821Z 0 [Note] /usr/sbin/mysqld: Shutdown complete
2022-08-23T17:36:48.899199Z 0 [Warning] /usr/sbin/mysqld: Forcing close of thread 20 user: 'root'

mysql restarted successfully.
The system was not able to ensure the availability of the “MariaDB-client” package: The package “MariaDB-client” with version “10.2” is not available via yum: Loaded plugins: fastestmirror, universal-hooks
Loading mirror speeds from cached hostfile
* EA4:
* cpanel-addons-production-feed:
* cpanel-plugins:
* base:
* epel:
* extras:
* updates:
Available Packages
MariaDB-client.x86_64 10.6.9-1.el7.centos MariaDB102
Obtained version information from system.
Proceeding with MySQL/MariaDB upgrade despite the following:
Critical: MariaDB enables "strict mode" by default as of version 10.2. Strict mode controls how MariaDB and MySQL handle invalid or missing values in data-change statements such as INSERT or UPDATE. Applications not built with strict mode enabled may cause undesired behavior; please verify applications using MariaDB are compatible before upgrading. More information about strict mode is available here. Critical: In MariaDB® 10.3, the mysqldump client includes logic for the mysql.transaction_registry table. You cannot use the mysqldump client from an earlier MariaDB release on MariaDB 10.3 and later. For more information about how to upgrade to MariaDB 10.3, read the MariaDB upgrade documentation. Critical: In MariaDB 10.4 and later, the mysql.global_priv table has replaced the mysql.user table. The mysql.user table is converted into a view of the mysql.global_priv table during the database upgrade. The dedicated mariadb.sys user is created as the definer of the new mysql.user view.
Critical: The "mytop" package is not compatible due to MDEV-22552. If "mytop" is installed, the upgrade process will uninstall the "mytop" package.
Normal: All binaries previously beginning with `mysql` now begin with `mariadb`. Symlinks are created for the corresponding mysql commands to ensure backwards compatibility. Usually that should not cause any changed behavior, but when starting the MariaDB server via systemd, or via the `mysqld_safe` script symlink, the server process will now always be started as `mariadbd`,
not`mysqld`. Any 3rd party software or scripts looking for the `mysqld` name in the system process list
must now look for `mariadbd` instead. Normal: The selected MariaDB version (10.6) is more than one generation newer than the currently installed version. The upgrade process will iterate over each intervening version to ensure tables are upgraded appropriately.
Normal: MariaDB 10.6 introduced a new reserved word: OFFSET. This can no longer be used as an identifier without being quoted.
Normal: From MariaDB 10.6, tables that are of the `COMPRESSED` row format are read-only by default. This is the first step towards removing write support and deprecating the feature. The `innodb_read_only_compressed` variable
must be set to `OFF` in order to make the tables writable.


Jurassic Moderator
Staff member
Oct 19, 2014
cPanel Access Level
Root Administrator
Hey there! The place where this is getting the most attention is here:

We're currently working on fixing issue number 3 to properly handle the changes that MariaDB made to their repositories, but unless you absolutely need to update, it's best to wait.