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
-- Only those who reach toward a goal are likely to achieve it.
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
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
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
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
-
Benjamin Smith -
Bill Campbell -
Johnny Hughes