Bug 470613

Summary:	Failed DHCP attempts do not get detected, anaconda spends 5~ minutes trying to download content
Product:	[Fedora] Fedora	Reporter:	Jesse Keating <jkeating>
Component:	anaconda	Assignee:	Radek Vykydal <rvykydal>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	10	CC:	anaconda-maint-list, anthonybryan, dcantrell
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-07-03 11:39:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	438944

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.