Description of problem: In order to avoid failure of zoneminder when mariadb versions change, the zmsetup script runs mysqlcheck. This has never given problems in Mga8 but it repeatably fails in Cauldron. Attached is the full output of zmsetup in Mga8 and the same output from it in Cauldron. These are taken from a Mga8 VM and the same VM upgraded to Mga9. The first instance of this showed up in another real system, where the mariadb install is now broken. The VM testing was purely for this report. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 12983 [details] Normal operation in Mga8
Created attachment 12984 [details] Failing in Mga9
Assigning to registered maintainer.
CC: (none) => ftgAssignee: bugsquad => mageia
There are similar but very old reports here: https://jira.mariadb.org/browse/MDEV-8117 https://jira.mariadb.org/browse/MDEV-8115 https://jira.mariadb.org/browse/MDEV-6916 There is a note in here: https://docs.w3cub.com/mariadb/repair-view/index that says "Note that REPAIR VIEW in MariaDB 10.0.18 and MariaDB 5.5.43 could crash the server (see MDEV-8115). Upgrade to a later version." Maybe this bug has re-surfaced in 10.6.4 ? It was OK in 10.5.12 on Mga8. Once this has happened, mysqld will no longer start. I don't know how to fix it. "Exited with Error code" does not help much :\
A little background that may help: mysql_upgrade is called from http://svnweb.mageia.org/packages/cauldron/zoneminder/current/SOURCES/zmsetup?revision=1755397&view=markup at line 243. mysql_update calls mysqlcheck, which it seems is the tool that is failing. Running mysql_upgrade should not normally break anything see docs here: https://docs.w3cub.com/mariadb/mysql_upgrade/index If nothing needs updating it normally returns a message to that effect and closes.
s/mysql_update/mysql_upgrade/ Sorry typo :/
Running mysql_upgrade with -vvvv does not help much: Phase 3/7: Fixing views Running 'mysqlcheck' with connection arguments: --port='3306' --socket='/var/lib/mysql/mysql.sock' 'mysqlcheck' --defaults-file=/tmp/mysql_upgrade-PvkDae --all-databases --repair --process-views=YES --skip-process-tables --verbose --skip-write-binlog 2>&1 Processing databases information_schema mysql mysqlcheck: Got error: 2013: Lost connection to server during query when executing 'REPAIR NO_WRITE_TO_BINLOG VIEW ... ' FATAL ERROR: Upgrade failed However in this Mga9 VM I *CAN* still restart mysqld which was not the case when this error occured on a real system. ZoneMinder of course will not run as the zmsetup script does not get past mysql_update to upgrade the ZoneMinder database to the new zm db version which it requires to start.
Created attachment 12986 [details] Running mysql_upgrade from command line without zmsetup script Just to pull zmsetup script out of the arena this is the output from just running msql_upgrade.
Sorry for the late reply. It looks like some upgrade table definition does not match the running version. I've created an upstream bug for it: https://jira.mariadb.org/browse/MDEV-27236 The connection is lost, since the server "crashes" (restarts), as you can see in the logs. Thanks for testing! I hope this gets fixed soon, as mariadb will start to release new versions every 1/4 of a year....
See Also: (none) => https://jira.mariadb.org/browse/MDEV-27236
So far it looks like this has to do with openssl upgrade to V3...
"You can see that MDEV-25785 has FixVersion: 10.8, so it's being implemented for 10.8. This is the plan." https://jira.mariadb.org/browse/MDEV-25785 We'll see what else fails due to ssl upgrade...
old - cauldron is released.
Status: NEW => RESOLVEDResolution: (none) => OLD