| Summary: | mysqlcheck fails with fatal error in Cauldron breaking mariadb | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Barry Jackson <zen25000> |
| Component: | RPM Packages | Assignee: | Marc Krämer <mageia> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | ftg |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://jira.mariadb.org/browse/MDEV-27236 | ||
| Whiteboard: | |||
| Source RPM: | mariadb-10.6.4-2.mga9.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
Normal operation in Mga8
Failing in Mga9 Running mysql_upgrade from command line without zmsetup script |
||
|
Description
Barry Jackson
2021-11-12 01:59:59 CET
Created attachment 12983 [details]
Normal operation in Mga8
Created attachment 12984 [details]
Failing in Mga9
Assigning to registered maintainer. CC:
(none) =>
ftg 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 =>
RESOLVED |