[CentOS] Prelink: Something's happening here

Johnny Hughes johnny at centos.org
Sun Dec 23 12:27:37 UTC 2007


Johnny Hughes wrote:
> Benjamin Smith wrote:
>> Can anybody explain to me what's going on here? This is a CentOS 4 i386 
>> system. 
>>
>> [root at edison ~]# rm -f /etc/prelink.cache 
>> [root at edison ~]# /etc/cron.daily/prelink
>> [root at edison ~]# rpm -qf /usr/bin/sqlite3
>> sqlite-3.3.6-2
>> [root at edison ~]# rpm --verify sqlite
>> prelink: /usr/bin/sqlite3: at least one of file's dependencies has changed 
>> since prelinking
>> S.?.....    /usr/bin/sqlite3
>> [root at edison ~]# rpm -q --dump sqlite | grep "bin/sqlite3"
>> /usr/bin/sqlite3 29044 1178360479 70e7158185e01e23dd2a62fa00f0f752 0100755 
>> root root 0 0 0 X
>> [root at edison ~]# md5sum /usr/bin/sqlite3
>> 6e4b1dc7b0b5ade26448ed700c33e05f  /usr/bin/sqlite3
>> [root at edison ~]# prelink -u /usr/bin/sqlite3
>> [root at edison ~]# md5sum /usr/bin/sqlite3
>> 70e7158185e01e23dd2a62fa00f0f752  /usr/bin/sqlite3
>> [root at edison ~]# rpm --verify sqlite
>> [root at edison ~]# prelink -f /usr/bin/sqlite3 
>> prelink: /usr/lib/libncurses.so.5.4: .debug_loc adjusting unfinished
>> [root at edison etc]# md5sum /usr/bin/sqlite3
>> 70e7158185e01e23dd2a62fa00f0f752  /usr/bin/sqlite3
>> [root at edison etc]#
>>
>> How did the RPM database have the right values for the sqlite3 file before 
>> prelink was run? Or, another way, why was the file different in the first 
>> place, that running prelink against it fixed it? And if "undoing" the prelink 
>> changed something, why wasn't it "changed back" when I ran prelink against 
>> the sqlite3 file the second time? 
>>
>> Finding this confusing as H__L. 
>>
>> I have *alot* of files on this system with this issue - I discovered this 
>> while debugging a problem with MailScanner. And, why do I see similar 
>> behavior on another system that's freshly built? EG: just ran the installer 
>> and "yum update" and see the same issue with a smaller number of files?
> 
> Ben,
> 
> I can verify that I see the same thing on centos-4.6 fully updated right
> now.
> 
> When running "rpm -Va" I have several (dozen :D) RPMS that show the:
> 
> "at least one of file's dependencies has changed since prelinking"
> 
> The good news (or bad news depending on your point of view) is that I
> also see the same thing on a fully updated RHEL-4.6 AS install.
> 
> I am currently doing a virgin RHEL-4.6 install from the ISOs to see if
> it happens with the base 4.6 or only after updates.
> 
> I will post when I know more.
> 
> Thanks,
> Johnny Hughes

We have been in touch with the upstream provider on this ... first some
issues:

The default prelink setup can take up to 2 weeks to rerun a full
prelink.  This is due to serveral settings in the file
/etc/sysconfig/prelink.

So, after an update, it may take up to 14 days for a file to get
prelinked after it's libraries are updated.  You can manually prelink
sooner if required.

It seems the only real thing affected by this is "rpm -V".

You can "fix" the issue by running this command:

/usr/sbin/prelink -av -mR

This should re-prelink everything, then you should have a lot less of the:

"at least one of file's dependencies has changed since prelinking"

I have to admit that I did (on a couple machines) still have some of
those left ... so what I did was uninstall and reinstall the RPMS and
prelink again ... then they were fine (not required, I did it as a
test).  This means that they should have been fine all along as I did
not change _ANY_OF_ their dependencies or shared libs that they use
except those inside the RPM itself.

I have seen this problem on several installs of CentOS and RHEL, so it
is not a CentOS specific issue ... however the upstream provider assures
us that other than "rpm -V" not being 100% accurate, there are no other
issues caused by this.  They said for anything but package verification
it should make zilch difference for functionality, just prelinking
cannot be used for some programs and normal re-locations will be applied
instead.

I did have several people run "rpm -Va" on RHEL servers, and they all
had the same errors.

Thanks,
Johnny Hughes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20071223/6c6ba7de/attachment.sig>


More information about the CentOS mailing list