Bug 195250

Summary:	anaconda hangs when given eth device that gets no dhcp response
Product:	[Fedora] Fedora	Reporter:	Doug Chapman <dchapman>
Component:	anaconda	Assignee:	David Cantrell <dcantrell>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	mgahagan
Target Milestone:	---	Keywords:	Regression, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-06-26 15:14:25 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:	150224

Description Doug Chapman 2006-06-14 16:11:50 UTC

Description of problem:
This was seen on an HP Integrity ia64 server.

During a network based install I selected an eth device that is disconnected. 
Anaconda tries to get an ip address via dhcp and hangs instead of timing out and
allowing the user to select the correct eth device.

Version-Release number of selected component (if applicable):
rawhide-20060614
anaconda-11.1.0.33-1

How reproducible:
100% on this system

Steps to Reproduce:
1. start an nfs install
2. when prompted for the ethernet device choose one that is not connected
3. select DHCP
  
Actual results:
hang


Expected results:
should time out and allow selecting a different device


Additional info:

Comment 1 Doug Chapman 2006-06-19 15:44:25 UTC

I have been experimenting with this on other systems.  I don't hit it 100% of
the time but I do see it elsewhere.

I can reporoduce it every time after a few tries of:

1. start the install
2. when prompted select an eth device that is disconnected
3. select dhcp
4. if the dhcp times out as it should just re-try dhcp

It will usually hang on the first try.  I have not seen it take more than 2
tries to reproduce the hang.

Comment 2 David Cantrell 2006-06-20 18:56:25 UTC

Looks like the IPv6 DHCP request is what fails to timeout.  The IPv4 request
times out after 10 seconds, then it moves to IPv6 and you can see it just loops
over and over (check log on tty3).  Looking at this in libdhcp6client.

For now you can boot with the 'noipv6' boot parameter and that should disable
IPv6 throughout the installation.

Comment 3 David Cantrell 2006-06-22 15:53:59 UTC

I've patched libdhcp6client, which fixes the timeout problem.  Next build in
rawhide will have this fix integrated.

Comment 4 David Cantrell 2006-06-22 17:12:11 UTC

*** Bug 195935 has been marked as a duplicate of this bug. ***

Comment 5 Doug Chapman 2006-06-23 14:22:25 UTC

I still see the hang in rawhide-20060623.  I am going to re-open but put it into
the state "NEEDINFO_REPORTER" so it is on me to re-verify this next week (in
case the fix did not make it in to the 0623 build yet).

Comment 6 Doug Chapman 2006-06-26 15:14:25 UTC

I just verified that this is fixed in rawhide-20060626.  The timeout however
does seem to take a very long time (which might be why I thought it was still
broken last week).  It certainly takes longer than I remember back in RHEL4.  I
will do some comparisons and open a different BZ if it does seem to be a real issue.

Comment 7 David Cantrell 2006-06-29 15:27:58 UTC

The timeout is 45 seconds each for IPv6, per the RFC requirement.