Bug 431403 - probable wrong libgcc-4.1.2-33.i386.rpm checksum in FC8 primary.xml.gz
probable wrong libgcc-4.1.2-33.i386.rpm checksum in FC8 primary.xml.gz
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-04 03:30 EST by Mark Abraham
Modified: 2008-06-03 13:21 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-03 13:21:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Abraham 2008-02-04 03:30:13 EST
Description of problem:

I'm attempting an FTP install of FC8 started with an FC5 installation disk. I've
done an rsync mirror of my ISP's FC8 distribution and am making that available
by FTP from another machine on my network. I select FTP install and it finds my
server fine, does the dependency check, and starts downloading packages. When it
gets to libgcc-4.1.2-33.i386.rpm, the installer complains that there's a problem
consistent with media corruption. I'm sorry I can't remember the wording now. I
am prompted to retry or reboot, and the former is not successful. This suggests
that the MD5 checksum isn't working. I am able to produce the same problem using
my ISP's FC8 mirror, so the problem isn't with me mangling this file.

I hope I guessed correctly that anaconda is the right component for this bug
report. Otherwise, please accept my apologies and redirect as suitable.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. FTP install of FC8
2. Choose suitable options
3. Wait for checksum 
Actual results:

Aborted installation

Expected results:

Correct installation

Additional info:

I observed in repodata/primary.xml.gz the section:

<package type="rpm">
  <version epoch="0" ver="4.1.2" rel="33"/>
  <checksum type="sha" pkgid="YES">dcbba9125e8a1d66c97a459bbbde9cd9b2c45fca</che
  <summary>GCC version 4.1 shared support library</summary>
  <description>This package contains GCC shared support library which is needed
e.g. for exception handling support.</description>
  <packager>Fedora Project</packager>
  <time file="1193463564" build="1192981403"/>
  <size package="96895" installed="73312" archive="74180"/>
  <location href="Packages/libgcc-4.1.2-33.i386.rpm"/>

The package size is correct at 96895 bytes, but md5sum reports 

f32ef4801e6c2af0c52557a7858afb4a */home/Mark/libgcc-4.1.2-33.i386.rpm

which clearly differs from that above.

I tried substituting a few other copies of this file from other mirrors, but
they were identical to the one they had. I also tried substituting this MD5 sum
into primary.xml and re-gzipping, but that caused the primary.xml.gz checksum to
be wrong and I gave up.
Comment 1 Mark Abraham 2008-02-04 05:44:45 EST
Enhancing the above, you can observe this mismatch between the contents of the
metadata file here


and running md5sum on the RPM file here

Comment 2 Mark Abraham 2008-02-04 06:23:14 EST
Duh. It's not an MD5 sum. sha1sum is correct for this RPM and the metadata file.
That scotches my theory on what is causing the problem, but doesn't solve it.
Comment 3 Chris Lumens 2008-02-16 13:02:57 EST
Can you attach /tmp/anaconda.log to this bug report after you get to the error
message in question?
Comment 4 Mark Abraham 2008-02-17 05:09:58 EST
(In reply to comment #3)
> Can you attach /tmp/anaconda.log to this bug report after you get to the error
> message in question?

Unfortunately, no. The machine on which I was attempting the above install has
now had an FC8 system installed on it via the LiveCD with no problems, and the
partition where that logfile would have been written has been over-written. The
current /tmp/anaconda.log is also not helpful, since it doesn't mention libgcc.

I'll remember to keep anaconda.log files in future, though. I'd have to do some
googling to work out how you can recover a .log file from a machine on which an
install failed to complete, but I guess a rescue disk would give you a chance.


Comment 5 Andy Lindeberg 2008-06-03 13:21:21 EDT
Without error logs, there's not much we can do. Closing this; please reopen if
you either run into the bug again or manage to recover the log file.

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