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): N/A How reproducible: Always 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"> <name>libgcc</name> <arch>i386</arch> <version epoch="0" ver="4.1.2" rel="33"/> <checksum type="sha" pkgid="YES">dcbba9125e8a1d66c97a459bbbde9cd9b2c45fca</che cksum> <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> <url>http://gcc.gnu.org</url> <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.
Enhancing the above, you can observe this mismatch between the contents of the metadata file here http://mirrors.kernel.org/fedora/releases/8/Everything/i386/os/repodata/primary.xml.gz and running md5sum on the RPM file here http://mirrors.kernel.org/fedora/releases/8/Everything/i386/os/Packages/libgcc-4.1.2-33.i386.rpm
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.
Can you attach /tmp/anaconda.log to this bug report after you get to the error message in question?
(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. Thanks! Mark
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.