Bug 1268364 - Anaconda network install blocked by broken mirror
Summary: Anaconda network install blocked by broken mirror
Keywords:
Status: CLOSED DUPLICATE of bug 1212320
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-02 16:45 UTC by Haakon Riiser
Modified: 2015-10-21 13:08 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-10-21 13:08:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dnf.log with timeout errors (125.53 KB, application/x-gzip)
2015-10-18 10:43 UTC, Haakon Riiser
no flags Details
dnf.librepo.log with timeout errors (332.68 KB, application/x-gzip)
2015-10-18 10:44 UTC, Haakon Riiser
no flags Details

Description Haakon Riiser 2015-10-02 16:45:13 UTC
Description of problem:
When installing Fedora with a netinst image, Fedora automatically picks http://ftp.uninett.no as my source. This server is currently broken - it answers ping and ftp, but all http packets seem to be dropped. The result is that the installer never gets started, because the "Installation source" and "Software selection" buttons are greyed out.

Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:
1. Set up a mirror that has lower ping than all other mirrors
2. Make the firewall drop all http packets to that mirror
3. Run netinst

Actual results:
Installation can never begin, because it's waiting forever for a reply from the non-responsive server it decided to use as the source.

Expected results:
Switch to a different server when the one with the lowest ping doesn't reply within a reasonable time.

Additional info:
This also breaks DNF the same way, and I had to override the timeout value to make DNF usable. The manual says that the default DNF timeout is 30 seconds, but it hangs _far_ longer than 30 seconds. Changed it to 2 seconds, and it works fine. Maybe a more sane timeout would solve the problem in Anaconda as well.

Comment 1 Haakon Riiser 2015-10-02 20:53:55 UTC
If I wait a while (several minutes), it _finally_ moves to the next step, but it does not help. Fedora's network installer insists on using this broken mirror, so it can't even download a single package.

Btw, I don't know if netinst uses ping to determine the closest mirror, it was just an assumption on my part.

Comment 2 Brian Lane 2015-10-03 00:17:16 UTC
Sounds like a dnf issue.

Comment 3 Haakon Riiser 2015-10-03 09:35:38 UTC
Turns out I could also fix dnf by setting fastestmirror=true. I thought this was the default already. I have no idea why dnf insists on using the broken mirror http://ftp.uninett.no, unless it's based on some kind of IP geolocation scheme. Anyway, it's not ideal that the netinst installer can be blocked indefinitely by a single broken mirror.

Comment 4 Brian Lane 2015-10-05 18:05:45 UTC
(In reply to Haakon Riiser from comment #3)
> Turns out I could also fix dnf by setting fastestmirror=true. I thought this
> was the default already. I have no idea why dnf insists on using the broken
> mirror http://ftp.uninett.no, unless it's based on some kind of IP
> geolocation scheme. Anyway, it's not ideal that the netinst installer can be
> blocked indefinitely by a single broken mirror.

Anaconda expects the mirror manager to present the best list to you. Setting fastestmirror is only a work around for this, not an actual solution. DNF should detect that it is failing and move to the next entry in the list.

Comment 5 Michal Luscon 2015-10-13 13:53:11 UTC
Please attach installation logs (dnf.log, dnf.librepo.log) and dnf version.

Comment 6 Haakon Riiser 2015-10-18 10:43:25 UTC
Created attachment 1084108 [details]
dnf.log with timeout errors

Comment 7 Haakon Riiser 2015-10-18 10:44:08 UTC
Created attachment 1084109 [details]
dnf.librepo.log with timeout errors

Comment 8 Michal Luscon 2015-10-21 13:08:18 UTC
Are you sure that those logs were produced during the installation by anaconda? 

Anyway, it looks like that the installation medium contains dnf-1.0.0 which lacks the fix for #1212320.

*** This bug has been marked as a duplicate of bug 1212320 ***


Note You need to log in before you can comment on or make changes to this bug.