Bug 817419 - mediacheck FAIL is ignored by installer, install continues without warning prompt
Summary: mediacheck FAIL is ignored by installer, install continues without warning pr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 17
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedNTH
Depends On:
Blocks: F17-accepted, F17FinalFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2012-04-29 22:10 UTC by Andre Robatino
Modified: 2013-01-10 08:29 UTC (History)
10 users (show)

Fixed In Version: dracut-018-35.git20120510.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-12 16:22:21 UTC
Type: Bug


Attachments (Terms of Use)
photo of failed media check (69.51 KB, image/jpeg)
2012-05-02 16:44 UTC, Chris Murphy
no flags Details
fail to boot when mediacheck fails (931 bytes, patch)
2012-05-09 18:15 UTC, Brian Lane
no flags Details | Diff
screenshot after mediacheck FAIL (mediacheck scrolled up out of view) (15.79 KB, image/png)
2012-05-12 11:23 UTC, Andre Robatino
no flags Details

Description Andre Robatino 2012-04-29 22:10:46 UTC
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.

Comment 1 Chris Murphy 2012-04-29 22:46:29 UTC
Goes against anaconda according to:
http://fedoraproject.org/wiki/MediaCheck

Comment 2 Matthew Garrett 2012-04-30 15:23:42 UTC
The mediacheck fail here is due to the firmware having modified the filesystem contents. This is, obviously, unhelpful of the firmware.

Comment 3 Andre Robatino 2012-04-30 20:37:38 UTC
(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.)

Comment 4 Chris Murphy 2012-04-30 21:03:50 UTC
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.

Comment 5 Andre Robatino 2012-04-30 21:17:27 UTC
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.

Comment 6 Adam Williamson 2012-05-02 10:19:29 UTC
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

Comment 7 Brian Lane 2012-05-02 15:06:13 UTC
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?

Comment 8 Chris Murphy 2012-05-02 16:42:07 UTC
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.

Comment 9 Chris Murphy 2012-05-02 16:44:13 UTC
Created attachment 581666 [details]
photo of failed media check

There's about 3-4 seconds the failure is on-screen, boot process continues.

Comment 10 Andre Robatino 2012-05-02 20:17:50 UTC
(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).

Comment 11 Andre Robatino 2012-05-05 11:16:34 UTC
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 ).

Comment 12 Adam Williamson 2012-05-08 22:38:31 UTC
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

Comment 13 Andre Robatino 2012-05-09 01:46:50 UTC
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.

Comment 14 Chris Murphy 2012-05-09 02:10:16 UTC
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.

Comment 15 Brian Lane 2012-05-09 18:15:47 UTC
Created attachment 583360 [details]
fail to boot when mediacheck fails

Comment 16 Andre Robatino 2012-05-10 07:33:13 UTC
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.

Comment 17 Fedora Update System 2012-05-10 10:08:14 UTC
dracut-018-33.git20120510.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dracut-018-33.git20120510.fc17

Comment 18 Fedora Update System 2012-05-10 12:54:02 UTC
dracut-018-35.git20120510.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dracut-018-35.git20120510.fc17

Comment 19 Fedora Update System 2012-05-10 12:54:07 UTC
dracut-018-35.git20120510.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dracut-018-35.git20120510.fc17

Comment 20 Adam Williamson 2012-05-10 13:34:17 UTC
andre: indeed it wasn't, arrived too late.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 21 Fedora Update System 2012-05-10 20:41:26 UTC
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).

Comment 22 Dennis Gilmore 2012-05-12 02:14:20 UTC
+1 for NTH

Comment 23 Andre Robatino 2012-05-12 02:16:04 UTC
+1 for NTH

Comment 24 John Dulaney 2012-05-12 03:05:37 UTC
+1 NTH

Comment 25 Adam Williamson 2012-05-12 03:39:00 UTC
Accepted as NTH with the above votes.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 26 Andre Robatino 2012-05-12 11:23:41 UTC
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.

Comment 27 Fedora Update System 2012-05-12 16:22:21 UTC
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.

Comment 28 Bruno Wolff III 2012-05-13 13:28:09 UTC
+1 NTH as this affects installs from media.


Note You need to log in before you can comment on or make changes to this bug.