PDA

View Full Version : Failed dependency installing 7.0 rpm



Pale Blue Ego
2008-03-04, 10:29
error: Failed dependencies:
/usr/bin/mysqld_safe is needed by squeezecenter-7.0-1.noarch

Using Clark Connect 4.1 which normally has a very limited repository.

Mark Miksis
2008-03-04, 10:58
This means you need to install mysqld which I think is in a package called mysql-server on CC. I also think you can install the mysql server from the CC web GUI.

Pale Blue Ego
2008-03-04, 11:06
thanks, looks like that solved it. I had though SC7 included the needed mysql files.

Mark Miksis
2008-03-04, 11:27
I had though SC7 included the needed mysql files.

The RPM and deb packages use the mysqld from your Linux distro.

mbonsack
2008-03-04, 15:17
I got the same thing as above, installed MySQL-server, and then got:

[08-03-04 14:07:35.3521] Slim::Utils::MySQLHelper::createSystemTables (433) FATA
L: Couldn't connect to database: [Can't connect to local MySQL server through so
cket '/var/lib/squeezecenter/cache/squeezecenter-mysql.sock' (2)]

I'm on Mandrake 10.1 and was running 6.5 just fine. Installed over the top. Install seemed to go fine as far as RPM/dependencies were concerned after picking up MySQL.

Mark Miksis
2008-03-05, 08:13
I got the same thing as above, installed MySQL-server, and then got:

[08-03-04 14:07:35.3521] Slim::Utils::MySQLHelper::createSystemTables (433) FATA
L: Couldn't connect to database: [Can't connect to local MySQL server through so
cket '/var/lib/squeezecenter/cache/squeezecenter-mysql.sock' (2)]

I'm on Mandrake 10.1 and was running 6.5 just fine. Installed over the top. Install seemed to go fine as far as RPM/dependencies were concerned after picking up MySQL.

I never fully tested the SC RPM on Mandrake, but if it works with 6.5, I can't think of anything 7.0 would break. The error message above suggests that mysqld didn't start. Is there any info in /var/lib/squeezecenter/cache/mysql-error-log.txt? What's the output of "ps -ef | grep squeeze"? Maybe the 6.5 mysqld wasn't killed. What's the output of "ps -ef | grep slim"?

mbonsack
2008-03-05, 08:28
I never fully tested the SC RPM on Mandrake, but if it works with 6.5, I can't think of anything 7.0 would break. The error message above suggests that mysqld didn't start. Is there any info in /var/lib/squeezecenter/cache/mysql-error-log.txt? What's the output of "ps -ef | grep squeeze"? Maybe the 6.5 mysqld wasn't killed. What's the output of "ps -ef | grep slim"?

There is no mysql-error-log.txt at all in the cache directory, and the output of the greps show nothing is running. I do know this from looking at rapid ps outputs when I try to start squeeze -- it stays running for about 20 sec and then gives up on the socket. At no time does mysqld start -- what script is responsible for starting it, and how can I debug that?

If I start mysql by hand (/etc/init.d/mysql start) I get the following from ps:

/bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/mand
mysql 9447 9424 0 07:26 pts/1 00:00:00 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/l

which looks good. I just can't make Squeeze start mysqld with the correct my.cnf file being read.


As an alternative, should I just shine Mandrake 10.1 (which has been running my slim software for years) and just go to ubuntu server or something (which I tried in a VM and seems to work)

Thanks for your help!

Mark Miksis
2008-03-05, 08:59
As an alternative, should I just shine Mandrake 10.1 (which has been running my slim software for years) and just go to ubuntu server or something (which I tried in a VM and seems to work)

That's up to you, but I'd like to solve the Mandrake problem. Let's enable some debugging. Edit /etc/sysconfig/squeezecenter and add "--d_startup --debug os.paths,database.mysql" to the end of the SQUEEZECENTER_ARGS line (inside the quotes). This should add some logging on the console as well as to the server.log file. Look for where it finds and launches the mysqld binary.

Mark Miksis
2008-03-05, 09:07
That's up to you, but I'd like to solve the Mandrake problem. Let's enable some debugging. Edit /etc/sysconfig/squeezecenter and add "--d_startup --debug os.paths,database.mysql" to the end of the SQUEEZECENTER_ARGS line (inside the quotes). This should add some logging on the console as well as to the server.log file. Look for where it finds and launches the mysqld binary.

Also please post the output of "rpm -qa | grep MySQL".

mbonsack
2008-03-05, 09:26
That's up to you, but I'd like to solve the Mandrake problem. Let's enable some debugging. Edit /etc/sysconfig/squeezecenter and add "--d_startup --debug os.paths,database.mysql" to the end of the SQUEEZECENTER_ARGS line (inside the quotes). This should add some logging on the console as well as to the server.log file. Look for where it finds and launches the mysqld binary.

Relevant output from the last few lines of server.log:

[08-03-05 08:10:20.3593] Slim::Utils::MySQLHelper::startServer (247) About to start MySQL as a process with command: [/usr/sbin/mysqld --defaults-file=/var/lib/squeezecenter/cache/my.cnf]
[08-03-05 08:10:50.4601] Slim::Utils::MySQLHelper::createSystemTables (433) FATAL: Couldn't connect to database: [Can't connect to local MySQL server through socket '/var/lib/squeezecenter/cache/squeezecenter-mysql.sock' (2)]
[root@mandrake squeezecenter]#

I then tried the command shown by hand (which I did last night as well), and got:

[root@mandrake squeezecenter]# sudo -u squeezecenter /usr/sbin/mysqld --defaults-file=/var/lib/squeezecenter/cache/my.cnf
/usr/sbin/mysqld: ambiguous option '--innodb' (innodb_data_file_path, innodb_force_recovery)
[root@mandrake squeezecenter]#

Therein lies the culprit. One other thing I forgot to mention -- Mandrake 10.1 offered me two choices for MySQL -- one with (MySQL-max) and without (MySQL) "innodb" support. Tried both; got the same error on startup with both. In the case above, I'm just running the stock (non "-max") MySQL.

And another: Why does Squeezecenter require "mysqld_safe" as a dependency, and then not use it?

Oops, almost forgot:

[root@mandrake squeezecenter]# rpm -qa | grep MySQL
MySQL-4.0.20-3mdk
MySQL-client-4.0.20-3mdk
MySQL-common-4.0.20-3mdk
[root@mandrake squeezecenter]#

Mark Miksis
2008-03-05, 09:36
Therein lies the culprit. One other thing I forgot to mention -- Mandrake 10.1 offered me two choices for MySQL -- one with (MySQL-max) and without (MySQL) "innodb" support. Tried both; got the same error on startup with both. In the case above, I'm just running the stock (non "-max") MySQL.

That's definitely the problem (or at least part of it). SC needs innodb support. Can you switch back to MySQL-Max and try again?


And another: Why does Squeezecenter require "mysqld_safe" as a dependency, and then not use it?

It's a kludge to try to make one RPM work well with both Fedora and SUSE. I'd love to find a better way.

mbonsack
2008-03-05, 10:00
That's definitely the problem (or at least part of it). SC needs innodb support. Can you switch back to MySQL-Max and try again?

[08-03-05 08:55:37.5430] Slim::Utils::Misc::findbin (128) Didn't find binary for mysqld
[08-03-05 08:55:37.5435] Slim::Utils::MySQLHelper::startServer (231) FATAL: Couldn't find a executable for 'mysqld'! Exiting.
[08-03-05 08:55:37.5445] Log::Log4perl::Logger::and_die (850) Warning: FATAL: Couldn't find a executable for 'mysqld'! Exiting. at /usr/lib/perl5/vendor_perl/Slim/Utils/MySQLHelper.pm line 231
[root@mandrake squeezecenter]#

I then tried a symbolic link from /usr/sbin/mysqld-max to /usr/sbin/mysqld and got:

[08-03-05 09:02:46.1801] Slim::Utils::MySQLHelper::startServer (247) About to st
art MySQL as a process with command: [/usr/sbin/mysqld --defaults-file=/var/lib/
squeezecenter/cache/my.cnf]
[08-03-05 09:03:16.2826] Slim::Utils::MySQLHelper::createSystemTables (433) FATA
L: Couldn't connect to database: [Can't connect to local MySQL server through so
cket '/var/lib/squeezecenter/cache/squeezecenter-mysql.sock' (2)]

Bit this time it took about 20 sec to die.

Again, running the command shown:

[root@mandrake squeezecenter]# sudo -u squeezecenter /usr/sbin/mysqld --defaults-file=/var/lib/squeezecenter/cache/my.cnf
/usr/sbin/mysqld: ambiguous option '--innodb' (innodb_data_file_path, innodb_force_recovery)
[root@mandrake squeezecenter]#

And without the symbolic link, to make sure the "max" version is being run:

[root@mandrake squeezecenter]# sudo -u squeezecenter /usr/sbin/mysqld-max --defaults-file=/var/lib/squeezecenter/cache/my.cnf
/usr/sbin/mysqld-max: ambiguous option '--innodb' (innodb_data_file_path, innodb_force_recovery)
[root@mandrake squeezecenter]#

Mark Miksis
2008-03-05, 10:01
I just noticed this is mysql 4.0. SC needs at least 4.1. Unless there's a supported way to upgrade to 4.1, I suggest you either upgrade to a recent Mandriva or switch to another distro as you mentioned.

mbonsack
2008-03-05, 10:15
I just noticed this is mysql 4.0. SC needs at least 4.1. Unless there's a supported way to upgrade to 4.1, I suggest you either upgrade to a recent Mandriva or switch to another distro as you mentioned.

OK, I'll see if I can pick up 4.1 on one a different repository, or upgrade to ubuntu server as mentioned. Thanks for your help!

Mark Miksis
2008-03-05, 10:25
Thanks for your help!

No problem. I'm going to see if I can some up with a better way to set up the mysql dependency that avoids the mysql-max issue as well as a related problem on altlinux. Can you refer me to a web page that specifies which versions of mandrake/mandriva are still supported with bug/security fixes? I don't want to waste time trying to support Linux distros that are already EOL, but I can't find any info on when/how Mandrake does this.

mbonsack
2008-03-05, 10:40
No problem. I'm going to see if I can some up with a better way to set up the mysql dependency that avoids the mysql-max issue as well as a related problem on altlinux. Can you refer me to a web page that specifies which versions of mandrake/mandriva are still supported with bug/security fixes? I don't want to waste time trying to support Linux distros that are already EOL, but I can't find any info on when/how Mandrake does this.

I didn't hit any Mandrake web pages either; I just simply used the URPMI repositories that I have set up for years with this distro. The highest MySQL offered was 4.0.2. I gotta believe this distro, now 3 years old, is no longer supported but I don' have any proof of this.

As an aside, I think this is one of the biggest reasons Linux has a hard time on the desktop (which the server versions have largely fixed). Too many distros, too many dependencies, making life *way* too hard for folks like you just trying to support your own product. Makes you want to just say, "we support RHEL 3.x and above" and call it a day...

Ben Sandee
2008-03-05, 10:53
On Wed, Mar 5, 2008 at 11:40 AM, mbonsack <
mbonsack.35t90z1204739101 (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> fixed). Too many distros, too many dependencies, making life *way* too
> hard for folks like you just trying to support your own product. Makes
> you want to just say, "we support RHEL 3.x and above" and call it a
> day...


More like "we support Ubuntu" and call it a day, at least lately. There is
real innovation going on and no one distribution is right for everyone, but
for right now, today, Ubuntu truly is the one with the momentum and user
base. Next year it could be something else.

Ben

Mark Miksis
2008-03-05, 11:13
As an aside, I think this is one of the biggest reasons Linux has a hard time on the desktop (which the server versions have largely fixed). Too many distros, too many dependencies, making life *way* too hard for folks like you just trying to support your own product. Makes you want to just say, "we support RHEL 3.x and above" and call it a day...

IMO, it's no better/worse for desktop vs. servers. The real problem is that the major RPM-based distros (RH and SUSE) don't cooperate. They have different packaging policies, use different names, different init scripts, different FHS interpretations, different installers (yum/yast), etc. Mandrake, CC, altlinux and others just add to the complexity. The debian world doesn't have this problem. Major derivatives (specifically Ubuntu) just use the debian packages and everything just works.

It's not easy to make a generic RPM. The SC RPM tries to do what's best for RHEL/Fedora/SUSE. The only way to make this all work cleanly for others is to build different RPMs for each distro.

mbonsack
2008-03-05, 11:25
IMO, it's no better/worse for desktop vs. servers. The real problem is that the major RPM-based distros (RH and SUSE) don't cooperate. They have different packaging policies, use different names, different init scripts, different FHS interpretations, different installers (yum/yast), etc. Mandrake, CC, altlinux and others just add to the complexity. The debian world doesn't have this problem. Major derivatives (specifically Ubuntu) just use the debian packages and everything just works.

It's not easy to make a generic RPM. The SC RPM tries to do what's best for RHEL/Fedora/SUSE. The only way to make this all work cleanly for others is to build different RPMs for each distro.

That's why I picked RHEL as an example. It can be supported via a support contract through large companies (there *are* advantages there), many server/enterprise software vendors use it as a base for their products, and changes are not made based on the latest technology of the day, but instead by whether or not the changes are supportable in the enterprise. In my opinion, vendors (such as Slim) should only pick distros that have a long-term support life, like RHEL or Ubuntu long-term releases. You may be missing some of the latest and greatest technology, but you won't bang your head on the wall developing RPMs for altlinux, old Mandrake (like mine :-), etc.

Ben Sandee
2008-03-05, 11:48
On Wed, Mar 5, 2008 at 12:25 PM, mbonsack <
mbonsack.35tb3z1204741801 (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> That's why I picked RHEL as an example. It can be supported via a
> support contract through large companies (there *are* advantages
> there), many server/enterprise software vendors use it as a base for
> their products, and changes are not made based on the latest technology
> of the day, but instead by whether or not the changes are supportable in
> the enterprise. In my opinion, vendors (such as Slim) should only pick
> distros that have a long-term support life, like RHEL or Ubuntu
> long-term releases. You may be missing some of the latest and greatest


I appreciate where you're coming from but I think that it make more sense
that they support the distros that their customers are actually using. I
recognize the value of the LTS releases and Redhat for business use, but I'm
doing a lot of things on my home media Linux servers and desktops that
weren't possible in 2006 when these releases were made. Things are moving
very quickly, particularly in the areas of media server technologies.

Ben