Hide Forgot
When performing a netinstall, it's quite common for individual mirrors to have problems, causing Anaconda to show errors like this: 11:36:38,406 WARN anaconda: Try 1/10 for http://download.fedoraproject.org/pub/f edora/linux/releases/test/15-Beta/Fedora/x86_64/os/Packages/coreutils-8.10-2.fc1 5.x86_64.rpm failed: [Errno 14] HTTP Error 403 - Forbidden : http://mirror.seas. harvard.edu/fedora/linux/releases/test/15-Beta/Fedora/x86_64/os/Packages/coreuti ls-8.10-2.fc15.x86_64.rpm 11:36:38,656 WARN anaconda: Failed to get http://download.fedoraproject.org/pub/ fedora/linux/releases/test/15-Beta/Fedora/x86_64/os/Packages/coreutils-8.10-2.fc 15.x86_64.rpm from mirror 1/1, or downloaded file is corrupt Clicking the "Retry" button causes Anaconda to try a different mirror and succeed, but then it fails again on the next file. Unfortunately, it's not particularly convenient to click "Retry" hundreds of times in a row (once for each package). With a headless machine installing with kickstart, the problem makes the installation completely fail. If Anaconda were to automatically retry three times before giving the error, then it would be possible to complete an install without having to wait for the mirror to get fixed.
Common? It never happened to me, so it's hard to reproduce. Can you please attach a screenshot of the retry dialog? And also the list of repos you have set up? Or are you using just the default ones?
This was very common for me when I used default repos. It's hard to quantify exactly, but my guess is about 1 in 5 installs. I think it just depends on which mirror you happen to get. Recently I've gone to great effort to set up a local mirror to work around the problem (and to speed things up in general). Is there any particular information that the retry dialog gives beyond the "Try 1/10 for ..." message in the logs? Reproducing the retry dialog and making a screenshot wouldn't be hard, but I won't be able to do it until after the weekend. What I plan to do is to pick an RPM at random, chmod it so that it's unreadable, and do an install in a VM.
The thing is that there are more points where the download can fail, and they are sort of being handled by yum. So it would help me to see the exact error dialog, so I can pinpoint which particular download problem you're experiencing.
I've also experienced similar problem. Automated retries would be useful mainly for automated kickstart installations where this download failure stops the installation. Anaconda then waits for user to hit "Retry" which is annoying when you are trying to automate the process completely.
I've finally gotten back to look at this, and it looks like something has changed between Fedora 15 and Fedora 16, as I'm no longer able to reproduce the problem. I just chmodded all of the RPMs on my local mirror to 600, and the logs show only a single "forbidden" error for each repo, but the installation continues to proceed. Presumably, it's going on to the next mirror without requiring me to hit a "Retry" button. This is really great. Trying to reproduce for other types of errors would be much more invasive, but at least one of the most common errors ("forbidden") doesn't look like it will affect me anymore. Richard, have you experienced this in Fedora 16. If so, do you have any more information you could provide for Martin?
I'm hitting this on F15 -> Log snippet: WARN anaconda: Try 1/10 for (url here) failed [Errno 12] Timeout (url here): (28, '') WARN anaconda: Failed to get (url here) from mirror 1/1, or downloaded file is corrupt. Is this is enough to solve the issue?
Reproducible on Fedora 17: Log snippet: WARN anaconda: Try 1/10 for (url here) failed [Errno 14] HTTP Error 503 - Service Unavailable: (url here) WARN anaconda: Failed to get (url here) from mirror 1/1, or downloaded file is corrupt. Hitting "Retry" will download the package and installation continues. Moving bug to Fedora 17 not to be closed for Fedora 15. # anaconda --version anaconda 17.29
I also experince this with F16 when trying to install virtual machine: $ virt-install --name F16_nightly_run --ram 1300 --connect qemu:///system --location http://download.fedoraproject.org/pub/fedora/linux/releases/16/Fedora/x86_64/os/ --disk path=/dev/mapper/vg-f16_vm,cache=none --initrd-inject=./custom-ks.cfg --extra-args ks=file:/custom-ks.cfg --noautoconsole --os-type=linux --os-variant=fedora16 --graphics type=vnc --quiet
Created attachment 593421 [details] Requested screenshot
I have a fix for this in F17, but the whole yuminstall.py with it's error message windows has been rewritten ffor F18, so this is something to think about in anacondas new ui too.
I get this all the time when using virt-install (similar to the usage in comment # 8 as well. It's really frustrating because I'm trying to do an unattended install (F17 in my case). Is there an option that you can set in the kickstart to force anaconda to retry in this situation? When I hit retry it seems to work and keep moving on but I encounter it multiple times on each run.
Me too, unattended net installs are basically impossible. Every couple minutes I have to get up, check the console and kick it along again. Very annoying.
This is worse in Fedora 18: if a package download fails, the installer throws a fatal error without offering a retry button. The workaround is to use --mirrorlist in your repo settings instead of --baseurl and list your internal repo in different ways. For example in my list I have the server address, a cname for the same address and the IP address: http://reposerver.our.net/fedora/18/Everything/x86_64/ http://cname_for_reposerver.our.net/fedora/18/Everything/x86_64/ http://ip_address_of_reposerver/fedora/18/Everything/x86_64/ -- Ian
Ian, what an evil workaround. :)
yum and curl should be retrying downloads,
Brian, does that mean that there has been a fix to make them retry or that it "should" have been working all along? :)
This is still an issue several years after the initial request. Can we not just expose a kickstart option to set download retries?
+1 Ryan Bowlby's comment. I have a client situation where the switch doesn't light up the port for a certain time but the machine thinks it's statically set network is good. The install fails on loading the initial image. This could be easily fixed by adding a retry limit in kickstarts/anaconda.
Created attachment 788158 [details] F19 install screenshot
(In reply to Brian C. Lane from comment #15) > yum and curl should be retrying downloads, Perhaps it should, but it doesn't. Just lost my one shot at installing a remote system that doesn't want to netboot so I placed vmlinuz + initrd on an old install only to have Anaconda decided it didn't feel like trying. Re-opening.
This should be fixed by 4ded6a03229e2e34902b33ffaaa7a4d04fddd11b on master.