+++ 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)
*** 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: 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 controller. 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 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)
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.