Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 470613 - Failed DHCP attempts do not get detected, anaconda spends 5~ minutes trying to download content
Summary: Failed DHCP attempts do not get detected, anaconda spends 5~ minutes trying t...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F10Target
TreeView+ depends on / blocked
 
Reported: 2008-11-07 23:30 UTC by Jesse Keating
Modified: 2013-01-10 03:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-03 11:39:34 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Jesse Keating 2008-11-07 23:30:37 UTC 
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 05:01:25 UTC 
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-21 04:05:11 UTC 
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-30 00:14:41 UTC 
So yum has this patch:

commit 64fd03f4111c250b36342000c5248d871e54b42b
Author: James Antill <james>
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 11:39:34 UTC 
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.