Description of problem: After performing a disk check on the Fedora installation disk using the installer's console utility fedora keeps telling me: "The fedora disk was not found in any of your cdrom drives" even though the disk check succeeded and I left the same disk in the drive. Version-Release number of selected component (if applicable): Fedora-10-x86_64-DVD.iso f1e5ae7db6a1ba227de7294c4112385922388648 sha1sum I've also noticed this problem with earlier Fedora versions and on different machines. How reproducible: Always. Steps to Reproduce: 1. insert the install disk into the cd/dvd drive 2. reboot computer 3. boot from the dvd 4. select "OK" and "Test" to test the media 5. select "OK" to accept the successful verification of the media 6. select "Skip" because there are no more disks left Actual results: The console application displays a message box saying: "The fedora disk was not found in any of your cdrom drives" Selecting the "OK" button on this message box results in the same message appearing after a bit of disk spinning. Expected results: The installation should continue past the console interface into the GUI part. Additional info: The CD/DVD drive in the latest machine which exhibited this bug is show as "HL-DT-ST DVD-RAM GSA-H55L 1.00 PQ: 0 ANSI: 5" in dmesg. Its brand is LG. (I'm just guessing that this is an anaconda bug. I don't know what the console application/component is called). I was just able to re-produce this problem inside qemu with the DVD's image.
Is this still happening with rawhide?
How can I check that? Where can I get a rawhide CD/DVD iso? Can't you check that yourself? I mentioned that I was able to reproduce this with qemu, so the problem shouldn't be related to my hardware.
We have tested it ourselves, and it works perfectly fine for us (see Bug 375011 if you want the long, tortured history of this bug). It works fine for us in F10 too, so I wouldn't trust our hardware to give us the true story. You can get a rawhide boot.iso from one of the public mirrors: http://mirrors.fedoraproject.org/publiclist
I was able to to reproduce this problem with a boot.iso from http://fedora.mirror.iweb.ca/development/x86_64/os/images/boot.iso: $ sha1sum boot.iso 9c1b6924f95d32d910a7b12c94332f6886cfa02c boot.iso $ qemu-system-x86_64 -m 300 -cdrom boot.iso -boot d Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory I'm going to attach some screenshots to illustrate what I saw. I tried pressing "OK" at various time intervals without success. By the way, I'm running the following version of Qemu: qemu.x86_64 0.9.1-6.fc9
Created attachment 328821 [details] install disk boot menu
Created attachment 328822 [details] install booting messages
Created attachment 328823 [details] media test option At this screen I pressed Enter to activate the "OK" button.
Created attachment 328824 [details] media test confirmation At this screen I pressed Enter to activate the "Test" button.
Created attachment 328825 [details] media check in progress This screen just shows that the media was being tested.
Created attachment 328826 [details] successfully verification dialog At this screen I pressed Enter to activate the "OK" button.
Created attachment 328827 [details] additional media dialog At this screen I pressed the right arrow to select the "Continue" button. Then I pressed Enter to activate that button.
Created attachment 328828 [details] error message After pressing the "Continue" button and waiting a few seconds I received this message. Before pressing Enter to activate the "OK" button I checked the other virtual consoles for messages.
Created attachment 328829 [details] tty3 content after the first occurance of the disc not found error
Created attachment 328830 [details] tty4 content after the first occurance of the disc not found error
I should mention that subsequent presses of the "OK" button on new copies of the error message window resulted in the last line on tt3 ("ejecting /dev/sr0") being repeated.
*** This bug has been marked as a duplicate of bug 375011 ***
This isn't fixed yet.
No, it is not, but it's a duplicate of the earlier bug. *** This bug has been marked as a duplicate of bug 375011 ***