Description of problem: I have set up some private repositories that are not accessible on the Internet, so trying to refresh repomd.xml fails which leads to failure of the whole upgrade process. Yum handles this gracefully, not failing on inaccessible repos. Version-Release number of selected component (if applicable): dnf-0.2.21-1.git050524e.fc18.noarch How reproducible: always Steps to Reproduce: 1. configure some repos that are inaccessible 2. dnf upgrade Actual results: [root@kvolny ~]# dnf upgrade Příprava průběhu aktualizace Řešení závislostí... --> Starting dependency resolution http://(super secret hostname)/client/Fedora18/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: (super secret hostname); Jméno počítače nemá přiřazenu adresu" Zkusí se jiné zrcadlo... Can not read repomd file. [root@kvolny ~]# Expected results: [root@kvolny ~]# yum upgrade Zavedené moduly: auto-update-debuginfo, langpacks adobe-linux-x86_64 | 951 B 00:00:00 http://(super secret hostname)/client/Fedora18/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: (super secret hostname); Jméno počítače nemá přiřazenu adresu" Zkusí se jiné zrcadlo... fedora/18/x86_64/metalink | 32 kB 00:00:00 http://(another secret hostname)/repo/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: (another secret hostname); Jméno počítače nemá přiřazenu adresu" Zkusí se jiné zrcadlo... http://(third secret hostname)/dist-git/fedora/18/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: (third secret hostname); Jméno počítače nemá přiřazenu adresu" Zkusí se jiné zrcadlo... rpmfusion-free-updates | 3.3 kB 00:00:00 rpmfusion-free-updates-debuginfo | 2.7 kB 00:00:00 ... Aktualizováno: kernel-headers.x86_64 0:3.8.2-206.fc18 spherical-cow-kde-theme.noarch 0:18.0.1-1.fc18 systemtap.x86_64 0:2.1-2.fc18 systemtap-client.x86_64 0:2.1-2.fc18 systemtap-devel.x86_64 0:2.1-2.fc18 systemtap-runtime.x86_64 0:2.1-2.fc18 Hotovo! [root@kvolny ~]# Additional info: This may be a duplicate of bug #910088 but that one is about not trying to refresh repos for actions that don't need it if I get it right. This one is about just skipping unavailable repos. ... or at least add an option to skip if not a default behaviour, disabling all the inaccessible repos manually is a PITA
Hi Karel, thanks for the report. This could be a dup of bug 904706, can I please ask you to try with dnf-0.2.22 and tell me if the problem is gone? If not, I'll move this to the rawhide version which is getting librepo integrated and situations like this (some mirrors down) will have to be handled and tested anyway.
no, 0.2.22 does not fix this I've tried to clean metadata to ensure that something has to be downloaded, then added a fake dns record to /etc/hosts for the Adobe repo to simulate the inaccesibility and got: [root@kvolny ~]# rpm -q dnf dnf-0.2.22-1.git97180b8.fc18.noarch [root@kvolny ~]# dnf upgrade Příprava průběhu aktualizace Řešení závislostí... --> Starting dependency resolution http://linuxdownload.adobe.com/linux/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "couldn't connect to host" Zkusí se jiné zrcadlo... Chyba: failure: repodata/repomd.xml from adobe-linux-x86_64: [Errno 256] No more mirrors to try. ... hm, now it comes to my mind that this testcase is not exactly the same as original, because in the original one I still had the old metadata available (not cleaned), but it doesn't matter much, as you cannot download the packages from unavailable repo so it is unusable for solving the dependencies anyways, no matter if you have the old metadata or not; I'd like to see dnf being able to workaround both cases (old/missing metadata)
Yeah, I was afraid this is actually a different issue. Thanks for the detailed reproducer, I'll try to have this fixed once librepo is integrated into DNF.
(In reply to comment #2) > dependencies anyways, no matter if you have the old metadata or not; I'd > like to see dnf being able to workaround both cases (old/missing metadata) Ok, this is the situation: If repo metadata is locally cached and not expired DNF never tries to access the remote repository. By default, if repo metadata is expired and the repo is inaccessible 'yum upgrade' will fail ("No more mirrors to try") just like DNF. In yum there is a per-repo option called 'skip_if_unavailable' that prevents this: the operation will continue as if the repo didn't exist/was disabled. Bug 889202 returns this support to DNF so it should work fine. Also, if you want to use a cached, expired that is momentarily unavailable you can use '--cacheonly' to force using even expired repositories. Closing this as dup 889202, please reopen if that doesn't satisfy you. *** This bug has been marked as a duplicate of bug 889202 ***
thanks for looking into this; now it seems to behave a bit differently (wonder what has changed since the abovementioned update ...), I'll open a new report if something goes wrong