Bug 817419 - mediacheck FAIL is ignored by installer, install continues without warning prompt
mediacheck FAIL is ignored by installer, install continues without warning pr...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
17
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
AcceptedNTH
:
Depends On:
Blocks: F17-accepted/F17FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-04-29 18:10 EDT by Andre Robatino
Modified: 2013-01-10 03:29 EST (History)
10 users (show)

See Also:
Fixed In Version: dracut-018-35.git20120510.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-12 12:22:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Andre Robatino 2012-04-29 18:10:46 EDT
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 18:46:29 EDT
Goes against anaconda according to:
http://fedoraproject.org/wiki/MediaCheck
Comment 2 Matthew Garrett 2012-04-30 11:23:42 EDT
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 16:37:38 EDT
(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 17:03:50 EDT
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 17:17:27 EDT
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 06:19:29 EDT
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 11:06:13 EDT
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 12:42:07 EDT
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 12:44:13 EDT
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 16:17:50 EDT
(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 07:16:34 EDT
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 18:38:31 EDT
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-08 21:46:50 EDT
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-08 22:10:16 EDT
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 14:15:47 EDT
Created attachment 583360 [details]
fail to boot when mediacheck fails
Comment 16 Andre Robatino 2012-05-10 03:33:13 EDT
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 06:08:14 EDT
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 08:54:02 EDT
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 08:54:07 EDT
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 09:34:17 EDT
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 16:41:26 EDT
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-11 22:14:20 EDT
+1 for NTH
Comment 23 Andre Robatino 2012-05-11 22:16:04 EDT
+1 for NTH
Comment 24 John Dulaney 2012-05-11 23:05:37 EDT
+1 NTH
Comment 25 Adam Williamson 2012-05-11 23:39:00 EDT
Accepted as NTH with the above votes.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 26 Andre Robatino 2012-05-12 07:23:41 EDT
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 12:22:21 EDT
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 09:28:09 EDT
+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.