On 2/1/07, Rick Stevens <rstevens@xxxxxxxxxxxxxxx> wrote:
On Wed, 2007-01-31 at 20:14 -0500, Jeff G wrote: > On 1/31/07, Rick Stevens <rstevens@xxxxxxxxxxxxxxx> wrote: > > On Wed, 2007-01-31 at 18:15 -0500, Jeff G wrote: > > > no, it fails on disk 2 > > > > It's best if you don't top post. > > > > In your previous message (see below), you got an SHA1SUM off disk 2, so > > I don't see how it could have failed. > > [oops, sorry. I always like reading the answers on top, but if that's > not normal, I'll do it this way] > > The only thing I thought of is some problem with my CD reader/burner. > I did the SHA1 computation on the FILE that I used to burn the CD, not > the CD itself. I guess I'll try the CD itself, if that's possible. > Otherwise, I'll take and ISO image of the CD and compare the resulting > file to the original. What I really meant was for you to do a full sha1sum on ALL of the ISOs you used to burn the media and verify you get the correct signatures. The idea was to ensure the ISOs were clean to start with. Next, check the media you're using. Make sure you get name-brand 700MB media. A lot of the "bargain" media absolutely won't hold 700MB. CDs are written from the center out (like an old LP record, but in reverse), so the edge of the media is the last bit to be used. In bargain media, the material is suspect and out at the edge (where the rotational speed is greatest and flutter can be an issue), issues with suspect material get MASSIVELY amplified. I use TDK media almost exclusively (this is NOT a commercial) and have have very few issues. As another poster mentioned, you may take a look at the CDs themselves on a machine that is running and go to the "/mountpoint/Fedora/RPMS" directory on the CD. Look for any RPMs that are 0 length. You can do that via "find . -size 0" > > > > > > On 1/31/07, Rick Stevens <rstevens@xxxxxxxxxxxxxxx> wrote: > > > > On Wed, 2007-01-31 at 17:59 -0500, Jeff G wrote: > > > > > I did check that and got it right: > > > > > > > > > > Here's what "accuhash" calculated, which is the same as the SHA1 file > > > > > values (and yours) > > > > > > > > > > Disk 1: CC503D99C9D736AF9052904A6AB14931B0850078 > > > > > Disk 2: 3051710E6B2F1D17A14EDE0EBB74761C29CDA954 > > > > > > > > > > Doesn't make it past that. > > > > > > > > It hangs up? Then I'd guess the disk 3 image is hosed. I don't have > > > > the CD images handy (I have the DVD), but my guess is that the suspect > > > > RPM is on disk 3. > > > > > > > > > Since it's doing x.11, I though it might be trying to load incorrect > > > > > fonts based on a bad idea of the hardware? > > > > > > > > No, it's saying the RPM is 0 bytes, which is flat wrong. > > > > > > > > > On 1/31/07, Rick Stevens <rstevens@xxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, 2007-01-31 at 14:57 -0500, Jeff G wrote: > > > > > > > [repost attempt, since last one didn't seem to make it] > > > > > > > > > > > > > > on Dell Desktop PC w (standard) Intel/82865G Video adapter > > > > > > > > > > > > > > Not sure it's due to adapter, but I continually get a failure with new > > > > > > > installation on Dell Desktop when it gets to trying to load > > > > > > > xorg-x11-fonts-misc-7.1-2.noarch.rpm > > > > > > > > > > > > > > it says installating xorg-x11-drivers-7.1-3-i386 (0 bytes) > > > > > > > > > > > > > > [note: it really says 0 bytes] > > > > > > > > > > > > > > x.org x11 driver installation package > > > > > > > > > > > > > > It says package not found either missing or corrupt. > > > > > > > > > > > > > > Anyone have any ideas? > > > > > > > > > > > > That sure as heck smells like a borked disk image. It should be 4785 > > > > > > bytes for the i386 RPM and 4464 bytes for the x86_64 RPM. > > > > > > > > > > > > I'd recommend you double check the ISO image you're using (do the > > > > > > sha1sum on the image) before you reburn it. The SHA1SUMs for the i386 > > > > > > version should be: > > > > > > > > > > > > 834fd761b9c0a5dc550d10d97307dac998103a68 FC-6-i386-rescuecd.iso > > > > > > cc503d99c9d736af9052904a6ab14931b0850078 FC-6-i386-disc1.iso > > > > > > 3051710e6b2f1d17a14ede0ebb74761c29cda954 FC-6-i386-disc2.iso > > > > > > 5357ce21f8766db385b25923216a430b694bca5d FC-6-i386-disc3.iso > > > > > > d6133ab5ccf19431c14fd2ad85bce03c9834ef87 FC-6-i386-disc4.iso > > > > > > 22327af62d6376916e209b0c4934540e14d5664a FC-6-i386-disc5.iso > > > > > > 6722f95b97e5118fa26bafa5b9f622cc7d49530c FC-6-i386-DVD.iso > > > > > > > > > > > > For the x86_64, they should be: > > > > > > > > > > > > 18d0a690db32fd5569b41acf4f1affeb0448d5fe FC-6-x86_64-rescuecd.iso > > > > > > 5c976214a16b206761e37bbe5c98e53494b115ac FC-6-x86_64-disc1.iso > > > > > > e2f8375ba631f449d137a28d6947e493c631f198 FC-6-x86_64-disc2.iso > > > > > > 6c85acf08c7944362ba761cc32d1d26c612f327c FC-6-x86_64-disc3.iso > > > > > > 6290f258630cedb82ca45bcaff6d02a122a002df FC-6-x86_64-disc4.iso > > > > > > 7babc6131eb2ead65ca09b5efc475b7b212b0775 FC-6-x86_64-disc5.iso > > > > > > 38d975b6fa3b49262bc96df4bfd34d335c94ebb6 FC-6-x86_64-disc6.iso > > > > > > 550da315c09d8b58d4c80534ce5263d359e479be FC-6-x86_64-DVD.iso > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > - Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx - > > > > > > - VitalStream, Inc. http://www.vitalstream.com - > > > > > > - - > > > > > > - The world is coming to an end ... SAVE YOUR FILES!!! - > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > -- > > > > > > fedora-list mailing list > > > > > > fedora-list@xxxxxxxxxx > > > > > > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > - Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx - > > > > - VitalStream, Inc. http://www.vitalstream.com - > > > > - - > > > > - "People tell me I look at the dark side. That's not true. I have - > > > > - the heart of a small boy......in a jar right here on my desk." - > > > > - -- Stephen King - > > > > ---------------------------------------------------------------------- > > > > > > > > -- > > > > fedora-list mailing list > > > > fedora-list@xxxxxxxxxx > > > > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > > > > > > > > > ---------------------------------------------------------------------- > > - Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx - > > - VitalStream, Inc. http://www.vitalstream.com - > > - - > > - I.R.S.: We've got what it takes to take what you've got! - > > ---------------------------------------------------------------------- > > > > -- > > fedora-list mailing list > > fedora-list@xxxxxxxxxx > > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > > > ---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx - - VitalStream, Inc. http://www.vitalstream.com - - - - We look for things. Things that make us go! - ---------------------------------------------------------------------- -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
I took your advice and did check the .iso images and all was fine. Then I checked the CDs (also using accuhash on Windows). This time, I got a "data error" on CD 2. I was pretty sure that I had done a "media scan" before install, though. Regardless, I re-burned CD 2, and tried it again. IT WORKED! Oddly, the screen had the same info (0 bytes) just before asking for CD 2, BUT then I noticed it saying something about having to build from source and it went on it's merry way. I am happily using this system to type this message, but I think there is a least one moral to this story -- The installer should say "I/O ERROR" or something similar instead of package not found. I actually DO use TDK disks too, but never knew the burning process could be so faulty without feedback while burning, so I learned now to check my CDs as well. Thank you all.
