我有一个较旧的系统（Fedora Core 6，这是一个用于为较旧设备进行构建的独立系统）。我正在尝试构建一个匹配的 VM，并且我注意到一个我无法解释的差异。
两个系统都具有 glibc-2.5-3 软件包，其中包括文件 /lib/libc-2.5.so。
rpm -qi glibc两个系统上的输出完全匹配。
在两个系统上，rpm -Vv都表示一切正常（........ /lib/libc-2.5.so）。
两个系统上的文件md5sum不匹配。（
当我在两个系统上执行objdump -x该文件时，我得到了不同的起始地址值，证实这两个 SO 文件实际上是不同的。
那么，为什么rpm -V告诉我 md5sum 匹配，而事实显然不匹配？这些库怎么会变得不同？
答案1
这些库很可能是预链接的。RPM 了解预链接。
这个帖子谈论它。
“问题”（如果你可以这么称呼的话）是 rpm 知道 prelink，并且知道如何处理它。正如这个简洁解释的那样邮件列表电子邮件, “rpm 在 –verify 时会预链接 –verify，这本质上是 –undo，然后再次预链接并进行比较。” 因此，rpm 不会验证失败的原因在于它基本上关闭了要检查文件的预链接，运行验证，然后重新打开预链接。 这就是为什么 rpm 不会报告 MD5SUM 更改，但 AIDE 会报告的原因。
链接的电子邮件位于：
2003 年 4 月 4 日星期五下午 04:24:39，James Ralston 写道：
2003-04-04 11:34:35-0500 Jakub Jelinek 写道：
人前链接
我最终会写更多文档。
一个问题...
如果 prelink 修改了实际的二进制文件和库（从我对手册页的解读来看似乎是这样的），那么这是否意味着“rpm --verify”毫无用处？prelink 修改的每个二进制文件和库都将无法通过 size/md5sum/mtime 测试。
它不会失败。rpm 在 --verify 时将预链接 --verify，这本质上是 --undo 然后再次预链接并进行比较。
即使使用 --undo 来恢复预链接，“rpm --verify”仍然会失败（除非 prelink 恢复了启动前文件的精确 mtime）...
prelink 不会修改预链接库/二进制文件的 mtime。
雅库布
另一种可能性是，一般来说，可以在 spec 文件本身中按文件或目录级别禁用单个验证检查。因此，虽然在这种情况下并非如此，但打包者完全有可能禁用已知会因某种原因而更改的文件的 MD5 和检查。