Red Hat Bugzilla – Bug 72898
rpm modifying packages on failed install
Last modified: 2008-05-01 11:38:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
Description of problem:
After downloading some packages, I can --checksig them fine (they aren't GPG
signed, but they do have an MD5 sum). Trying to install these particular
packages failed with a cpio error on one of the files in one of the packages.
After trying to install them, the packages no longer --checksig fine; one of the
file's MD5 sums has changed.
Version-Release number of selected component (if applicable):
RPM version 4.0.4
Tried briefly, but couldn't.
Steps to Reproduce:
1. Install a version of mozilla earlier than 1.1 using the RH 7.x RPMs found on
ftp.mozilla.org. I'm not sure what steps are required to create the proper
"crud" in /var/lib/mozilla*
2. 'rpm -e' all mozilla packages.
3. Download mozilla-1.1 from ftp.mozilla.org. Make a backup copy of the
3. rpm --checksig all mozilla packages; they should work (they use only MD5
4. Try to rpm -i all mozilla packages; the mozilla-1.1 package fails with a
complaint about an invalid cpio checksum on one of the files in it.
5. rpm --checksig the mozilla packages again; the mozilla-1.1 package has
changed, and the checksum will be invalid. 'diff'ing the backup copy and the
current copy reveals that the file has changed. 'diff'ing the 'hexdump'ed files
reveals that the change is not a few characters, but many.
To get mozilla-1.1 to work properly:
6. rpm -e all mozilla packages.
7. rm -Rf /usr/lib/mozilla*
8. rpm -i all mozilla packages. They will work this time, and the checksum
will still be valid.
Actual Results: RPM modifies part of one of the package files upon failed install.
Expected Results: RPM should never modify an RPM unless it is building one or
adding a signature. When trying to install a package, RPM should open the file
read-only, since the write permission is unnecessary. (right?)
System is installed with all 7.2 errata, as far as I know. I used mozilla-1.0
for a long time, then mozilla-1.1b, and now mozilla-1.1. Thus, when I
encountered this error, I had a /usr/lib/mozilla, /usr/lib/mozilla-1.1b, and
after the failed install I had a /usr/lib/mozilla-1.1. Removing all three let
me install mozilla.
I don't think this is a security issue because there are lots of mitigating
factors (the user must be root and try to install the package in order to modify
it). But it is annoying (after one failed attempt at installing the package,
you need to reobtain the RPM to try to reinstall it).
This could be an issue somehow with the mozilla packages itself, but it seems
unlikely that the install script would modify the package.
What release of rpm-4.0.4 (i.e. rpm -q rpm)?
[root@paul mozilla]# rpm -q rpm
Try rpm-4.0.4-7x.18 from Red Hat 7.3, there
are other important fixes there. Even better
is rpm-4.1 from Raw Hide or
all but released.
Meanwhile back to your problem.
Did you reproduce this problem, or did it just happen once?
Is NFS involved?
Created attachment 73844 [details]
Transcripts of failures
I have reproduced it two more times, essentially by installing mozilla-1.1b,
using it, removing it, installing mozilla-1.1, using it, removing it, and
repeating. I have not been able to make it fail consistently (unfortunately).
NFS is not involved... I don't have any NFS mounts or exports.
I've attached the transcripts of these two latest failures. I also have copies
of the RPM file before and after having one of these failures, if you'd like to
look at what parts of the files are getting changed.
OK, I believe you're seeing a problem, thanks for
making the effort to reproduce.
Can you also attach the output of "rpm -qa"? Problems
like you are reporting are often with other packages.
In fact, I'm hard pressed to understand how rpm
(which opens packages for install with O_RDONLY, verify with
strace if you wish) can modify the original package
contents at all.
Off to mozilla for a 2nd opinion.
glibc mmap'ed stdio? kernel? hardware?
7.3 doesnt have mmap stdio not that it should matter
I'd like to know what the results are if you have time to do
chmod 400 on the package that seems to get modified then run rpm
strace -o logfile rpm ...
Then gzip the logfile and attach it
Sorry... bad hardware seems to be most suspect. (IBM DeskStar hard drive which
died soon after I reported the bug, and also memtest86 found some errors in the
RAM.) Thanks, though; your support is great! :)