Bug 972561

Summary: Anaconda fails find to a dependent package and crashes with Errno 256: "No more mirrors to try" on TC-2 DVD install. MATE and minimal tested so far.
Product: [Fedora] Fedora Reporter: Dan Mashal <dan.mashal>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: anaconda-maint-list, awilliam, dan.mashal, dshea, g.kaviyarasu, jonathan, mkolman, robatino, sbueno, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-11 00:28:32 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:
Attachments:
Description Flags
screenshot of crash
none
minimal install failure screenshot none

Description Dan Mashal 2013-06-10 04:45:11 UTC
Created attachment 759032 [details]
screenshot of crash

Don't know if other DE's experience this but this fails under the criterion of being able to complete an installation successfully. See attached screenshot.

Comment 1 Adam Williamson 2013-06-10 07:22:49 UTC
It's not a blocker unless it affects minimal, GNOME, or KDE.

Comment 2 Adam Williamson 2013-06-10 07:24:08 UTC
well, hum, depending on the circumstances, it could possibly qualify under the 'no broken packages' criterion. but we'd need rather more data.

Comment 3 Dan Mashal 2013-06-10 07:32:56 UTC
Created attachment 759076 [details]
minimal install failure screenshot

Comment 4 Dan Mashal 2013-06-10 07:34:46 UTC
Okay environment:

Virtualizer: VBOX
VM specs: 8 CPUs (from AMD8350)
GPU memory: 8GB
CPU memory: 512GB
HDD: 40GB
partitioning: automatic
Networking: bridged

Fails on MATE AND Minimal installs. See screenshot.

Thank you.

Comment 5 Adam Williamson 2013-06-10 07:56:44 UTC
I can't reproduce this here at all. DVD install of MATE in a VM with 512MB of RAM succeeds (and with 2048MB). Could be a bad image.

Comment 6 Adam Williamson 2013-06-10 16:41:01 UTC
Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . We agreed this is an interesting issue but others cannot reproduce it (kparal also tried and failed to reproduce) and there is not sufficient data yet to debug it, so the decision is delayed.

Dan, can you please attach all logs from a reproduction of this issue? That would help to figure out what's going on.

We note that the path "Packages/f/" is clearly a part of the DVD package tree, but "No more mirrors to try" is an error you'd expect from a mirrorlist remote repo, which is interesting. We theorize this may have something to do with doing a DVD install with extra packages from updates-testing. Logs would help check that.

Comment 7 Dan Mashal 2013-06-10 20:29:56 UTC
The image was incomplete and failed the sha256 check.

Will test again. I would suggest adding some kind of sanity check within anaconda that doesn't require "testing the installation media"

Comment 8 Adam Williamson 2013-06-11 00:28:20 UTC
Testing the media *is* the sanity check. We could try and predict every possible way in which the media could possibly be corrupted and all the ways that could possibly cause anaconda to have issues and test for every single one of those, which would be several years and millions of lines of code of effort, or we could just test the media aren't corrupted. Option b) seems simpler.

Comment 9 Andre Robatino 2013-06-11 00:37:31 UTC
(In reply to Dan Mashal from comment #7)
> The image was incomplete and failed the sha256 check.
> 
> Will test again. I would suggest adding some kind of sanity check within
> anaconda that doesn't require "testing the installation media"

A size check - comparing the actual size to that indicated by the ISO header - would be quick if you're booting from an ISO file. I believe VirtualBox does that - if you try to boot from a sufficiently truncated file, it refuses. If you're booting from burned media such as a thumb drive or optical disk, I'm guessing it has to read the whole media anyway. Maybe if the mediacheck does this and finds the image too small, it could specifically state that, in addition to the generic FAIL message. (Note that you'd still have to run the mediacheck to catch this - it would just give a better error message.)

BTW, I believe truncation is by far the most common cause of bad downloads. Command-line tools such as wget and curl are far more robust than a browser for downloading and you rarely get a truncated file with those, and even if you do you can see the errors in the output.

Comment 10 Adam Williamson 2013-06-11 02:00:04 UTC
andre: hm, that's a reasonable idea; could you submit it as an RFE?

Comment 11 Andre Robatino 2013-06-11 03:24:20 UTC
(In reply to Adam Williamson from comment #10)
> andre: hm, that's a reasonable idea; could you submit it as an RFE?

https://bugzilla.redhat.com/show_bug.cgi?id=972995