This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 470613 - Failed DHCP attempts do not get detected, anaconda spends 5~ minutes trying to download content
Failed DHCP attempts do not get detected, anaconda spends 5~ minutes trying t...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2008-11-07 18:30 EST by Jesse Keating
Modified: 2013-01-09 22:25 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-03 07:39:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jesse Keating 2008-11-07 18:30:37 EST
When I've got multiple devices or just a device with the cable unplugged and try to do an install via a network repo (boot with boot.iso, use repo=http://), at the software screen dhcp will be attempted on a device, and then anaconda will try to download content over and over again for a long period of time before finally giving up as a bad network connection and allowing me to try again.  We should fail earlier.
Comment 1 Bug Zapper 2008-11-26 00:01:25 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 David Cantrell 2009-02-20 23:05:11 EST
Looks like this was happening because the repo definition files that we provide for yum during installation are no longer using baseurl or mirrorlist, but metalink instead.  Our needsNetwork() function was returning False because it never checked metalink.

Patch:

diff --git a/yuminstall.py b/yuminstall.py
index f8aae0d..d965396 100644
--- a/yuminstall.py
+++ b/yuminstall.py
@@ -244,6 +244,8 @@ class AnacondaYumRepo(YumRepository):
             return len(filter(lambda s: _isURL(s), self.baseurl)) > 0
         elif self.mirrorlist:
             return _isURL(self.mirrorlist)
+        elif self.metalink:
+            return _isURL(self.metalink)
         else:
             return False
 

Sending the patch to the mob for review.
Comment 3 David Cantrell 2009-05-29 20:14:41 EDT
So yum has this patch:

commit 64fd03f4111c250b36342000c5248d871e54b42b
Author: James Antill <james@and.org>
Date:   Mon Mar 2 17:41:34 2009 -0500

    Add hack for mirrorlist to treat as metalink, for anaconda

Which looks like it addresses this problem, but on the yum side.  So I'm wondering if this bug is still valid or not.
Comment 4 Radek Vykydal 2009-07-03 07:39:34 EDT
With repo=http://... on boot line there is just this repo checked with needsNetwork with return value True (baseurl check succeeds) so it seems the bug is not related to issues in comment #2 and #3.

What I observed (F10) is that when we try to enable network in reposetup, anaconda.intf.enableNetwork(anaconda) returns True because NetworkConfigurator dialog _always_ reports success for DHCP - see iw/netconfig_dialog.py:212 in F10), therefore we don't end with error message right here, but doRepoSetup() is called which tries to download metadata - 10 times failing - and then comes another network configuration dialog.

This is fixed in F11 - NetworkConfigurator fails as supposed with error message (fixed by commit 5b96a97a87a633ffb495989ca073430db58600b9), so I close the bug.

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