Bug 105908 - rpmbuild believes file has a MD5 sum of all zeroes
rpmbuild believes file has a MD5 sum of all zeroes
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm-build (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
http://uberh4x0r.org/~yax/rocks-sge-5...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-29 09:11 EDT by rudi
Modified: 2007-04-18 12:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-28 12:50:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description rudi 2003-09-29 09:11:54 EDT
Description of problem:
rpmbuild generates a package that I can't install. It believes that there's this
file with a MD5 sum of all zeroes. Of course, when installing the package, rpm
finds out that the sum is something entirely different.

Version-Release number of selected component (if applicable):
rpm-build-4.2.0-0.30

How reproducible:
Always

Steps to Reproduce:
1. Generate package
2. Install it

Actual results:
# rpm -Uvh rocks-sge-5.3p4-3.i386.rpm
Preparing...                ########################################### [100%]
   1:rocks-sge              ########################################### [100%]
error: unpacking of archive failed on file
/opt/sge/utilbin/glinux/openssl;3f7829af: cpio: MD5 sum mismatch

Expected results:
File's MD5 sum is picked up correctly and the package installs successfully.

Additional info:
Here's the dump of the file:
/opt/sge/utilbin/glinux/openssl 359288 1064802706
00000000000000000000000000000000 0100755 root root 0 0 0 X

File size, permissions and ownership appear to be correct.

A XML dump seems to confirm that the MD5 sum in the package's file list
is incorrectly believed to be all zeroes.

Here's the actual MD5 sum:

$ md5sum /tmp/rocks-sge-5.3p4-root/opt/sge/utilbin/glinux/openssl
6da82ad9d8c4f62e4f79e2184517a6af 
/tmp/rocks-sge-5.3p4-root/opt/sge/utilbin/glinux/openssl

For what is worth, "openssl" is a copy of /usr/bin/openssl that Grid Engine's
baroque build system wants to keep - for reasons I can't understand yet. It
is created by calling "install".

I noticed a warning related to the file in the build logs:

prelink: /tmp/rocks-sge-5.3p4-root/opt/sge/utilbin/glinux/openssl: at least one
of file's dependencies has changed since prelinking

Just to have all corners covered, I tried issuing a "prelink /usr/bin/openssl".
That made the warning go away, but the correct MD5 sum is still not picked up.

The system is a current Raw Hide setup (20030923). I am going to try rebuilding
the package later today on a RH9 box. I'll also try to see if I can get the
relevant strace output without having to wait for the next century.

I have uploaded the log to http://uberh4x0r.org/~yax/sge.log and the source RPM
to http://uberh4x0r.org/~yax/rocks-sge-5.3p4-3.src.rpm in case you need them.
Comment 1 Jeff Johnson 2003-09-29 13:26:27 EDT
Hmmm, 404 on the src.rpm. COuld you fixplease?
Comment 2 rudi 2003-09-29 17:14:20 EDT
Fixed. I had uploaded the file, but not moved it to public_html. Ooops.
By the way, I can't reproduce this on a RH9 box with all the errata and
rpmbuild versions 4.2-1 and 4.2-0.69.

Comment 3 Jeff Johnson 2003-12-28 12:50:09 EST
I've rebuilt on fc2+2.6.0 with rpm-4.2.2 but cannot reproduce.

Weird problem.
Comment 4 Frank Schruefer 2004-02-20 13:55:40 EST
Hy,

I had a similar error msg:
error: unpacking of archive failed on file
/opt/siteforum/COMMAND.TRACE;403653df: cpio: MD5 sum mismatch

The problem was that my build script redirected the trace of rpmbuild
to a file included in the specs %files section. This means a package
file was modified while the package was generated.

Rpmbuild should either complain about modified files like tar does
(tar says something like 'file is modified as we read it') or maybe
md5 on the copy it is putting into the package anyways.

But as it behaves now it simply generates a broken rpm.

-- 
Thanks,
  Frank Schruefer

Note You need to log in before you can comment on or make changes to this bug.