Description of problem: When updating a production server, mariadb don't restart due to the lack of "mysqld-prepare-db-dir" uses by the previous systemd unit Version-Release number of selected component (if applicable): MariaDB: 11.4.5 How reproducible: Each reboot or service restart This bug is also noticed here : https://bugs.mageia.org/show_bug.cgi?id=34176
Thank you for the heads up! Assigning to packager of the update.
Priority: Normal => HighAssignee: bugsquad => mageiaCC: (none) => fri
Let me add an other warning : "mariadb-prepare-db-dir" runs "/usr/bin/mariadb_install_db" at line 58. The right name should be "/usr/bin/mariadb-install-db"
Can confirm this issue. Noticed it after installing Mageia 9 on a VM. This issue does not affect previously installations. This fix is has mentioned in comment 2.
CC: (none) => mageia
Build is running - true must have overseen this change from "_" to "-"
I see it built.
Assignee: mageia => qa-bugs
Packages: i586: libmariadb-devel-11.4.5-3.mga9.i586.rpm libmariadb-embedded-devel-11.4.5-3.mga9.i586.rpm libmariadb3-11.4.5-3.mga9.i586.rpm libmariadbd19-11.4.5-3.mga9.i586.rpm mariadb-11.4.5-3.mga9.i586.rpm mariadb-bench-11.4.5-3.mga9.i586.rpm mariadb-client-11.4.5-3.mga9.i586.rpm mariadb-common-11.4.5-3.mga9.i586.rpm mariadb-common-core-11.4.5-3.mga9.i586.rpm mariadb-connect-11.4.5-3.mga9.i586.rpm mariadb-core-11.4.5-3.mga9.i586.rpm mariadb-extra-11.4.5-3.mga9.i586.rpm mariadb-feedback-11.4.5-3.mga9.i586.rpm mariadb-mroonga-11.4.5-3.mga9.i586.rpm mariadb-obsolete-11.4.5-3.mga9.i586.rpm mariadb-pam-11.4.5-3.mga9.i586.rpm mariadb-s3-engine-11.4.5-3.mga9.i586.rpm mariadb-sequence-11.4.5-3.mga9.i586.rpm mariadb-sphinx-11.4.5-3.mga9.i586.rpm mariadb-spider-11.4.5-3.mga9.i586.rpm mysql-MariaDB-11.4.5-3.mga9.i586.rpm x86_64: lib64mariadb-devel-11.4.5-3.mga9.x86_64.rpm lib64mariadb-embedded-devel-11.4.5-3.mga9.x86_64.rpm lib64mariadb3-11.4.5-3.mga9.x86_64.rpm lib64mariadbd19-11.4.5-3.mga9.x86_64.rpm mariadb-11.4.5-3.mga9.x86_64.rpm mariadb-bench-11.4.5-3.mga9.x86_64.rpm mariadb-client-11.4.5-3.mga9.x86_64.rpm mariadb-common-11.4.5-3.mga9.x86_64.rpm mariadb-common-core-11.4.5-3.mga9.x86_64.rpm mariadb-connect-11.4.5-3.mga9.x86_64.rpm mariadb-core-11.4.5-3.mga9.x86_64.rpm mariadb-extra-11.4.5-3.mga9.x86_64.rpm mariadb-feedback-11.4.5-3.mga9.x86_64.rpm mariadb-mroonga-11.4.5-3.mga9.x86_64.rpm mariadb-obsolete-11.4.5-3.mga9.x86_64.rpm mariadb-pam-11.4.5-3.mga9.x86_64.rpm mariadb-rocks-11.4.5-3.mga9.x86_64.rpm mariadb-s3-engine-11.4.5-3.mga9.x86_64.rpm mariadb-sequence-11.4.5-3.mga9.x86_64.rpm mariadb-sphinx-11.4.5-3.mga9.x86_64.rpm mariadb-spider-11.4.5-3.mga9.x86_64.rpm mysql-MariaDB-11.4.5-3.mga9.x86_64.rpm SRPM: mariadb-11.4.5-3.mga9.src.rpm
Advisory: Due to an script error introduced in the previous update mariadb server refused to restart. This update fixes this regression.
MGA9-64 Plasma Wayland on Compaq H000SB No installation issues. Strange: I have mariadb always running on my "production" desktop in the previous version. It runs to support another application, and I never noticed it would not run after a reboot. You understand something else by "restart"?? Anyway, tested the new version # systemctl start mysqld # systemctl -l status mysqld ● mysqld.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; preset: disabled) Active: active (running) since Wed 2025-04-30 16:35:18 CEST; 28s ago Process: 21869 ExecStartPre=/usr/sbin/mariadb-prepare-db-dir (code=exited, status=0/SUCCESS) Main PID: 21884 (mysqld) Status: "Taking your SQL requests now..." Tasks: 22 (limit: 8806) Memory: 155.7M CPU: 17.629s CGroup: /system.slice/mysqld.service └─21884 /usr/sbin/mysqld Apr 30 16:34:45 mach3.hviaene.thuis mysqld[21884]: 2025-04-30 16:34:45 0 [Note] InnoDB: log sequence number 55542; transaction id 25 Apr 30 16:34:45 mach3.hviaene.thuis mysqld[21884]: 2025-04-30 16:34:45 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool Apr 30 16:34:46 mach3.hviaene.thuis mysqld[21884]: 2025-04-30 16:34:46 0 [Note] InnoDB: Buffer pool(s) load completed at 250430 16:34:46 Apr 30 16:34:46 mach3.hviaene.thuis mysqld[21884]: 2025-04-30 16:34:46 0 [Note] CONNECT: Version 1.07.0002 March 22, 2021 Apr 30 16:34:46 mach3.hviaene.thuis mysqld[21884]: 250430 16:34:46 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED. Apr 30 16:34:46 mach3.hviaene.thuis mysqld[21884]: 250430 16:34:46 server_audit: Query cache is enabled with the TABLE events. Some table reads can be veile> Apr 30 16:35:18 mach3.hviaene.thuis mysqld[21884]: 2025-04-30 16:35:18 0 [Note] mysqld: Event Scheduler: Loaded 0 events Apr 30 16:35:18 mach3.hviaene.thuis mysqld[21884]: 2025-04-30 16:35:18 0 [Note] /usr/sbin/mysqld: ready for connections. Apr 30 16:35:18 mach3.hviaene.thuis mysqld[21884]: Version: '11.4.5-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 0 Mageia MariaDB Server Apr 30 16:35:18 mach3.hviaene.thuis systemd[1]: Started mysqld.service. Made sure httpd is running, then used phpMyAdmin to delete a previous testdatabase and create a new one. Create new table with serial field as PK, two varchars (one with unique index) and timestamp. Populate the table with a few rows. All works OK. Good enough for me, but let others test it as well.
CC: (none) => herman.viaene
Keywords: (none) => advisory
(In reply to Marc Krämer from comment #7) > Advisory: > > Due to an script error introduced in the previous update mariadb server > refused to restart. This update fixes this regression. This is not correct. The issue happened on first start, when setting up the database directory. If the database directory was already setup, the mariadb server started without any issue. That is probably why no QA tester (me included) noticed the issue at the time. I only noticed the issue when setting up a new Mageia 9 VM with mariadb.
Installed and tested on a clean VM without issues. The path in /usr/sbin/mariadb-prepare-db-dir is fixed. $ uname -a Linux jupiter-vm-mageia-9 6.6.88-desktop-3.mga9 #1 SMP PREEMPT_DYNAMIC Sat Apr 26 22:17:20 UTC 2025 x86_64 GNU/Linux $ rpm -qa | grep mariadb | sort lib64mariadb3-11.4.5-3.mga9 mariadb-11.4.5-3.mga9 mariadb-client-11.4.5-3.mga9 mariadb-common-11.4.5-3.mga9 mariadb-common-core-11.4.5-3.mga9 mariadb-core-11.4.5-3.mga9 mariadb-extra-11.4.5-3.mga9 $ ls -la /usr/bin/mariadb-install-db -rwxr-xr-x 1 root root 22079 abr 29 13:50 /usr/bin/mariadb-install-db* $ systemctl status mysqld.service ● mysqld.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; preset: disabled) Active: active (running) since Thu 2025-05-01 10:03:27 WEST; 1min 55s ago Process: 16283 ExecStartPre=/usr/sbin/mariadb-prepare-db-dir (code=exited, status=0/SUCCESS) Main PID: 16354 (mysqld) Status: "Taking your SQL requests now..." Tasks: 9 (limit: 9488) Memory: 232.2M CPU: 1.412s CGroup: /system.slice/mysqld.service └─16354 /usr/sbin/mysqld mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 2025-05-01 10:03:27 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 2025-05-01 10:03:27 0 [Note] InnoDB: log sequence number 47763; transaction id 14 mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 2025-05-01 10:03:27 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 2025-05-01 10:03:27 0 [Note] InnoDB: Buffer pool(s) load completed at 250501 10:03:27 mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 250501 10:03:27 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED. mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 250501 10:03:27 server_audit: Query cache is enabled with the TABLE events. Some table reads can be veiled.2025-05-01 10:03:27 0 [Note] Plugin 'wsrep-provider' is disabled. mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 2025-05-01 10:03:27 0 [Note] mysqld: Event Scheduler: Loaded 0 events mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: 2025-05-01 10:03:27 0 [Note] /usr/sbin/mysqld: ready for connections. mai 01 10:03:27 jupiter-vm-mageia-9 mysqld[16354]: Version: '11.4.5-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 0 Mageia MariaDB Server mai 01 10:03:27 jupiter-vm-mageia-9 systemd[1]: Started mysqld.service.
(In reply to PC LX from comment #9) > (In reply to Marc Krämer from comment #7) > > Advisory: > > > > Due to an script error introduced in the previous update mariadb server > > refused to restart. This update fixes this regression. > > This is not correct. The issue happened on first start, when setting up the > database directory. If the database directory was already setup, the mariadb > server started without any issue. That is probably why no QA tester (me > included) noticed the issue at the time. I only noticed the issue when > setting up a new Mageia 9 VM with mariadb. Ok, you're right. Advisory: Due to an script error introduced in the previous update mariadb server was not able to start on a clean install. Updated installations were not affected. However, this update makes mariadb work on clean and updated installations.
Advisory updated
CC: (none) => andrewsfarmWhiteboard: (none) => MGA9-64-OK
Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2025-0044.html
Status: NEW => RESOLVEDResolution: (none) => FIXED