Red Hat Bugzilla – Bug 972561
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.
Last modified: 2013-06-10 23:24:20 EDT
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.
It's not a blocker unless it affects minimal, GNOME, or KDE.
well, hum, depending on the circumstances, it could possibly qualify under the 'no broken packages' criterion. but we'd need rather more data.
Created attachment 759076 [details]
minimal install failure screenshot
VM specs: 8 CPUs (from AMD8350)
GPU memory: 8GB
CPU memory: 512GB
Fails on MATE AND Minimal installs. See screenshot.
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.
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.
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"
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.
(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.
andre: hm, that's a reasonable idea; could you submit it as an RFE?
(In reply to Adam Williamson from comment #10)
> andre: hm, that's a reasonable idea; could you submit it as an RFE?