Bug 693953

Summary: error: unpacking of archive failed: cpio: read failed - Bad file descriptor
Product: [Fedora] Fedora Reporter: Matt Hirsch <matthew.hirsch>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 14CC: ffesti, jnovy, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-12 18:22:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Matt Hirsch 2011-04-06 04:13:55 UTC
Description of problem:
I have encountered this error on two different i686 Fedora 14 machines over the last few weeks when running a yum update: "cpio: Digest mismatch" The problem has occurred with a variety of different rpms. Most recently I have run into this problem with gnome-icon-theme-2.31.0-1.fc14.noarch.rpm, so I will use this as an example. I have downloaded this package, and attempted to install it from a file with rpm. rpm gives the error in the title. I have downloaded the file from multiple mirrors with wget and checked the md5sums against one another and they all match, so a corrupted download is very unlikely.

I don't think this issue is related to my local rpm database, but nonetheless I have deleted my /var/lib/rpm/__db.00* files and run a rpm --rebuilddb, which does not solve the problem.

In some cases, simply rerunning rpm -Uvh package.rpm will eventually work. Non-deterministic behavior seems very strange, so I ran the following test:

rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm | cpio -imdv
<.. cpio lists files in the rpm, then.. >
cpio: premature end of file

But this is also non-deterministic. Sometimes (but rarely) cpio succeeds without the premature eof message.

So I tried this:

# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > a
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > b
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > c
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > d
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > e
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > f
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > g
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > h
# rpm2cpio gnome-icon-theme-2.31.0-1.fc14.noarch.rpm > i

# md5sum [abcdefghi]
c5ec5a10dfa8274459c1e0d828fdcc1d  a
c5ec5a10dfa8274459c1e0d828fdcc1d  b
c5ec5a10dfa8274459c1e0d828fdcc1d  c
c5ec5a10dfa8274459c1e0d828fdcc1d  d
c5ec5a10dfa8274459c1e0d828fdcc1d  e
02fc149e19b867593ed72eed73ec2ddf  f
c5ec5a10dfa8274459c1e0d828fdcc1d  g
c5ec5a10dfa8274459c1e0d828fdcc1d  h
c5ec5a10dfa8274459c1e0d828fdcc1d  i

Note that f has a different checksum. Sure enough, cat [abcdeghi] | cpio -imdv all fail, but cat f | cpio -imdv succeeds.

# du -bsc [abcdefghi]
9003008	a
9003008	b
9003008	c
9003008	d
9003008	e
9003676	f
9003008	g
9003008	h
9003008	i

Version-Release number of selected component (if applicable):
rpm-4.8.1-5.fc14.i686
yum-3.2.28-5.fc14.noarch

How reproducible:
Reproduceible frequently with select packages for i686.

Steps to Reproduce:
1. yum update (when select packages are to be installed)

OR

1. download affected package
2. rpm -Uvh package.rpm

OR

1. download affected package
2. rpm2cpio package.rpm | cpio -imdv
  
Actual results:
package fails to install with message:
error: unpacking of archive failed: cpio: read failed - Bad file descriptor
or cpio fails with error:
cpio: premature end of file

Expected results:
Normal package installation

Additional info:

At the moment, the following packages seem to exhibit this behavior for me, but there have been many more examples:

gnome-icon-theme-2.31.0-1.fc14.noarch.rpm
gnome-themes-2.32.0-1.fc14.noarch.rpm
mono-core-2.6.7-4.fc14.i686.rpm
kernel-2.6.35.11-83.fc14.i686.rpm

Comment 1 Matt Hirsch 2011-11-12 18:22:10 UTC
I just noticed that this is still open. I solved this problem some time ago - it was not a software bug. The CPU on the system in question was running at the wrong clock rate, which caused some strange, non-deterministic, behavior.