Bug 193734

  Possibly the mediacheck bug #186512 (yes, it can manifest during installation
even if some or all of the install discs check as good).  Try running the
installer with the ide=nodma option (at the boot prompt, type "linux ide=nodma"
instead of just Enter).  The installer puts any kernel options you run it with
in grub.conf, so if you install successfully and you don't want to use ide=nodma
permanently, take it out.

That can go into the "append" section of the isolinux/isolinux.cfg file, right?

Ok, I'll give it a try.

It's also been suggested that this might be caused by breakage introduced by
Redhat patches to mkisofs...  So I'll try the unadulterated version as well.

mkisofs was only broken for a couple days, so you most likely didn't hit that. 
If you switch to tty2 and run dmesg, do you see any kernel error messages
regarding your optical drive?  Ignore any selinux-related spew there.

I went into isolinux/isolinux.cfg and added "append ... ide=nodma" to the
"kickstart" entry.  I also started using mkisofs (cdrtools-2.01.01a09) at the
same time, and the issue seems to have gone away.

I'll try using the stock mkisofs.

  Assuming it was the mediacheck bug, you might want to look at

http://www.troubleshooters.com/linux/coasterless.htm

  I found that by burning CDs according to the instructions, I was able to avoid
having to use ide=nodma on a drive that previously needed it.  I'm not familiar
with burning DVDs so don't know how applicable the instructions are.

  Actually, look at this instead:

http://www.troubleshooters.com/linux/coasterless_dvd.htm

Can you provide /tmp/anaconda.log and /tmp/syslog from when it fails?

Created attachment 130474 [details]
/tmp/anaconda.log

Created attachment 130475 [details]
/tmp/syslog

Actually, using cdrecord didn't seem to make any difference.

The only things that have were (a) using an unpatched version of mkisofs, and
(b) adding "ide=nodma" to the append line in isolinux.cfg.

  I wasn't recommending that you use cdrecord - in fact, the coasterless_dvd
page (which I didn't know about until just before posting it here) recommends
using growisofs.

(In reply to comment #11)
>   I wasn't recommending that you use cdrecord - in fact, the coasterless_dvd
> page (which I didn't know about until just before posting it here) recommends
> using growisofs.

Tried that.  It doesn't work in FC5:

growisofs -use-the-force-luke=dao -dvd-compat -J -R -Z
/dev/dvdwriter=/home/tmp/FC-5-i386-DVD-tweaked.iso -speed=4
growisofs: no mkisofs options are permitted with =, aborting...

  I just recently tried burning the FC6 DVD ISO to a DVD+RW and found that the
mediacheck bug affects the reading of DVDs also.  To avoid it, one needs to add
padding after the end of the ISO when burning to the DVD (NOT padding inside the
ISO itself, which mkisofs provides by default).  Unfortunately, growisofs
doesn't allow this type of padding - if you pass it the -pad option, it just
passes it through to mkisofs, which isn't what is needed.  Therefore, one must
use cdrecord, like this:

cdrecord -v dev=/dev/dvd -dao -pad padsize=63s driveropts=burnfree FC-6-i386-DVD.iso

I just used the same amount of padding that the linked page recommends for CDs,
which seems to work.  For some reason I didn't need to need the padding when
burning to a DVD+R, but it doesn't hurt to add it anyway.

  I also sent an email recently to the maintainer of the linked pages and he
agreed that he had had problems using growisofs and now just uses cdrecord. 
When I run the command above, there are some ugly-looking warning messages, but
it does work, and the resulting disc passes mediacheck even on a drive
vulnerable to the read-ahead bug.

This is reported in your syslog:

<3>Buffer I/O error on device hdc, logical block 856496
<4>hdc: command error: status=0x51 { DriveReady SeekComplete Error }
<4>hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
<4>ide: failed opcode was: unknown
<4>end_request: I/O error, dev hdc, sector 3425984

This is hardware error of some variety (bad optical drive, bad media, bad cable,
etc) and not an anaconda bug.

  I'm quite sure it's not due to faulty hardware, since my father was able to
immediately do a successful install of FC4 after failing repeatedly with FC5, on
exactly the same hardware (2 different boxes with identical CD drives both
suddenly failing after 7 years with FC5, then both immediately working when
falling back to FC4 - not terribly likely to be simultaneous failures followed
by simultaneous revivals).  The real problem seems to be that the version of the
driver(s) for FC5 has suddenly become either buggy or more sensitive, causing
install failures on FC5 even though they will work reliably using FC4 or older.
 The job of the driver should be to make the best possible use of the hardware,
and in this case it's not happening.