When does rpm -V not verify md5sums?

Question

I've got an older system (Fedora Core 6, it's an isolated system used to do builds for older devices). I'm trying to build a matching VM, and I've noticed a difference I can't explain.

Both systems have the package glibc-2.5-3 on them, which includes the file /lib/libc-2.5.so.

The rpm -qi glibc output matches exactly on both systems.

On both systems, rpm -Vv says everything is fine (........ /lib/libc-2.5.so).

The md5sum of the file on the two systems DO NOT MATCH. (

When I do an objdump -x of the file on the two systems, I get DIFFERENT start address values, confirming that in fact the two SO files are different.

So, why does rpm -V tell me that the md5sum matches, when it clearly doesn't? How is it that these libraries became different?

Answer 1

Those libraries are likely prelinked. RPM knows about prelinking.

This post talks about it.

The “problem” (if you can call it that) is that rpm knows about prelink, and knows how to deal with it. As is succinctly explained in this mailing list email, “rpm when –verify will prelink –verify, which is essentially –undo followed by prelinking again and comparing.” So the reason that rpm doesn’t fail the verification is that it is basically turning off prelink for the file(s) to check, running the verification, then turning prelink back on. This is why rpm won’t report on a MD5SUM change, but AIDE will.

Where the linked email is:

On Fri, Apr 04, 2003 at 04:24:39PM -0500, James Ralston wrote:

On 2003-04-04 at 11:34:35-0500 Jakub Jelinek wrote:

man prelink

I will eventually write more documentation.

One question...

If prelink modifies the actual binaries and libraries in-place (which seems to be the case from my reading of the man page), doesn't that essentially make "rpm --verify" useless? Every single binary and library modified by prelink will fail the size/md5sum/mtime tests.

It will not fail. rpm when --verify will prelink --verify, which is essentially --undo followed by prelinking again and comparing.

Even if --undo is used to revert the prelinking, "rpm --verify" would still fail (unless prelink restored the exact mtimes that were on the files before it started, that is)...

prelink does not modify mtimes of prelinked libraries/binaries.

Jakub

The other possibility, in general, is that individual verification checks can be disable on a per-file or per-directory level in the spec file itself. So, while not true in this case, it is entirely possible that a packager could disable MD5 sum checking for files that are known to change for one reason or another.