[CentOS] Yum messages: /usr/lib/liblzo.so.1 is not a symbolic link
William L. Maltby
CentOS4Bill at triad.rr.com
Tue Dec 16 22:51:07 UTC 2008
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 at 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!
--
Bill
More information about the CentOS
mailing list