Red Hat Bugzilla – Bug 213270
install hangs using eth1 with dhcp
Last modified: 2008-08-02 19:40:36 EDT
+++ 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)
Everytime. If I disable internal wireless card, thereby making internal
ethernet adapter eth0 I get an address immediately.
[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
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
02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller
02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet
Controller (Mobile) (rev 03)
*** This bug has been marked as a duplicate of 213262 ***
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.
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.
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:
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.
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
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:
For IPv4 only:
For IPv6 only:
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 --ipv6
(The last would be the default)
try this: noipv6 ip=dhcp
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.
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.