Description of problem: when doing "dnf upgrade", dnf tries only the first mirror and if it gets 404 HTTP error, upgrade can stall for up to 12 hours, or whenever mirror is synced. Fedora 21 - x86_64 - Updates - Debug 0% [ ] --- B/s | 0 B --:-- ETA 404 error for http://www.nic.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/21/x86_64/debug/repodata/a50717db310063c8d106c566548b5876743ffd89b39eb9bc794295a8b6c42f08-filelists.xml.gz Version-Release number of selected component (if applicable): How reproducible: every couple of days Steps to Reproduce: 1. dnf upgrade 2. 3. Actual results: upgrade stalls Expected results: dnf could try some other mirror. that's why there is more than one mirror. Additional info:
0.6.4-5.fc21
Not sure if this bug is related to https://bugzilla.redhat.com/show_bug.cgi?id=1219283 and also see https://lists.fedoraproject.org/pipermail/devel/2015-May/210424.html
Hi Sami, which version of librepo and curl do you have installed? $ rpm -q librepo curl
librepo-1.7.13-1.fc21.x86_64 curl-7.41.0-1.fc21.x86_64 now upgraded to curl-7.42.1-1.fc21.x86_64
Hi, do you have set `timeout` option in `/etc/dnf/dnf.conf`? How fast is your internet connection? Can you reproduce it again? Can you attach the output of `export LIBREPO_DEBUG=1 && dnf upgrade` [1], please? [1] https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#connection-issue
no timeout option, 50-80 Mbit/s, I can't reproduce it right now because "dnf upgrade" does not trigger requests to mirrors, and also 404 error would be required.
lr_download: Target: repodata/7797977bd4a47e6e874749a98c34a1f0140d0fecd822e022374d72b052eb11ba-filelists.xml.gz (-) select_next_target: Selecting mirror for: repodata/1cb3e47444a8a23d1936137d244acc8a30ad19ad9cf1c96ccfdfc26134d661a6-primary.xml.gz prepare_next_transfer: URL: ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/22/x86_64/debug/repodata/1cb3e47444a8a23d1936137d244acc8a30ad19ad9cf1c96ccfdfc26134d661a6-primary.xml.gz select_next_target: Selecting mirror for: repodata/7797977bd4a47e6e874749a98c34a1f0140d0fecd822e022374d72b052eb11ba-filelists.xml.gz prepare_next_transfer: URL: ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/22/x86_64/debug/repodata/7797977bd4a47e6e874749a98c34a1f0140d0fecd822e022374d72b052eb11ba-filelists.xml.gz lr_download: Downloading started ^Clr_perform: select() interrupted by signal 0% [ ] --- B/s | 0 B --:-- ETAA proxy (squid 3.5.4) gets 550 Can't open /pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/22/x86_64/debug/repodata/7797977bd4a47e6e874749a98c34a1f0140d0fecd822e022374d72b052eb11ba-filelists.xml.gz: No such file or directory but doesn't report error to client (dnf). mirror list could be updated to use http instead of ftp, it could as well use http://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/22/x86_64/debug/repodata/7797977bd4a47e6e874749a98c34a1f0140d0fecd822e022374d72b052eb11ba-filelists.xml.gz
I have the same problem. The only workaround i've found is to use yum-deprecated command.
(In reply to Matteo from comment #8) > I have the same problem. > The only workaround i've found is to use yum-deprecated command. I Forgot to say that i'm on fedora 22
Hi Matteo, this is almost same problem as 1219817. This is happening, because librepo consider curl's return code CURLE_RECV_ERROR as a fatal failure and don't try another mirror. This is fixed in librepo-1.7.16-1.fc22 which is already in testing and will be pushed into stable soon. Could you please try the build and let me know if it helps? https://admin.fedoraproject.org/updates/FEDORA-2015-9077/librepo-1.7.16-1.fc22
Hi Tomas, I updated librepo from testing repos and get dnf working now. I can't do an update because i just did one, but apper works perfectly (before some package like firefox was just not found by apper du to the fatal) and when i ask for update it call to check if i need update and no error occurred so i think the fix is good. Thanks for the quick and effective answer.
Matteo, great to hear that! Thank you for confirmation!
So, I think that we can mark this as a duplicate. *** This bug has been marked as a duplicate of bug 1219817 ***