Description of problem: In the current build of F20 x64 running Gnome I'm currently unable to start mariadb. I receive the following error: [matthew@lilith ~]$ sudo service mariadb start Redirecting to /bin/systemctl start mariadb.service Job for mariadb.service failed. See 'systemctl status mariadb.service' and 'journalctl -xn' for details. Happened on fresh installations of Fedora 20 Beta-TC6 and TC2. Version-Release number of selected component (if applicable): mariadb-5.5.34 How reproducible: 100% Steps to Reproduce: 1. start mysqld/mariadb Actual results: mariadb fails to start Expected results: mariadb starts Additional info: See attachment for systemctl status and journalctl -xn dumps
Created attachment 829283 [details] Dumps of systemctl mariadb.service status and journalctl -xn
It seems like your server refuses to start. What is in your log file /var/log/mysqld.log (resp. /var/log/mariadb/mariadb.log)?
Created attachment 829311 [details] mariadb.log
Log added. I have gained access to the shell via: sudo mysqld -u root -p I'm able to start/configure mysql with sudo mysqld_safe sudo mysql_secure_installation The login information i provided to gain shell access with the first listed command was with the information provided to the configuration command. I then tried to access phpmyadmin with the newly created/tested credentials and it threw this error: #2002 - Permission denied The server is not responding (or the local server's socket is not correctly configured).
Scratch that last part about not gaining access to phpyadmin. I rebooted, and turned on mariadb with mysqld_safe and was able to login to phpmyadmin with the credentials i provided in mysql_secure_installation.
Same issue for me.
Same issue here. With previous version of mariadb-server it works fine.
Found the issue, new build is on the way: http://koji.fedoraproject.org/koji/buildinfo?buildID=481161
mariadb-5.5.34-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mariadb-5.5.34-2.fc20
Confirming that updating to mariadb-5.5.34-2.fc20 fixed the problem for me.
I can verify that it now works with the latest update.
Proposed as a Freeze Exception for 20-final by Fedora user tflink using the blocker tracking app because: All system services present after installation with one of the release-blocking package sets much start properly, unless they require hardware which is not present. This package is shipped on at least the KDE live media ... even though it's not started/used by default from the normal server unit
I may miss something, but mariadb-5.5.34-1 has never been in stable, since this bug was found while it was in updates-testing repository. Thus, I'd say Freeze Exception is not necessary, because previous version (still in stable) mariadb-5.5.33a-2.fc20 should be working just fine.
Yep, as per honza. The broken one never went stable. You may have got it on a netinstall, tflink. -1
*** Bug 1035951 has been marked as a duplicate of this bug. ***
Hmm, I was using updates-testing, and hit this as a consequence of updating to mariadb-5.5.34-1.fc20.x86_64 on my OpenStack setup. Only to find (after an hour) that downgrading it to mariadb-5.5.33a-2.fc20.x86_64 worked. Thanks for the fix.
kashyap: updates-testing is enabled by default for pre-releases so lots of people run into it; the discussion about FE status doesn't mean the bug isn't valid or serious, it's just specifically about whether we need to pull the build through freeze into the Final images or not.
Discussed at 2013-12-02 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-02/f20-blocker-review-%234.2013-12-02-17.02.log.txt . Rejected as a freeze exception issue: the broken build never made it to stable, so there is no need to break freeze here. The build currently in stable - and hence which will be on the F20 media - is not affected by this issue. No-one who installs F20 after today will see the bug on updates, either, as the broken update has already been superseded by the working one.
mariadb-5.5.34-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.