Red Hat Bugzilla – Bug 375011
Can't continue installation after running media check
Last modified: 2013-01-09 23:29:55 EST
Boot a Fedora DVD, select item 1 (install/upgrade existing partition), and run
the media check when given the option. When the media check completes the DVD is
ejected and the user can select "Test" or "Continue". Select continue. The DVD
is reloaded, the DVD drive light flashes for a while and is eventually ejected
once more. The screen shows a dialog box titled "Error" containing the message
"OK" in black, and a button with the text "OK" on it.
The only way to get past this point is to reboot the computer using the DVD, and
when asked about running a media check, select "Skip" to skip the media check.
This problem exists with both the F8 i386 and F8 x86_64 DVD's. I download the
ISO's for the discs off the net. Both DVD ISO images passed the 'sha1sum -c'
test. Each image was burned to a DVD and verified by k3b. I was able to
successfully upgrade the i386 and x86_64 partitions of my computer with the
DVD's as long as I skip the media check.
i did a media check too and once the dvd was ejected i pressed "continue",
a new windows prompt out with only an "Ok" message, i inserted the dvd media,
pressed ok and the installation went on smoothly... i didn't get this kind
of error even if i executed a media check
What is printed on tty3 when the CD is ejected again?
The only message that appears on tty3 is the message:
The message appears about 30 seconds after hitting the "Ok" button on the screen
with the "Ok" message. I hit the "Ok" button three times and the DVD was ejected
Some additional bits of information (in case they may be helpful). I am using a
computer which I have only had for about 6 months. I initially installed Fedora
7 on it. I don't recall having a problem with the media test on F7. However,
that was about 6 months ago and I can't say with absolute certainty that I did
perform the media test. The DVD drive I was using during the install is a
DVD+/-R/W drive. It is identified in dmesg as HL-DT-ST DVDRRW GSA-H30L.
*** Bug 442188 has been marked as a duplicate of this bug. ***
*** Bug 442208 has been marked as a duplicate of this bug. ***
JFTR: Bug 442188 and bug 442208 referred not to F8 like this bug, but to
*** Bug 446265 has been marked as a duplicate of this bug. ***
*** Bug 446301 has been marked as a duplicate of this bug. ***
To work around this, you just need to slow down - wait for the machine to detect
that there's a disc in the drive (watch the flashing light) before you hit OK.
*** Bug 441041 has been marked as a duplicate of this bug. ***
*** Bug 446838 has been marked as a duplicate of this bug. ***
*** Bug 447165 has been marked as a duplicate of this bug. ***
This bug persists in F9, though it's not really a bug. You need to reinsert the
disc and wait for about fifteen seconds for the system to find it again before
hitting continue. A more graceful error message than "Error" would be helpful,
Reopening, as the useless error message IS the bug, and I have not read about a
fix for that yet.
At least the useless error message is what I reported as bug 442188, and that
bug has been classified as a duplicate of this-here bug.
Just for the record, the message in question looks like this:
| OK |
| [OK] |
The user is supposed to read that as "The installer is currently cannot read
from the installation medium. Please wait until the drive has definitely
recognized the medium, which may take a little time." or something along these
That cannot be realistically expected from a majority of users, IMHO.
*** Bug 451785 has been marked as a duplicate of this bug. ***
Stupid error message fixed in Rawhide, though we still need to fix the real
problem here. The real problem is that we're not able to wait for the drive
tray to be pulled back in and the new media to be recognized without some kernel
patching. Peter's working on that.
*** Bug 459056 has been marked as a duplicate of this bug. ***
*** Bug 459342 has been marked as a duplicate of this bug. ***
*** Bug 461876 has been marked as a duplicate of this bug. ***
*** Bug 465257 has been marked as a duplicate of this bug. ***
This has (finally!) been fixed in today's rawhide.
This is good news to hear. I did want to ask if it will be back-patched to F9
(In reply to comment #23)
> This has (finally!) been fixed in today's rawhide.
Has it? I can still reproduce with the latest rawhide here with anaconda-18.104.22.168-1: it keeps asking me for "The Fedora disc" after checking boot.iso successfully.
The situation *has* improved somewhat - loader appears waits for the disc to be sensed by the drive/kernel. But once that happens, it thinks the disc still isn't there.
As before, you can work around this by inserting the media, waiting a bit for the drive to detect it, and *then* hitting "OK" or "Continue".
Tried Fedora 10 Snap2 x86_64 DVD and once I test the DVD it ejects it and then it can't seem to find it again.
I also have a second DVD drive and it looks at /dev/sr1 for a while before it will go on.
I tried this again with Fedora 10 Snap 2 x86_64 and if I put the DVD back in the drive and wait for the light to stop flashing and then select continue then it seems to be okay. Then I just have to wait the min for /dev/sr1.
I tried this on VBox and if I kind of do that same thing, but I have to Select Devices and Mount the DVD image and then select continue. If I select continue without doing that I can't seem to recover without a reboot.
If there isn't an easy way to fix this cleanly then IMHO it would be better just to do a reboot by default after finishing the mediacheck and confirming with the user: the current status quo is just too confusing, or maybe add a message saying "Wait a bit!" or something at least.
So I guess I should say "forget my email about porting to Fedora 9" ...
Given the subsequent emails, I think Jen's (comment #29) is the correct approach. Though I would prefer a "do this cause there is a problem and you need to do such-and-such workaround" rather than a "wait a bit" as that doesn't own up to the issue that is causing the problem.
*** Bug 467566 has been marked as a duplicate of this bug. ***
Aaaargh! You're right, this is still halfway broken.
However, it works just fine if you hit "continue" and let the computer take the disc back in itself. (Wtf.) Peter has said he'll look at the hitting-ok-right-after-reinserting behavior tomorrow.
Why does it have to eject the disk in the first place?
This causes problem on things like vbox.
When you are testing a DVD you only have 1, why eject it?
Why not have an eject button to go along with the test and continue ones?
(In reply to comment #33)
> Why does it have to eject the disk in the first place?
> When you are testing a DVD you only have 1, why eject it?
Very good point.
> Why not have an eject button to go along with the test and continue ones?
I like that idea.
I'd ask the user before the media test - give the user these three buttons to choose from:
* Skip media test
* Test medium and continue installation (if successful)
* Test medium and eject it
On three well-named dialog buttons, that would make things a lot easier.
If the explanation is in the text, the buttons could e.g. be called
"Skip" "Test and continue installation" "Test and eject medium"
That should fit on an 80 column text screen.
I believe this should be fixed up as of 22.214.171.124-1. Peter just committed some fixes for it on Thursday.
No good, at least for the 3 drives / 2 machines I tested.
The test goes like this:
0) Burn and boot rawhide's boot.iso
1) Perform mediacheck
2) When mediacheck completes, hit "OK" to acknowledge success and eject the disc
3) Choose "Continue" to continue installation
4) Drive closes, time passes
5) Disc ejects; "Error: The Fedora disc was not found in any of your drives..."
6) Hit OK. Goto 4
There are no log messages from loader during this loop, even with 'loglevel=debug'. tty5 does say:
Running... /bin/mount -n -t iso9660 -o -ro /dev/sr0 /mnt/stage2
but there's nothing in dmesg, syslog, or anaconda.log.
The only way to break the loop is to insert the disc by hand, wait for the drive/kernel to notice that it's been inserted, and *then* hit OK.
Strangely, if you hit "Test" rather than "Continue" at step 3, it will happily close the drive, wait for it to spin up, and then proceed to test the media, as you would expect.
(In reply to comment #35)
> I believe this should be fixed up as of 126.96.36.199-1.
Not for me either.
(In reply to comment #34)
> "Skip" "Test and continue installation" "Test and eject medium"
"Install" "Test and install" "Test only"
"Install" "Test and install" "Test and ask"
Sure, as long as "ask" does not sit you in an infinite media eject loop. :)
Obviously. And make my suggestion
"Install" "Test and install" "Test and ask again"
> The only way to break the loop is to insert the disc by hand, wait for the
> drive/kernel to notice that it's been inserted, and *then* hit OK.
Okay I finally reproduced that - not sure how long one needs to wait I think I waited over 20s.
*** Bug 470033 has been marked as a duplicate of this bug. ***
Yeah, there is still a loop here, I can't break out of it unless I put the disc in manually.
Still a loop here as well. Here's the /proc/scsi/scsi information about my drives:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: LITE-ON Model: CD-ROM LTN-4891S Rev: NDS3
Type: CD-ROM ANSI SCSI revision: 05
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: TSSTcorp Model: CDRWDVD TS-H492C Rev: DE02
Type: CD-ROM ANSI SCSI revision: 05
The latter is the one I'm using.
Reproduced in anaconda-188.8.131.52 (20081112 Rawhide boot.iso).
Maybe it's just certain balky hardware that's affected anymore? Or maybe having multiple drives changes the outcome?
I'll accept moving this bug off the Blocker list if we can show that it works for *most* people.
Think we finally got this knocked. pjones built a test image that works exactly as expected on my unhappy drives. The fix is in:
Should land in the next anaconda build, which would presumably be anaconda-184.108.40.206-1
Leaving this open until we actually have a fixed package tagged and signed for f10-final.
Assuming this fix holds up as valid and is released into f10, will it be back-patched to f9?
(In reply to comment #50)
> Assuming this fix holds up as valid and is released into f10, will it be
> back-patched to f9?
Err, what for? :) fedoraunity? anaconda is not normally backported, I think.
"Fedoraunity" is the least of my worries. I have multiple machines I need to upgrade from FC5 to F9 and my experience in dealing with thrid-party software is that sometimes a fix only holds for the current release and sometimes it is possible to baclpatch to the prior release, maybe more.
This thread shows that its impacted alot of people and it seems that if it can be backpatched it would make life easier for those who are still working on F9 and not ready to move to F10.
Whether it happens or not is not a critical issue. But asking if it is possible is a legit question in my book.
(In reply to comment #52)
> I have multiple machines I need to upgrade from FC5 to F9
So to make my question more specific: how would you use such a potential anaconda update?
You would have to do a local respin of f9 to make use of it I think.
Ah, light bulb goes off above head !!!
I now understand why this request doesn't make sense, thanks for clarifying (and let's pretend I never asked about a back-patch)
Package built, tag request in. --> MODIFIED
Confirmed in rawhide-20081114 while booting from and verifying boot.iso media.
*** Bug 479543 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
This bug is still present in Fedora 11 install DVD.
Do a media check; reinsert DVD and click on 'ok''; get a message saying the disk is not recognized as the Fedora disk.
(In reply to comment #60)
> This bug is still present in Fedora 11 install DVD.
> Do a media check; reinsert DVD and click on 'ok''; get a message saying the
> disk is not recognized as the Fedora disk.
This is not the same bug at all. Please file a separate report for this problem.
We have not gotten any reports since January, so I'm going to close this bug as FINALLY fixed. Hopefully it will stay that way this time.