Gene Heskett wrote:
...
With all due respect Craig, what the hell use is it then when ALL the
documentation is wrong?
...
/tmp itself is drwxr-xr-x amanda disk system_u:object_r:tmp_t:s0 tmp
Well, that's totally wrong. I'm curious about how permissions on /tmp
got broken. That's almost certainly what caused the problem. My guess
is that the first time mysql started, it began the initialization
process for the databases in /var/lib/mysql, but failed partially
through because of the problem with /tmp. After that, MySQL will not
continue trying to initialize, so you've got a bad database.
To correct the problem, you need to make sure that /tmp is in good
order. It should look like this:
# ls -ldZ /tmp
drwxrwxrwt root root system_u:object_r:tmp_t:s0 /tmp/
If it doesn't, then "chmod 1777 /tmp" and "chown root:root /tmp"
Next, delete the contents of /var/lib/mysql. That directory must also
exist and must have the correct permissions. It should look like this:
$ ls -ldZ /va/lib/mysql
drwxr-xr-x mysql mysql system_u:object_r:mysqld_db_t /var/lib/mysql
Once those two directories are fixed, you *should* be able to start
msyql, and use the cli "mysql" and "mysqladmin" tools without a
password. If not, check for new SELinux problems.
And with all due respect, the documentation isn't wrong just because it
doesn't cover recovery from the specific error condition on your host.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines