Bug 213270 - install hangs using eth1 with dhcp
install hangs using eth1 with dhcp
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-10-31 10:35 EST by John Poelstra
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-01 17:09:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Poelstra 2006-10-31 10:35:32 EST
+++ This bug was initially created as a clone of Bug #213262 +++

Description of problem:

Attempting to install FC6 GOLD on an IBM Thinkpad T41 doing an NFS install and DHCP.

Internal wireless card automatically gets assigned eth0 so I selected eth1
(unselected ipv6) and dhcp.  Notebook completely hangs trying to get an address.
 Assigning static address works fine (ethernet card is known to be good). 

Version-Release number of selected component (if applicable):
libdhcp-1.12-1.i386.rpm (this is the version on the dvd)

How reproducible:
Everytime.  If I disable internal wireless card, thereby making internal
ethernet adapter eth0 I get an address immediately.

Additional info:
[root@localhost ~]# lspci
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge
(rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97
Modem Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW
[Radeon Mobility 7500]
02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller
(rev 01)
02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller
(rev 01)
02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet
Controller (Mobile) (rev 03)
Comment 1 David Cantrell 2006-11-02 10:39:31 EST

*** This bug has been marked as a duplicate of 213262 ***
Comment 2 John Poelstra 2006-11-02 10:57:45 EST
How can you make a Fedora bug a dup of RHEL? They are different products.  This
could mean that the fedora bug won't get fixed until it does in RHEL or vice versa.
Comment 3 David Cantrell 2006-11-02 11:02:12 EST
Same tree, same code at the moment.  I'm drowning in bugs and am trying to clean
things up a bit.  I saw the dupe and thought it was a mistake.

This needs to be assigned to kernel for Fedora.
Comment 4 Karl Auerbach 2006-12-21 19:04:53 EST
I'm having a similar issue with FC6 and FC6-x64.

The installation hangs whenever I try to do a kickstart via NFS, e.g. when I
feed the following to the installation prompt:

linux ks=nfs:mykickstartserver:/vol1/Fedora/fc6.cfg

It hangs doing the DHCP.

The same machine works find doing a similar install using FC5.

The DHCP server is on the same subnet and is responding to the DHCP requests.

The machine has 3 ethernets, two are Intel e1000 and the third is an Nvidia

The problem occurs no matter which answer I give to the installer's question of
which interface to use.

The problem seems to exist for both FC6 32 bit and FC6 64 bit.

There is no active IPv6 on the subnet I am using, only IPv4.

I was running FC6 x64 on this box, having done an install from DVD, without any
problems and getting addresses for these interfaces via DHCP.  I discovered the
problem when I went to reload the box using my normal kickstart procedures
(modified for FC6)

I have not tried this on another box.
Comment 5 Karl Auerbach 2006-12-22 17:19:29 EST
I found the problem that I was having - IPv6 DHCP delays.

When there is no IPv6 DHCP server the kickstart process goes through several
rounds of (successful) IPv4 DHCP, each round of which contains an unsuccesful
IPv6 DHCP request.  And each of those IPv6 DHCP requests is repeated several
times, each with a timeout.  And those timeouts appear to be following an
exponential backoff.

All-in-all, these futile IPv6 DHCP delays cumulate to the degree that it appears
that the kick-start is hanging.

It would seem that an option is needed to say "don't try IPv4" and another
option to say "don't try IPv6".

I observed this long delay behavour occuring both when the ISOLINUX based code
as getting the kickstart file and then again when the kicstart file was being
processed.  So this option would have to be in both the startup ISOLINUX stuff
as well as in the kickstart file itself.

Perhaps we need something that looks like:

For both IPv4 and IPv6:
linux ks=nfs:mykickstartserver:/vol1/Fedora/fc6.cfg 

For IPv4 only:
linux ks4=nfs:mykickstartserver:/vol1/Fedora/fc6.cfg
For IPv6 only:
linux ks6=nfs:mykickstartserver:/vol1/Fedora/fc6.cfg 

And in the kickstart file it could have some a line that says what protocols
should be used to do the installation:

install_protocol --ipv4
install_protocol --ipv6
install_protocol --ipv4 --ipv6
(The last would be the default)

Comment 6 John Poelstra 2006-12-22 19:36:55 EST
try this: noipv6 ip=dhcp
Comment 7 Jon Stanley 2007-12-31 01:53:02 EST
noipv6 should help here.  Without further objections, I'll close this in a few
days since FC6 is EOL.  This is also likely anaconda or pump, not the kernel proper.
Comment 8 John Poelstra 2008-01-01 17:09:30 EST
Fine to close as this is for FC6 and I no longer have the hardware.  

FWIW... in the RHEL 5 version of this bugs it was determined to be an issue in
the kernel related to the aironet driver.  The source of the problem and a fix
has not been found to date. This is not an ipv6 issue.

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