-   Linux - Software (
-   -   MySQL 5.0.41 on RHEL5 failure to work (

kav 06-29-2007 02:08 PM

MySQL 5.0.41 on RHEL5 failure to work
Post removed

rylan76 07-05-2007 09:59 AM

Teeheehee... it's called RPM.

Personally I try to stay as far away from RPM (or any form of "package") as possible.

On a more serious note, MySQL 5x seems to have some serious issues. I spent a few hours yesterday trying to get a standard 5.0.26 going with Apache and PHP for our LAMP development setup here - no luck. It seems to work significantly differently from 4.0.26...

Do you have a reason to upgrade...? Is there a 5x feature you specifically need? I usually try not to upgrade such vital pieces of software if I do not have a very compelling reason that forces me to upgrade.

To directly address your problem, you might try downloading a binary package of MySQL 4.0.26 and seeing if you can manually install that. That's the saving grace of NOT using packages - you can put something exactly where you want it and IMO control it much more accurately. You can also do stuff RPM (or the RPM packager) won't allow, like installing something that might miss some optional components (which seems to be what your problem is being caused by...)

kav 07-11-2007 04:00 PM

unfortunetly zenoss specifically requires mysql5. And management decided we absolutely have to have zenoss.

You're definetly right about rpms. The more I use them the more trouble they cause. I don't even know why they give you the -e for uninstall option seeing as they leave sh*t everywhere. But of course the customer absolutely had to have a RedHat system.

I figured I'd go ahead with the redhat packages since the Debian mysql5.0.41 I've got running has been un-fricking-breakable so far. I should have just left it at version 5.0.2# or whateve it was at was fine.


I usually try not to upgrade such vital pieces of software if I do not have a very compelling reason that forces me to upgrade.
Words to live by. Why didn't I think of that?

After some research, the problem seemed to initially reside in /etc/my.cnf pointing to the wrong basedir. The 'fix' was to just comment out that line and let the other configuration file fill in that value. But all that did was make the startup script hang and eventually fail rather than fail immediatly.

I eventually uninstalled mysql, ripped out all of the guts left behind and then reinstalled. Now it's failing for all new reasons! :) ugh...

kav 07-12-2007 02:24 PM

The new version of MySQL released this morning (July 12 5.0.45) installed and works perfectly. I don't know what the problem was but it's fixed in the new version.

All times are GMT -5. The time now is 12:49 PM.