[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