Bug 920271
| Summary: | [repos] dnf upgrade fails completely if any repo is unavailable | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Karel Volný <kvolny> |
| Component: | dnf | Assignee: | Ales Kozumplik <akozumpl> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | akozumpl, jzeleny |
| 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-04-02 15:17:06 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: | |||
|
Description
Karel Volný
2013-03-11 16:35:06 UTC
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 |