Bug 817419
| Summary: | mediacheck FAIL is ignored by installer, install continues without warning prompt | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andre Robatino <robatino> | ||||||||
| Component: | dracut | Assignee: | Brian Lane <bcl> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 17 | CC: | awilliam, bcl, bruno, bugzilla, dennis, dracut-maint, g.kaviyarasu, jfeeney, jonathan, vanmeeuwen+fedora | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | AcceptedNTH | ||||||||||
| Fixed In Version: | dracut-018-35.git20120510.fc17 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-05-12 16:22:21 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 752653 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Andre Robatino
2012-04-29 22:10:46 UTC
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 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 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. |