Description of problem: Media checks fail for FC 7 & 8 installation DVDs (both have passed and worked on other boxes). Cannot not install...after media check fails, if I try to install anyway anaconda immediately . Version-Release number of selected component (if applicable): Fedora Core 8 How reproducible: Always Steps to Reproduce: 1. Insert DVD, boot up machine 2. Click OK for media check 3. Media check immediately fails Actual results: Cannot install fedora core 7 or 8 Expected results: To have upgraded from fedora core 5 Additional info: I've included screen shots of the TTY's immediately prior to the media check and screenshots of the TTY's immediately afterwards. System: Athlon XP 3000+ 1 GB of RAM DVD Burner: HL-DT-ST DVD-RAM GSA-H55L (LG lightscribe) Motherboard: Socket A (V600DAB Via KT600)
Created attachment 290562 [details] Screenshot of TTY just before Media Check is performed
Created attachment 290563 [details] Another TTY just before media check
Created attachment 290564 [details] Screenshot of TTY just after Media Check fails
Created attachment 290565 [details] Another TTY just after media check fails
Since I cannot use Fedora Core 7 or 8 because of this, I would actually prioritize this bug as "Urgent" and not "Low"
Wrong component, this should probably be filed either against anaconda or kernel. However, a quick perusal of your screen shots says NOTABUG. Look at the output. It says "Hardware error". Looks to me like that optical drive is bad. Do you have another drive you can swap in place of that drive?
Hmmm...no I don't have another optical drive to swap out. Ironically, I burned the ISOs via this very DVD burner and those DVDs subsequently installed (without any glitch) Fedora Core 8 just fine onto 2 other machines. I don't believe the optical drive is therefore bad....
Hrm, does suggest perhaps the drive is okay. Could be a drive that doesn't get along with DMA and the new-ish libata stack in F7 and F8. http://www.redhat.com/archives/fedora-extras-commits/2007-September/msg02104.html Not sure exactly how to pass that in (if at all possible) to the installer to test that theory though...
Oh yeah, please don't set bugs to MODIFIED, that state is for bugs which have had a fix committed.
Roger that (about the MODIFIED). Any advice would be appreciated. It's frustrating not to be able to upgrade. Here is the information from dmesg relevent to this optical drive in my current fc5 configuration. Not sure if it helps, but aside from suggesting not using a deprecated kernel command line, fc5 doesn't seem to have any hassle with this burner: Kernel command line: ro root=/dev/VolGroup00/LogVol00 3 hdd=ide-scsi ide_setup: hdd=ide-scsi ide1: BM-DMA at 0xac08-0xac0f, BIOS settings: hdc:DMA, hdd:DMA hdd: HL-DT-STDVD-RAM GSA-H55L, ATAPI CD/DVD-ROM drive hdd: DMA disabled ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device scsi2 : SCSI host adapter emulation for IDE ATAPI devices scsi 2:0:0:0: CD-ROM HL-DT-ST DVD-RAM GSA-H55L 1.00 PQ: 0 ANSI: 0 scsi 2:0:0:0: Attached scsi generic sg0 type 5 sr0: scsi-1 drive sr 2:0:0:0: Attached scsi CD-ROM sr0
Relating to your comment #8 above, does that mean if I swap out another DVD drive which DOES get along with DMA and the new-ish libata stack in F7 and F8 and I successfully install F8 and then put my LG back in after F8 is installed, that the new F8 will give me the same hassles? Then we've only moved the problem from installation to post-installation. Does that seem likely (I'm about to borrow a neighbors optical drive to upgrade, but I don't want to do that if my new box won't accept the lightscribe burner after installation)?
Assuming the problem really is the drive not getting along with libata and dma, then yes, it *should* work after installation w/the other drive if you add the appropriate kernel param (libata.dma=0, iirc).
Created attachment 292809 [details] Debugging informatio from K3B
Ok, Jarod, I'm completely confused. I ended up buying a completely different DVD burner (Philips) and everything installed. To verify your comment #12 above, after installation, I reinstalled the old LG. FC8 seemed to have tolerated it...I could read DVDs and CDs from it. But I can't burn with it! K3B kept giving me "write errors" shortly after burning starts (I've included debugging output in comment 13 above). So now it started to seem that maybe my LG was faulty after all. To be sure, I went out and bought the same LG model and guess what...it fails just like the old one! So here is what I did. I booted with the new LG and recorded dmesg. I then booted with the new LG with the boot option you suggested in comment #12 "libata.dma=0" (FC8 didn't like that, but I'm not sure where else to put that line) and recorded dmesg. Finally, I booted with the new Philips (which I verified could burn to DVD) and recorded dmesg. Then I went through all three dmesg's to see where they differed. Here are the differences: (see attachment below) I realize that this has now evolved away from anaconda but could someone please recommend 1) where I should file this bug report 2) any suggestions as to the problem (the Philips can still be returned and I would like to do so and have my light-scribing LG back!)
<table><tr valign="top"><td colspan=3><hr></td> </tr><tr valign="top" align="middle"> <td><b>LG</b></td><td><b>LG + boot param</b></td><td><b>Philips</b></td> </tr><tr valign="top"><td colspan=3><hr style="height: 5px"></td> </tr><tr valign="top"> <td>Kernel command line: ro root=/dev/VolGroup00/LogVol00 3 rhgb</td> <td>Kernel command line: ro root=/dev/VolGroup00/LogVol00 3 rhgb libata.dma=0</td> <td>Kernel command line: ro root=/dev/VolGroup00/LogVol00 3 rhgb</td> </tr><tr valign="top"> <td></td><td>Unknown boot option `libata.dma=0': ignoring</td><td></td> </tr><tr valign="top"><td colspan=3><hr></td> </tr><tr valign="top"> <td>pnp: 00:00: iomem range 0xd0000-0xd3fff has been reserved</td> <td>pnp: 00:00: iomem range 0xd0000-0xd3fff has been reserved</td> <td>pnp: 00:00: iomem range 0xd0000-0xd3fff could not be reserved</td> </tr><tr valign="top"><td colspan=3><hr></td> </tr><tr valign="top"> <td>Using IPI No-Shortcut mode</td> <td>Using IPI No-Shortcut mode</td> <td>Using IPI No-Shortcut mode</td> </tr><tr valign="top"> <td> Magic number: 8:14:88</td> <td> Magic number: 8:667:239</td> <td> Magic number: 8:323:391</td> </tr><tr valign="top"> <td> hash matches device hvc3</td><td></td><td></td> </tr><tr valign="top"><td colspan=3><hr></td> </tr><tr valign="top"> <td>ata2.01: ATAPI: HL-DT-STDVD-RAM GSA-H55L, 1.00, max UDMA/66</td> <td>ata2.01: ATAPI: HL-DT-STDVD-RAM GSA-H55L, 1.00, max UDMA/66</td> <td>ata2.01: ATAPI: PHILIPS SPD2413P, GP03, max UDMA/66</td> </tr><tr valign="top"> <td>ata2.01: configured for UDMA/66</td> <td>ata2.01: configured for UDMA/66</td> <td>ata2.01: configured for UDMA/33</td> </tr><tr valign="top"> <td></td><td></td><td>ata2.01: limited to UDMA/33 due to 40-wire cable</td> </tr><tr valign="top"><td colspan=3><hr></td> </tr><tr valign="top"> <td>scsi 1:0:1:0: CD-ROM HL-DT-ST DVD-RAM GSA-H55L 1.00 PQ: 0 ANSI: 5</td> <td>scsi 1:0:1:0: CD-ROM HL-DT-ST DVD-RAM GSA-H55L 1.00 PQ: 0 ANSI: 5</td> <td>scsi 1:0:1:0: CD-ROM PHILIPS SPD2413P GP03 PQ: 0 ANSI: 5</td> </tr><tr valign="top"><td colspan=3><hr></td> </tr><tr valign="top"> <td>sr 1:0:1:0: Attached scsi generic sg3 type 5</td> <td>scsi 1:0:1:0: Attached scsi generic sg3 type 5</td> <td>sr 1:0:1:0: Attached scsi generic sg3 type 5</td> </tr><tr valign="top"><td colspan=3><hr></td> </tr></table>
Created attachment 292817 [details] Comparing dmesg between three different configurations
If your existing drive was still good, then the problem must lie in the driver somewhere, so this should be reassigned to kernel. They can make the determination on if it's really bad hardware or a bad driver that's at fault here.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.