Prelink: Something's happening here
 

Johnny Hughes wrote:
> Benjamin Smith wrote:
>> Can anybody explain to me what's going on here? This is a CentOS 4 i386
>> system.
>>
>> [root@edison ~]# rm -f /etc/prelink.cache
>> [root@edison ~]# /etc/cron.daily/prelink
>> [root@edison ~]# rpm -qf /usr/bin/sqlite3
>> sqlite-3.3.6-2
>> [root@edison ~]# rpm --verify sqlite
>> prelink: /usr/bin/sqlite3: at least one of file's dependencies has changed
>> since prelinking
>> S.?..... /usr/bin/sqlite3
>> [root@edison ~]# rpm -q --dump sqlite | grep "bin/sqlite3"
>> /usr/bin/sqlite3 29044 1178360479 70e7158185e01e23dd2a62fa00f0f752 0100755
>> root root 0 0 0 X
>> [root@edison ~]# md5sum /usr/bin/sqlite3
>> 6e4b1dc7b0b5ade26448ed700c33e05f /usr/bin/sqlite3
>> [root@edison ~]# prelink -u /usr/bin/sqlite3
>> [root@edison ~]# md5sum /usr/bin/sqlite3
>> 70e7158185e01e23dd2a62fa00f0f752 /usr/bin/sqlite3
>> [root@edison ~]# rpm --verify sqlite
>> [root@edison ~]# prelink -f /usr/bin/sqlite3
>> prelink: /usr/lib/libncurses.so.5.4: .debug_loc adjusting unfinished
>> [root@edison etc]# md5sum /usr/bin/sqlite3
>> 70e7158185e01e23dd2a62fa00f0f752 /usr/bin/sqlite3
>> [root@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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Prelink: Something's happening here
 

On Sun, Dec 23, 2007, Johnny Hughes wrote:
>Johnny Hughes wrote:
...
>>> 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?
>>
...
>
>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".

A minor problem if one is trying to find changes on a possibly
cracked system.

Personally I figure being able to verify a system at any time is
far more important than any possible optimization from prelinking
so remove/disable prelink.

Bill
--
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

Government's view of the economy could be summed up in a few short phrases:
If it moves, tax it. If it keeps moving, regulate it. And if it stops
moving, subsidize it -- Ronald Reagan
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Prelink: Something's happening here
 

Bill Campbell wrote:
> On Sun, Dec 23, 2007, Johnny Hughes wrote:
>> Johnny Hughes wrote:
> ...
>>>> 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?
> ...
>> 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".
>
> A minor problem if one is trying to find changes on a possibly
> cracked system.
>
> Personally I figure being able to verify a system at any time is
> far more important than any possible optimization from prelinking
> so remove/disable prelink.
>

Sure ... and that is an option for the user. RHEL ships with prelinking
enabled by default, so CentOS will too.

Does prelinking really help ... maybe for some things.

It just depends on your priorities.

Thanks,
Johnny Hughes


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos