Bug 1236291
| Summary: | dnf often fails to work in constrained network environments with metalink | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> | ||||||||
| Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> | ||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 23 | CC: | antoine, jsilhan, mluscon, mrmazda, packaging-team-maint, pbrobinson, pnemade, rholy, tim.lauridsen, vmukhame | ||||||||
| 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: | 2015-07-29 12:05:02 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: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Peter Robinson
2015-06-27 11:35:16 UTC
Pasted from bug 1219283: (In reply to philip ross from comment #24) > (In reply to Peter Robinson from comment #19) > > Actually I'm still seeing it, and we have enough resilience in our > > servers/mirrors that it shouldn't fail with the loss of a single server. I'm > > also seeing it on some devices but not others. > > If the underlying cause of the problem is because DNF cannot download files > from some hosts when it uses extended passive mode (epsv), is that a bug in > DNF? In the uk when DNF tries to download repomd.xml from > ftp://ftp.mirrorservice.org it fails when it tries to switch the ftp > transfer into epsv mode. > > When this happens, the host is alive and I can download the file manually in > curl by specifying the -disable-epsv flag. > > In my mind, this should be classified as a bug in DNF because it is new > behaviour compared to YUM in Fedora 21 and there appears to be no > configuration or option to tell DNF to not consider epsv mode. The -4 option > to DNF doesn't seem to help, but one possibility would be to have DNF > disable epsv mode when the -4 option is present, as my understanding is that > epsv only difference to pasv is support for ipv6. (In reply to Peter Robinson from comment #26) > > The problem with the EPSV mode is a duplicate of the bug 1220269 which is a > > duplicate of the bug 1219817 which should be fixed by librepo-1.7.16-1.fc22. > > Is this your case, Peter? > > Nope, I have 12 Fedora machines running ARM, 8 of them don't have an issue. > They're also running on a dual stack IPv4/IPv6 native routed (not via a > tunneling network) so there's means of them getting out completely without > NAT. Peter, can you please run again `dnf update --refresh`, attach `/var/log/dnf.librepo.log` and post output of `rpm -q dnf librepo`? With the following versions: dnf-1.0.0-1.fc22.noarch librepo-1.7.16-1.fc22.aarch64 hawkey-0.5.7-1.fc22.aarch64 still get the timeout Curl error (28): Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=fedora-22&arch=aarch64 [Connection timed out after 120001 milliseconds] Sorry, it seems I forgot to post that update. I'll collect the output of the above logs the next time I'm on the platform.
> Peter, can you please run again `dnf update --refresh`, attach
> `/var/log/dnf.librepo.log` and post output of `rpm -q dnf librepo`?
When running a "dnf update --refresh" I don't get a dnf.librepo.log. I get a dnf.log dnf.rpm.log and hawkey.log
Created attachment 1044416 [details]
dnf.log
Created attachment 1044417 [details]
dnf.rpm.log
Created attachment 1044418 [details]
hawkey.log
Thanks. The dnf.librepo.log is the only one I need - it's generated in dnf-1.0.1. The content of it could be parsed from stdout while setting LIBREPO_DEBUG=1 [1]. Can you also try `dnf update dnf --refresh --setopt=minrate=1000`? [1] https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#connection-issue This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 Closing, we are not able to decect the problem without requested data. Feel free to attach them additionally and reopen. Might the DNF timeouts I describe in https://lists.fedoraproject.org/pipermail/devel/2015-August/213852.html be appropriate to follow-up with info needed to continue this? Clean needinfo |