Ran yum update this A.M. Got this. Is it a problem for rpmforge, CentOS or just me? Maybe not a problem at all?
/etc/ld.so.conf.d files are "box stock", so there were no clues there.
TIA for any insight.
=================================================== Running Transaction Updating : cups-libs [ 1/10] /sbin/ldconfig: /usr/lib/liblzo.so.1 is not a symbolic link
Updating : libpurple [ 2/10] /sbin/ldconfig: /usr/lib/liblzo.so.1 is not a symbolic link <snip>
Cleanup : libpurple [ 7/10] /sbin/ldconfig: /usr/lib/liblzo.so.1 is not a symbolic link
Cleanup : cups-libs [ 8/10] /sbin/ldconfig: /usr/lib/liblzo.so.1 is not a symbolic link
Cleanup : enscript [ 9/10] Cleanup : pidgin [10/10] ===================================================
$ rpm -q --whatprovides /usr/lib/liblzo.so.1 lzo-1.08-5.el5.rf
$ls -ld /usr/lib/liblzo.so.1 -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1
$ rpm -q libpurple enscript pidgin libpurple-2.5.2-6.el5 enscript-1.6.4-4.1.1.el5_2 pidgin-2.5.2-6.el5 =================================================== Updated: cups.i386 1:1.2.4-11.18.el5_2.3 cups-libs.i386 \ 1:1.2.4-11.18.el5_2.3 enscript.i386 0:1.6.4-4.1.1.el5_2 \ libpurple.i386 0:2.5.2-6.el5 pidgin.i386 0:2.5.2-6.el5 Complete! ===================================================
Hi,
On Tue, Dec 16, 2008 at 07:05, William L. Maltby CentOS4Bill@triad.rr.com wrote:
/sbin/ldconfig: /usr/lib/liblzo.so.1 is not a symbolic link
This message is not generated by "yum", but by "ldconfig" (as the message itself is actually saying). When "yum" installs a new library, the RPM contains instructions to run "ldconfig" after installing it, so that the loader cache is updated and when you run a program that needs that library it will be found.
One of the steps "ldconfig" does is creating symbolic links for libraries, using the name that is hardcoded inside the library.
$ rpm -q --whatprovides /usr/lib/liblzo.so.1 lzo-1.08-5.el5.rf
The lzo package actually contains a file such as /usr/lib/liblzo.so.1.0.0 (or similar version number), that file has "liblzo.so.1" hard-coded as the name to look for inside it (it's the SONAME), and the RPM also contains the symbolic link, /usr/lib/liblzo.so.1 -> liblzo.so.1.0.0 (this is the symbolic link created/updated by ldconfig).
However, in your system, you have a file and not a symbolic link:
$ls -ld /usr/lib/liblzo.so.1 -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1
Something overwrote that symbolic link and created a file in that place. Maybe by copying the original /usr/lib/liblzo.so.1.0.0 to liblzo.so.1, or maybe by doing something else. I've seen this happen with installation scripts for commercial products, maybe you installed something that used "lzo" and included a version of it that was packaged differently than the version you got from RPMforge.
The date of the file might be a clue on when that happened, in that case, at 2:39am last Novemeber 4th. You can try to look for logs on your system to see what might have done that.
In any case, the simple fix is to just remove that file (back it up first, just in case), and run ldconfig again, you will see that the symbolic link will be properly created.
You may also try to erase and reinstall the lzo RPM, I believe this would also fix the problem.
HTH, Filipe
On Tue, 2008-12-16 at 12:43 -0500, Filipe Brandenburger wrote:
Hi,
On Tue, Dec 16, 2008 at 07:05, William L. Maltby CentOS4Bill@triad.rr.com wrote:
/sbin/ldconfig: /usr/lib/liblzo.so.1 is not a symbolic link
This message is not generated by "yum", but by "ldconfig" (as the message itself is actually saying). When "yum" installs a new library, the RPM contains instructions to run "ldconfig" after installing it, so that the loader cache is updated and when you run a program that needs that library it will be found.
Yeah, I was on-board with that process. What I didn't know, was if the unexpected message was due to a local issue (as you've mentioned below) or something in the pre/post (or other?) sections of the scripts. Since I know nothing of the scripts (python?) I thought I'd better seek some help.
One of the steps "ldconfig" does is creating symbolic links for libraries, using the name that is hard-coded inside the library.
AH! Ergo, when it tries and there is a real file, is sensibly doesn't replace it. And it's nice enough to let the user know.
$ rpm -q --whatprovides /usr/lib/liblzo.so.1 lzo-1.08-5.el5.rf
The lzo package actually contains a file such as /usr/lib/liblzo.so.1.0.0 (or similar version number), that file has "liblzo.so.1" hard-coded as the name to look for inside it (it's the SONAME), and the RPM also contains the symbolic link, /usr/lib/liblzo.so.1 -> liblzo.so.1.0.0 (this is the symbolic link created/updated by ldconfig).
However, in your system, you have a file and not a symbolic link:
$ls -ld /usr/lib/liblzo.so.1 -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1
Something overwrote that symbolic link and created a file in that place. Maybe by copying the original /usr/lib/liblzo.so.1.0.0 to liblzo.so.1, or maybe by doing something else. I've seen this happen with installation scripts for commercial products, maybe you installed something that used "lzo" and included a version of it that was packaged differently than the version you got from RPMforge.
Hmm. Wouldn't an rpm -q --whatprovides tell all occurrences? Of course, if the miscreant package was since removed it couldn't. Maybe rpm expects only one source per resource?
The date of the file might be a clue on when that happened, in that case, at 2:39am last Novemeber 4th. You can try to look for logs on your system to see what might have done that.
I'll check that out.
In any case, the simple fix is to just remove that file (back it up first, just in case), and run ldconfig again, you will see that the symbolic link will be properly created.
Looks like that's on the $$
# ls -l `locate liblzo.so` -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1 -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1.0.0
You may also try to erase and reinstall the lzo RPM, I believe this would also fix the problem.
It looks like the remove/ldconfig would be just as good here.
I'm going to check my logs and see if I can see what scrogged the setup. If I see anything likely, I'll post so others can see it.
HTH, Filipe
<snip sig stuff>
Thanks for taking the time Filipe!
Hi,
On Tue, Dec 16, 2008 at 14:20, William L. Maltby CentOS4Bill@triad.rr.com wrote:
Since I know nothing of the scripts (python?)
Usually they're Bourne shell script.
You can see the scripts used by cups-libs with this command: rpm -q --scripts cups-libs
I thought I'd better seek some help.
Always a good call! :-)
One of the steps "ldconfig" does is creating symbolic links for libraries, using the name that is hard-coded inside the library.
AH! Ergo, when it tries and there is a real file, is sensibly doesn't replace it. And it's nice enough to let the user know.
That's it.
Hmm. Wouldn't an rpm -q --whatprovides tell all occurrences? Of course, if the miscreant package was since removed it couldn't. Maybe rpm expects only one source per resource?
Probably the miscreant package was not an RPM, since otherwise you would have a conflict and it wouldn't install "cleanly".
RPM can be used to show that something unexpected was changed with your original RPM if you use this command: rpm --verify lzo
# ls -l `locate liblzo.so` -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1 -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1.0.0
I would advise also doing "md5sum /usr/lib/liblzo.so.1*" to make really sure they're the same.
As both files have the same date, I might be wrong in my suspicion that that was the date the file replaced the symbolic link.
It looks like the remove/ldconfig would be just as good here.
Yes!
I'm going to check my logs and see if I can see what scrogged the setup. If I see anything likely, I'll post so others can see it.
Good, thanks! Filipe
On Tue, 2008-12-16 at 15:46 -0500, Filipe Brandenburger wrote:
Hi,
On Tue, Dec 16, 2008 at 14:20, William L. Maltby CentOS4Bill@triad.rr.com wrote:
Since I know nothing of the scripts (python?)
Usually they're Bourne shell script.
You can see the scripts used by cups-libs with this command: rpm -q --scripts cups-libs
Took a peek at the scripts for lzo too. Only ldconfig is shown. Ditto for cups-libs, libpurple. Enscript runs a script that executes a binary, /sbin/install-info, so I can't tell what it does, but it _seems_ innocuous enough, based on the name of the binary.
I thought I'd better seek some help.
Always a good call! :-)
One of the steps "ldconfig" does is creating symbolic links for libraries, using the name that is hard-coded inside the library.
I'm going to test that lzo install since it won't directly affect anything else.
AH! Ergo, when it tries and there is a real file, is sensibly doesn't replace it. And it's nice enough to let the user know.
That's it.
Hmm. Wouldn't an rpm -q --whatprovides tell all occurrences? Of course, if the miscreant package was since removed it couldn't. Maybe rpm expects only one source per resource?
Probably the miscreant package was not an RPM, since otherwise you would have a conflict and it wouldn't install "cleanly".
I avoid non-rpm installs because I believe in the "purity" principle. The only exception I recall was a user-local install of FF 3 beta. That was done a a non-privileged user, so no risk there. Later, I installed the real thing and it's all good.
But something happened somewhere, as you'll probably be able to tell when (if?) you see my request about prelink woes (I'll post a 2nd plea later).
My strong feeling is it is related.
RPM can be used to show that something unexpected was changed with your original RPM if you use this command: rpm --verify lzo
Bingo!? This was one of the ones that showed up in my thread about prelinking woes. I had run a global --verify a got a handful of messages similar to those below. Unfortunately, IIRC, trying to remove some of the stuff, so I could re-install, had too many undesirable side-effects (like removing some apps that I _really_ need to avoid messing with ATM).
$ rpm --verify lzo SM5..... /usr/lib/liblzo.so.1 prelink: /usr/lib/liblzo.so.1.0.0: at least one of file's dependencies has changed since prelinking S.?..... /usr/lib/liblzo.so.1.0.0
That "stoopid" prelink message reminded me, I have a post about that no one responded too. I'll post a second request on that later.
# ls -l `locate liblzo.so` -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1 -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1.0.0
I would advise also doing "md5sum /usr/lib/liblzo.so.1*" to make really sure they're the same.
As noted, the rpm --verify caught the md5 sum issue. But IIRC, my 4.x used to get that frequently when --verify was run and there were prelinked files involved.
Side note: /var/log/prelink/prelink.log of 12/15 shows liblzo.so.1 was prelinked OK. It didn't "see" liblzo.so.1.0.0 though.
As both files have the same date, I might be wrong in my suspicion that that was the date the file replaced the symbolic link.
It looks like lzo installed both files. It was installed 11/5, the only 11/4 install was net-snmp-libs. An rpm --filesbypkg on it shows no lzo reference of any kind.
Rpm --last has an lzo that shows
lzo-1.08-5.el5.rf Wed 05 Nov 2008 06:51:28 PM EST
and filesbypkg shows
$ rpm -q --filesbypkg lzo lzo /usr/lib/liblzo.so.1 lzo /usr/lib/liblzo.so.1.0.0
As noted above, the script only runs ldconfig in post(un)install. With an 11/4 date and 11/5 install my bet is the 11/4 date was that contained in the rpm. IIRC, most installs try to maintain creation date, useful in detecting if a file has been changed, as if common with configuration files. If rpmforge made the thing on 11/4 this would be my expectation.
It looks like the remove/ldconfig would be just as good here.
Yes!
With the above additional information, I'm now of the opinion that an --erase and --install would be safer. That'll clean up at least that one of my "prelink woes" issues.
I'm going to check my logs and see if I can see what scrogged the setup. If I see anything likely, I'll post so others can see it.
None of the "Usual Suspects" appeared. Combined with my "prelink woes" issues, I now think something undetected out-of-the normal happened. I'm going to sneak a peek at "messages", sneaking, sneaking, peeking, peeking, ... RATS! Oldest "messages" doesn't go back that far.
I think I'm at the point of a backup, remove, re-install of some stuff, based on this, your help and my "prelink woes" issues.
You know, given time, occasional issues and community help I'm learning a little about some of this new-fangled stuff.
Good, thanks! Filipe
<snip sig stuff>
Thanks for all the feedback Filipe!
On Tue, 2008-12-16 at 17:51 -0500, William L. Maltby wrote:
On Tue, 2008-12-16 at 15:46 -0500, Filipe Brandenburger wrote:
Hi,
<snip>
One of the steps "ldconfig" does is creating symbolic links for libraries, using the name that is hard-coded inside the library.
I'm going to test that lzo install since it won't directly affect anything else.
Did a yum erase of lzo (which also takes out mplayer* - not a critical application for me). Yummed in lzo and got exactly what you predicted.
# ls -l `locate liblzo` lrwxrwxrwx 1 root root \ 15 Dec 16 18:11 /usr/lib/liblzo.so.1 -> liblzo.so.1.0.0 -rwxr-xr-x 1 root root 404506 Nov 4 02:39 /usr/lib/liblzo.so.1.0.0
Yummed in mplayer and checked again. All OK. An rpm verify on lzo and mplayer was good too. Note the 11/4 date on liblzo. That leads me to conclude that neither another package nor my manual machinations were the cause (ignoring, conveniently, other possible ill-advised activities I may have undertaken and subsequently forgotten!? 8-O ) of this problem.
<snip>
I think now the thing I should do is try a general rpm --verify and see what happens.
On Tue, Dec 16, 2008 at 7:05 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
Ran yum update this A.M. Got this. Is it a problem for rpmforge, CentOS or just me? Maybe not a problem at all?
Bill: I have PUP running and this morning got the alert that updates were available. I had PUP (which I believe is a front end forYUM/RPM) install the 3 packages, without any issues, on this CentOS 5.2 (32 bit) box. I wonder why it went awry for you, when you did it manually.... Lanny
On Tue, 2008-12-16 at 15:42 -0500, Lanny Marcus wrote:
On Tue, Dec 16, 2008 at 7:05 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
Ran yum update this A.M. Got this. Is it a problem for rpmforge, CentOS or just me? Maybe not a problem at all?
Bill: I have PUP running and this morning got the alert that updates were available. I had PUP (which I believe is a front end forYUM/RPM) install the 3 packages, without any issues, on this CentOS 5.2 (32 bit) box. I wonder why it went awry for you, when you did it manually.... Lanny
Current assessment by me is that I've suffered some heretofore undetected generalized corruption since other issues detailed here
http://lists.centos.org/pipermail/centos/2008-December/068949.html
were detected last week.
<snip sig stuff>
-
Filipe Brandenburger -
Lanny Marcus -
William L. Maltby