This is on a brand-new fc5 server. Just about any "rpm verfify" command gives something like: # rpm -qV lynx prelink: /usr/bin/lynx: at least one of file's dependencies has changed since prelinking S.?..... /usr/bin/lynx rpm --verify postgresql-server prelink: /usr/bin/initdb: at least one of file's dependencies has changed since prelinking S.?..... /usr/bin/initdb prelink: /usr/bin/pg_controldata: at least one of file's dependencies has changed since prelinking S.?..... /usr/bin/pg_controldata prelink: /usr/bin/pg_ctl: at least one of file's dependencies has changed since prelinking S.?..... /usr/bin/pg_ctl This is fine... but... there's no clue given as to how to learn which files have actually changed.
For reference: # prelink --all prelink: /usr/bin/wvdialconf: NOBITS section followed by non-NOBITS section in the same segment prelink: /usr/bin/wvdial: NOBITS section followed by non-NOBITS section in the same segment
The msg is from prelink, not rpm. You'll get a better and faster answer if you reassign this bug to prelink.
I have no idea what prelink is... but I'll send it over there too.
User pnasrat's account has been closed
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I've stumbled over this on current (i.e. pre F-12) Rawhide: [root@gibraltar ~]# rpm -Vf /lib64/libvolume_id.so.1.1.0 prelink: /lib64/libvolume_id.so.1.1.0: at least one of file's dependencies has changed since prelinking S.?...... /lib64/libvolume_id.so.1.1.0 Florian Festi found that prelink provides this RPM macro which should give the un-prelinked binary contents on stdout: /etc/rpm/macros.prelink: # rpm-4.1 verifies prelinked libraries using a prelink undo helper. # Note: The 2nd token is used as argv[0] and "library" is a # placeholder that will be deleted and replaced with the appropriate # library file path. %__prelink_undo_cmd /usr/sbin/prelink prelink -y library Unfortunately, this doesn't work if un-prelinking and prelinking again doesn't produce a file identical to the original one. I assume this doesn't work if dependencies change or whatever. Instead of "prelink -y ...", "prelink -u ..." could be used if it were able to spit out the contents to stdout: - "prelink -u -o - ..." produces a file named "-" containing the original binary - "prelink -u -o /dev/stdout ..." replaces /dev/stdout with the binary contents - "prelink -u -o /proc/self/fd/1 ..." doesn't work at all (besides not being very portable) Alternatively to making the above work, one could add a "--stdout" option to be used with "-u" (or a "--always" for use with "-y"). Regardless of the solution, /etc/rpm/macros.prelink needs to be adapted as well.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I am having the same problem on my new Fedora install. Many rpms seem to give this error on at least one file. Also, presumably as a result, the corresponding file has the following result code: S.?...... (indicating a problem with both the size and md5um) Though could anybody explain why I get a question mark(?) rather than the usual five (5)? In any case it is a pretty severe problem since it makes it impossible to check install integrity.
OK - I think I figured out part of the problem. It seems that 'prelink' hadn't run since the system was built so this messed up the verifies. After running prelink, most (but NOT all) of the pre-link errors and "S.?......" lines have resolved. However, even running 'rpm -Va' right after a "full" prelink, I still get a bunch of residual prelink errors: prelink: /usr/lib/libusb-1.0.so.0.0.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libusb-1.0.so.0.0.0 prelink: /usr/lib/libblas.so.3.2.1: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libblas.so.3.2.1 prelink: /usr/lib/libevent-1.4.so.2.1.3: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libevent-1.4.so.2.1.3 prelink: /usr/lib/libgfortran.so.3.0.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libgfortran.so.3.0.0 prelink: /usr/lib/atlas/libatlas.so.3.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/atlas/libatlas.so.3.0 prelink: /usr/lib/atlas/libcblas.so.3.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/atlas/libcblas.so.3.0 prelink: /usr/lib/atlas/libf77blas.so.3.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/atlas/libf77blas.so.3.0 prelink: /usr/lib/atlas/liblapack.so.3.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/atlas/liblapack.so.3.0 prelink: /usr/lib/libamd.so.2.2.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libamd.so.2.2.0 prelink: /usr/lib/libcamd.so.2.2.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libcamd.so.2.2.0 prelink: /usr/lib/libccolamd.so.2.7.1: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libccolamd.so.2.7.1 prelink: /usr/lib/libcholmod.so.1.7.1: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libcholmod.so.1.7.1 prelink: /usr/lib/libcolamd.so.2.7.1: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libcolamd.so.2.7.1 prelink: /usr/lib/libcxsparse.so.2.2.3: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libcxsparse.so.2.2.3 prelink: /usr/lib/libumfpack.so.5.4.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libumfpack.so.5.4.0 prelink: /usr/lib/libftgl.so.2.1.3: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libftgl.so.2.1.3 prelink: /usr/lib/libqrupdate.so.1.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libqrupdate.so.1.0 prelink: /usr/lib/libarpack.so.2.1: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libarpack.so.2.1 prelink: /usr/lib/libgtkspell.so.0.0.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib/libgtkspell.so.0.0.0 I also still don't understand what the difference is between a "?" and a "5" in the md5sum field.
I see this bug in Fedora 13.
(In reply to comment #11) > I see this bug in Fedora 13. Reverting the product version to 12: That the problem exists in F-13 doesn't mean it's fixed in F-12. If a bug needs to be tracked separately for other Fedora releases, it can be easily cloned. But before doing that check back with Jakub if that is necessary: I assume if he put a fix in F-12, he would put it in later versions and Rawhide as well.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still happening on F-14, e.g.: prelink: /usr/lib64/libdevkit-power-gobject.so.1.0.1: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib64/libdevkit-power-gobject.so.1.0.1
I see this too, I've tried running prelink --all, didn't change much.
This is still happening on F-15: prelink: /usr/lib/libkresources.so.4.6.0: at least one of file's dependencies has changed since prelinking prelink --all didn't make any difference. This bug is about 5 years old, and it's following the Fedora releases, so the automatic message "This message is a reminder that Fedora $VERSION is nearing its end of life" should not apply.
Happening on Red Hat 5.7, after an upgrade from 5.6 and a manual "prelink" run. While doing "rpm --verify" on all packages: prelink: /usr/lib64/libpspell.so.15.1.3: at least one of file's dependencies has changed since prelinking prelink: /usr/lib/libaudiofile.so.0.0.2: at least one of file's dependencies has changed since prelinking prelink: /usr/lib/libesd.so.0.2.36: at least one of file's dependencies has changed since prelinking prelink: /usr/lib/libgconf-2.so.4.1.0: at least one of file's dependencies has changed since prelinking prelink: /usr/lib64/libgd.so.2.0.0: at least one of file's dependencies has changed since prelinking
I see this here on F15, too. I think the problem is that "prelink -a" looks only at binaries (i.e. executables), not at shared objects. DSOs are only prelinked if some binary that prelink finds depends on them. Thus DSOs that aren't used by any binary may cause this problem. If such a DSO is updated, its prelink information is never updated. I can see no way to work around this except running prelink explicitly on all .so files, like this: prelink -aRmv $(ldconfig -p | awk 'NR > 1 {print $NF; }') That workaround isn't perfect because prelink may fail if any library dependency in one of the explicitly specified DSOs is broken. In a properly prelinked system, only that aren't used by any executable will cause this error message. But on the other hand, the false error messages irritate users and make it hard to do a meaningful "rpm -V". Rather than running "prelink -a" in a cron job, as F15 does it, it would be desirable to run prelink whenever a package containing binaries and/or executables is installed or updated by rpm.
I still see this on F16 for some libraries *and* binaries: prelink: /usr/bin/gcr-viewer: at least one of [...] prelink: /usr/bin/gnome-keyring-3: at least one of [...] prelink: /usr/bin/gssdp-device-sniffer: at least one of [...] prelink: /usr/bin/palimpsest: at least one of [...] prelink: /usr/bin/pdftex: at least one of [...] prelink: /usr/bin/pstoedit: at least one of [...] prelink: /usr/bin/yelp: at least one of [...] prelink: /usr/bin/zenity: at least one of [...] prelink: /usr/lib64/libavahi-ui-gtk3.so.0.1.4: at least one of [...] prelink: /usr/lib64/libcairo-gobject.so.2.11000.2: at least one of [...] prelink: /usr/lib64/libgcr-3.so.1.0.0: at least one of [...] prelink: /usr/lib64/libgdu-gtk.so.0.0.0: at least one of [...] prelink: /usr/lib64/libsemanage.so.1: at least one of [...] prelink: /usr/lib64/libunique-3.0.so.0.0.2: at least one of [...] prelink: /usr/lib64/libustr-1.0.so.1.0.4: at least one of [...] prelink: /usr/lib64/libwebkitgtk-3.0.so.0.11.0: at least one of [...] prelink: /usr/lib64/libyelp.so.0.0.0: at least one of [...] prelink: /usr/libexec/gdu-format-tool: at least one of [...] prelink: /usr/libexec/gdu-notification-daemon: at least one of [...] prelink: /usr/libexec/gnome-keyring-prompt-3: at least one of [...] prelink: /usr/libexec/nm-openvpn-auth-dialog: at least one of [...] prelink: /usr/libexec/nm-pptp-auth-dialog: at least one of [...] prelink: /usr/libexec/nm-vpnc-auth-dialog: at least one of [...] prelink: /usr/libexec/webkitgtk3/GtkLauncher: at least one of [...]
YEah. I have got it in a 20 hour old install of F16 32bit. Bloody annoying since the bug seems to be over six years old now.
Hi, I just took ownership of a customer case that is linked to this bug. I don't see it in a RHEL5.8. Is there special conditions to reproduce this issue? [root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.8 (Tikanga) [root@localhost ~]# prelink --all prelink: /usr/bin/emacs-21.4-x: COPY relocations don't point into .bss or .sbss section [root@localhost ~]# rpm -V $(rpm -qa) .......T c /etc/libuser.conf ..5....T c /etc/yum/pluginconf.d/rhnplugin.conf S.5..... c /etc/openldap/ldap.conf S.5..... c /etc/openldap/ldap.conf .......T c /etc/audit/auditd.conf ....L... c /etc/pam.d/system-auth ....L... c /etc/pam.d/system-auth S.5....T c /etc/printcap SM5....T c /etc/sysconfig/iptables-config ..5....T c /usr/lib64/security/classpath.security .......T c /etc/inittab S.5..... c /etc/openldap/ldap.conf S.5..... c /etc/openldap/ldap.conf ....L... c /etc/pam.d/system-auth ....L... c /etc/pam.d/system-auth ..5....T c /usr/lib64/security/classpath.security S.5....T c /etc/sane.d/dll.conf .M....G. /etc/dirsrv S.5....T /etc/rc.d/init.d/dirsrv .M....G. /usr/lib64/dirsrv S.5....T c /etc/xml/catalog S.5....T c /usr/share/sgml/docbook/xmlcatalog S.5....T /usr/share/icons/hicolor/icon-theme.cache SM5..U.T c /etc/dirsrv/admin-serv/console.conf .M....G. /usr/lib64/dirsrv S.5....T c /etc/login.defs SM5....T c /etc/sysconfig/rhn/up2date S.5....T c /etc/ntp/ntpservers S.5....T c /etc/ssh/sshd_config S.5..... c /etc/ldap.conf S.5..... c /etc/ldap.conf S.5..... c /etc/ldap.conf S.5..... c /etc/ldap.conf S.5....T c /etc/sysconfig/system-config-securitylevel I can test in more releases if needed. Thank you.
One occurrence in Fedora 17. [root@localhost ~]# cat /etc/redhat-release Fedora release 17 (Beefy Miracle) [root@localhost ~]# prelink --all prelink: /usr/bin/emacs-24.1: COPY relocations don't point into .bss or .sbss section [root@localhost ~]# rpm -V $(rpm -qa) .M....G.. /var/log/gdm .M....... /var/run/gdm missing /var/run/gdm/greeter S.5....T. c /etc/selinux/targeted/contexts/files/file_contexts.local S.5....T. c /etc/printcap S.5....T. c /etc/services ..5....T. c /etc/sysctl.conf S.5....T. c /etc/plymouth/plymouthd.conf ....L.... c /etc/pam.d/fingerprint-auth ....L.... c /etc/pam.d/password-auth ....L.... c /etc/pam.d/postlogin ....L.... c /etc/pam.d/smartcard-auth ....L.... c /etc/pam.d/system-auth missing /var/run/NetworkManager .......T. /lib/modules/3.6.8-2.fc17.x86_64/modules.devname .......T. /lib/modules/3.6.8-2.fc17.x86_64/modules.softdep S.5....T. c /etc/logrotate.conf S.5....T. c /etc/redhat-ddns/hosts S.5....T. c /etc/openldap/ldap.conf .......T. c /etc/chrony.conf S.5....T. /etc/cron.d/smolt S.5....T. c /etc/sudoers S.5....T. c /etc/postfix/main.cf S.5....T. c /etc/postfix/virtual S.5....T. c /etc/maven/maven2-depmap.xml .......T. /lib/modules/3.6.10-2.fc17.x86_64/modules.devname .......T. /lib/modules/3.6.10-2.fc17.x86_64/modules.softdep S.5....T. c /etc/security/pwquality.conf S.5....T. c /etc/kdump.conf .......T. /lib/modules/3.6.9-2.fc17.x86_64/modules.devname .......T. /lib/modules/3.6.9-2.fc17.x86_64/modules.softdep .M....... c /etc/cups/subscriptions.conf .M....... /run/svnserve .M....... /var/lib/nfs/rpc_pipefs missing /var/run/wpa_supplicant ..5....T. c /etc/yum.repos.d/fedora-updates.repo ..5....T. c /etc/yum.repos.d/fedora.repo .M....... /sys prelink: /usr/lib64/libpkcs11-helper.so.1.0.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib64/libpkcs11-helper.so.1.0.0
Follow up on previous update: [root@localhost ~]# prelink -y --md5 /usr/lib64/libpkcs11-helper.so.1.0.0 prelink: /usr/lib64/libpkcs11-helper.so.1.0.0: at least one of file's dependencies has changed since prelinking [root@localhost ~]# prelink /usr/lib64/libpkcs11-helper.so.1.0.0 [root@localhost ~]# prelink -y --md5 /usr/lib64/libpkcs11-helper.so.1.0.0 af36274a3e1ad16ac59152beef60f8f2 /usr/lib64/libpkcs11-helper.so.1.0.0 No error after explicit prelink, but in previous update I ran "prelink --all". So, Did the "prelink --all" missed this file ?
(In reply to comment #23) > So, Did the "prelink --all" missed this file ? I seems that automatic prelink does not consider .so files, only executables. See also comment #18 This happens on a RH 6.3 rpm --verify --all announces that: "prelink: /usr/lib64/libusb-0.1.so.4.4.4: at least one of file's dependencies has changed since prelinking" A daily cron-started prelink (via /etc/cron.daily/prelink) does not change that, i.e. that error is not being fixed. Well, a full prelink doesn't always run so I tried manually: "prelink -av -f" (BTW, Getting a set of "X has undefined non-weak symbols" warnings....) But this does not fix it: "prelink: /usr/lib64/libusb-0.1.so.4.4.4: at least one of file's dependencies has changed since prelinking" No joy.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm still seeing this on F17 (though much less frequently than before).
I see this in F18 too. $ rpm -Va udisks prelink: /lib/udev/udisks-part-id: at least one of file's dependencies has changed since prelinking S.?...... /lib/udev/udisks-part-id prelink: /usr/libexec/udisks-helper-create-partition: at least one of file's dependencies has changed since prelinking S.?...... /usr/libexec/udisks-helper-create-partition prelink: /usr/libexec/udisks-helper-create-partition-table: at least one of file's dependencies has changed since prelinking S.?...... /usr/libexec/udisks-helper-create-partition-table prelink: /usr/libexec/udisks-helper-delete-partition: at least one of file's dependencies has changed since prelinking S.?...... /usr/libexec/udisks-helper-delete-partition prelink: /usr/libexec/udisks-helper-modify-partition: at least one of file's dependencies has changed since prelinking S.?...... /usr/libexec/udisks-helper-modify-partition
(In reply to comment #7) ... > Instead of "prelink -y ...", "prelink -u ..." could be used if it were able > to spit out the contents to stdout: ... > Alternatively to making the above work, one could add a "--stdout" option to > be used with "-u" (or a "--always" for use with "-y"). Regardless of the > solution, /etc/rpm/macros.prelink needs to be adapted as well. This would be the very solution, I think. I understand that prelink -y works this way because standalone prelink has no external reference it can compare with. rpm has the md5 sums in its database so the only thing what is necessary is dump the un-prelinked version to stdout and calculate the md5 of that and compare it to db. As a side effect it would give a performance boost because the re-prelink is not necessary any more. +1 for a --stdout parameter
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Is there any progress on this? I still get: ==================== Installed Packages ==================== blktrace.x86_64 : Utilities for performing block layer IO tracing in the linux : kernel File: /usr/bin/btreplay Problem: checksum does not match Current: sha256:cf7ae3b8152a86b660fb8eeb9f0e9d38a1c2fd1059d2ea929e9e189cfe01de2e Original: sha256:78abc14b2a58fb68896a6892a45ece2d1e1097d66f803186e434ec813089f2d0 -------- Problem: size does not match Current: 27 k Original: 24 k crda.x86_64 : Regulatory compliance daemon for 802.11 wireless networking File: /sbin/crda Problem: checksum does not match Current: sha256:1792ecd87ddee9f2e47adf6442f99e3f6808fdcc2bdd1aebcd2e055d674baa91 Original: sha256:630b5cb5669e96764d582f3d134821813f670424ae414b207b631e5158fa0456 -------- Problem: size does not match Current: 14 k Original: 9.8 k File: /sbin/regdbdump Problem: checksum does not match Current: sha256:dc9e946b418eefde712f6f3f5eea3c72e0ec2640274daeed267f045c0f7a73ad Original: sha256:5f22464fa0521fb7f79c5f776a87527f8f418e31f3010f105f2d8a8e5075bc34 -------- Problem: size does not match Current: 11 k Original: 7.6 k cryptsetup-luks.x86_64 : A utility for setting up encrypted filesystems File: /sbin/cryptsetup Problem: checksum does not match Current: sha256:2e6e45561a63e098014c7856d3723f0230e646cb333b5612631570b8a6f4558f Original: sha256:ae6352485ccaaa652e7a71d08fb613ae9c94621dc961bd1ba8c0ed6a46ea3df3 -------- Problem: size does not match Current: 41 k Original: 34 k gnupg2.x86_64 : Utility for secure communication and data storage File: /usr/bin/gpg-agent Problem: checksum does not match Current: sha256:ffbd40aae3ddcbe201a4d04303a36ffba662acfddbff44cde049b217fe0003ca Original: sha256:db0418e5405f36aff2588fcd30408ef2c0e7368904f017107435105aed2d67f2 -------- Problem: size does not match Current: 298 k Original: 291 k File: /usr/bin/gpg2 Problem: checksum does not match Current: sha256:a7f81c40778a62fb88bb7f500b1a502cda1281666e6d942ed825980eba62dbf3 Original: sha256:277fe5c85e5b60e3de5ecca1097167ea7c2db0a35cd80cea83d0ae5f1e681491 -------- Problem: size does not match Current: 750 k Original: 744 k File: /usr/bin/gpgkey2ssh Problem: checksum does not match Current: sha256:4b564d3cbf6c2100493e9953ae65c3e2105c149d1e9a4ca673932635c04853bc Original: sha256:6efa2c06debac42ee7d8fddfabbf201e10a7be92576768e0bbd8ff5475ea2783 -------- Problem: size does not match Current: 40 k Original: 35 k File: /usr/bin/gpgsplit Problem: checksum does not match Current: sha256:6d6947d46a7fdf7f9f5a2ee7c470b527bb9f429d0253e8713a9c1e5dff2e627f Original: sha256:545631f2e4a8fdef0e435203f3cf26cc848d48795ebb967b33afe3b6aa44a11e -------- Problem: size does not match Current: 51 k Original: 46 k File: /usr/bin/gpgv2 Problem: checksum does not match Current: sha256:7429838f82422de6bd14b6891a4f7aac35f1257eae51e4dd1742d80ed59d3479 Original: sha256:cb7de9e68d54973b4c823201ed7e5150437c9eeb4db1b75a15b483e1d3281e86 -------- Problem: size does not match Current: 334 k Original: 329 k libxslt.x86_64 : Library providing the Gnome XSLT engine File: /usr/bin/xsltproc Problem: checksum does not match Current: sha256:9af315314f9c10349dc600fd7fd112cbde037bd64f84c6945714bd4bbed85792 Original: sha256:c459c4f16dabeacf397abd98cc3282c43cf314fc128f49d138b029bcf73228df -------- Problem: size does not match Current: 29 k Original: 23 k mutt.x86_64 : A text mode mail user agent File: /usr/bin/mutt Problem: checksum does not match Current: sha256:244d0da61c22287865d1ada440f58b82b42f3925637162e378894aabc851758c Original: sha256:92d92aa6493db950c890e5e72757de05d12e1baf2774192235d48e03fabb7135 -------- Problem: size does not match Current: 799 k Original: 785 k xmlstarlet.x86_64 : Command Line XML Toolkit File: /usr/bin/xmlstarlet Problem: checksum does not match Current: sha256:4c6b14371e56ef8ffb977ec7eb8e7ea9cea174b7d9a7a0d685a2f466f22664f6 Original: sha256:e2ac79bb1ab2307a1d92dc32b67377dc8b66578d4cd92af1e5df5cc9a7a806de -------- Problem: size does not match Current: 110 k Original: 104 k verify done with outputs like: # rpm -V mutt.x86_64 prelink: /usr/bin/mutt: at least one of file's dependencies has changed since prelinking S.?...... /usr/bin/mutt
I think this warning is harmless ... Could be genetared when prelink warns like this : /usr/sbin/prelink: Could not prelink /usr/bin/dcopstart because it doesn't use /usr/lib64/freetype-freeworld/libfreetype.so.6, but one of its dependencies has been prelinked against it The goal is warning for not prelinkable so(s) , though.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Happens on a Fresh Fedora 20 install as well, including -- ironically enough -- the prelink RPM: [root@f20 cron.d]# rpm -qf /etc/sysconfig/prelink prelink-0.5.0-1.fc20.x86_64 [root@f20 cron.d]# rpm -qV prelink prelink: /usr/bin/execstack: at least one of file's dependencies has changed since prelinking S.?...... /usr/bin/execstack [root@f20 cron.d]#
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still happening on Fedora 20 x96_64. The problem with it is that it makes alomst impossible to see from first run if there is any problem with the rpm packages installed on the system. Please reopen and change version to Fedora 20.
Setting LD_LIBRARY_PATH before calling prelink itself or in /etc/sysconfig/prelink may help export LD_LIBRARY_PATH=/usr/lib64 or even export LD_LIBRARY_PATH=/usr/lib$([[ $(uname -m) == x86_64 ]] && echo 64 || :) See bug 1148241 for more details. BTW How can we "reopen this bug"? There is no such option in Bugzilla for mere mortals.
Why WONTFIX?
Fedora 21 no longer installs prelink by default. See also: #1190810 #1184712 and https://fedorahosted.org/fesco/ticket/1183 If prelink is not installed, rpm --verify should be ok. Note that Fedora 21 does still include prelink, it's just not installed by default anymore. It's not removed on upgrade.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I no longer see this problem in Fedora 25 x64. If nobody disagrees, please close it with "currentversion".
(In reply to cornel panceac from comment #42) > I no longer see this problem in Fedora 25 x64. If nobody disagrees, please > close it with "currentversion". That's because Fedora no longer enables prelink by default. Did you enable prelink and prelink the system, then do an RPM verify to see if this problem still exists?
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.