Description of problem: In either Install images (using the undocumented "check" boot option) or Live images (using the "Test this media" option under the "Troubleshooting" menu option), if the mediacheck fails, the installer just continues without even a warning prompt. This means that 1) if the mediacheck is fast, one may not even be able to see the FAIL without a camera, and 2) if the mediacheck is slow, one is forced to stare at the screen waiting for the mediacheck to finish in order to see the FAIL. It's already hard enough to convince people to do a mediacheck on slow media without this. See the thread at https://lists.fedoraproject.org/pipermail/devel/2012-April/166555.html . Expected results: Should get a prompt for what to do if mediacheck fails. Additional info: Please reassign to the appropriate component. If separate bugs are needed for Install and Live media, please let me know so I can file 2 bugs.
Goes against anaconda according to: http://fedoraproject.org/wiki/MediaCheck
The mediacheck fail here is due to the firmware having modified the filesystem contents. This is, obviously, unhelpful of the firmware.
(In reply to comment #2) > The mediacheck fail here is due to the firmware having modified the filesystem > contents. This is, obviously, unhelpful of the firmware. My original report was based on a mediacheck failure in a KVM guest attached to a known good ISO file, and is unrelated to Chris Murphy's report. (The failure in a KVM guest happens often, I normally just ignore it and boot again to get a passing mediacheck as it's not reproducible.)
The complaint with this bug is that the user is inadequately informed of verification failure, to the degree verification is useless. The cause of the failure seems like it would be a separate bug.
I deliberately left out the circumstances of the failure in my original report since it's irrelevant to this bug - it doesn't matter what the cause of the FAIL is, just that the installer fails to react appropriately. I'm guessing that the sporadic KVM mediacheck failure is well known, since so many Fedora people use KVM, though I don't have a bug number.
So, we don't have any criteria requiring mediacheck to work, so we can't really make this a release blocker. But it's obviously bad. Can you prioritize it, anaconda team? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is handled by dracut's dmsquash-live module. If checkisomd5 fails it prints "CD check failed!" and exits with a 1, skipping the rest of the live root setup. I *think* dracut catches this and drops to a shell prompt (but cannot confirm for sure, I've never seen a mediacheck failure). What, exactly, are you seeing happen when the check fails?
In my case (EFI booting Live-Desktop with USB), I see a very brief interruption/flash of text which resumes to the graphical boot screen. Then I see the animated Fedora logo. Then I'm at a desktop. If I try again, with rhgb and quiet removed, the mediacheck failure goes by so fast I can't see it. But I did photograph it.
Created attachment 581666 [details] photo of failed media check There's about 3-4 seconds the failure is on-screen, boot process continues.
(In reply to comment #7) > This is handled by dracut's dmsquash-live module. If checkisomd5 fails it > prints "CD check failed!" and exits with a 1, skipping the rest of the live > root setup. I *think* dracut catches this and drops to a shell prompt (but > cannot confirm for sure, I've never seen a mediacheck failure). That's interesting. I tried deliberately corrupting both an Install and a Live image by replacing the last few MiB with zeroes, and it did drop to a shell prompt as you described. But that's NOT what happened in my KVM guest (in which I attached directly to a known good ISO file).
In KVM guests with the 17.TC3 DVDs, I saw 3 more ignored mediacheck failures (1 on i386 and 2 on x86_64). In each case it failed at 4.8%. Chris Murphy's mediacheck on Fedora-17.TC2-x86_64-Live-Desktop.iso also failed at 4.8% (see https://bugzilla.redhat.com/show_bug.cgi?id=817262#c8 ).
Proposing as NTH, this seems like the kind of thing to break a freeze for. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Should mention that although ideally it's okay to go straight to the install in case of a PASS, it does make it much more likely that bugs like this one will go unnoticed. Is it possible to see the PASS somewhere (in a VT, maybe)? If not, what would be an effective way of deliberately corrupting an ISO to see if it's detected? As mentioned above, when I tried corrupting one deliberately, I got a dracut prompt (which is not terribly user-friendly, BTW - how is one supposed to know that was caused by a mediacheck FAIL?) yet in real-life conditions with a known good ISO, the FAIL was ignored.
If the corruption occurs in the initramfs, it's entirely possible boot will fail before media check is initiated, hence dropping to dracut. Perhaps a more reliable way of corruption testing is to corrupt a portion of squashfs.img which is within the ISO.
Created attachment 583360 [details] fail to boot when mediacheck fails
I take it this fix was not in 17.TC4 - I saw the mediacheck FAIL again (at 4.8% as usual) on the 17.TC4 i386 DVD and it continued to graphical anaconda without warning.
dracut-018-33.git20120510.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dracut-018-33.git20120510.fc17
dracut-018-35.git20120510.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dracut-018-35.git20120510.fc17
andre: indeed it wasn't, arrived too late. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Package dracut-018-35.git20120510.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-018-35.git20120510.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-7631/dracut-018-35.git20120510.fc17 then log in and leave karma (feedback).
+1 for NTH
+1 NTH
Accepted as NTH with the above votes. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 583984 [details] screenshot after mediacheck FAIL (mediacheck scrolled up out of view) Seems to work in 17.TC5 - attached is a screenshot after a mediacheck FAIL (at 4.8%, as usual). The mediacheck itself scrolled up out of view. There are two sets of dracut warnings and then a kernel panic. A little ugly but usable.
dracut-018-35.git20120510.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
+1 NTH as this affects installs from media.