Red Hat Bugzilla – Bug 104246
(NET E1000) dhcp fails during installation w/ Compaq NC6136 Gigabit NIC, works after install
Last modified: 2007-11-30 17:06:58 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807 Description of problem: I've got two HP DL360G3 servers that both exhibit this behavior. Installer fails to get ethernet address (and kickstart file) from dhcp server. If install is completed manually, the ethernet interface comes up properly via dhcp on first boot. The ethernet card is: 06:01.0 Ethernet controller: Intel Corp. 82543GC Gigabit Ethernet Controller (Fiber) (rev 02) Subsystem: Compaq Computer Corporation NC6136 Gigabit Server Adapter Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at f7fe0000 (32-bit, non-prefetchable) [size=128K] Memory at f7fd0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at <unassigned> [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Is the e1000 driver in the installer different from the one in the kernel rpm that gets installed on the system? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install Taroon-beta2 on HP GL380G3 w/ HP NC6136 fiber card. 2. Choose 'Get IP automatically' in installer. 3. Actual Results: Installer fails to get IP address. This also causes kickstart installs where the dhcp server defines the location of the .ks file to fail. Expected Results: Bliss. Additional info: Both on-board ethernet controllers are turned off in the BIOS. Only the PCI ethernet card detailed above is active.
I just tried this with RedHat 9 and I get the same result.
Is Spanning Tree Protocol (STP) enabled on the switch you're connected to? When the driver is loaded, link is activated, which would start the STP algorithm on the switch. It may take up to 30 seconds before the switch lets traffic pass through the switch port. This would block getting a DHCP address. It's just a guess. Something to look into. If it is STP, you can disable that from the switch management console.
I'll look into this just to rule it out, but if this were the problem why does dhcp work normally after a manual installation of the OS? I was assuming there was some difference between the boot kernel on the install media and that in the distro.
Two things: - RH v9.0 is not qualified for the Proliant. HP/Compaq is not actively supporting this release, plus you'll need a special driver for the Proliant to recognize the CDROM (available at HP/Compaq website). - The suggestion about turning off STP at the switch worked like a charm for me with a similar problem. After switching some Proliants from 100 baseT to 1000 baseT, we encountered a problem were not all our NFS directories were not mounting. The following clue was found in /var/log/messages when the system tried mount NFS directories: Mar 9 19:20:33 quartz mount: mount: RPC: Remote system error - No route to host Immediately after this message some of the mount requests succeeded, while the ones prior to the message failed. This was being caused by the latency introduced by STP at the switch. Try turning off STP!
The RH v9.0 comment was just an extra data point - RHEL 3 wasn't out at the time. I've just verified that STP is off on the 3Com 4900 gig switch.
How is this looking in Fedora Core or RHEL3?
Does not work on RHEL3 - resorted to putting ks.cfg file on floppy. Interface does come up during kickstart when a static network assignment is made in the ks.cfg file. Have not tried Fedora. I don't currently have a HP GL380G3 w/ HP NC6136 fiber card that isn't in production. mjc
Could you attach the output from running 'sysreport'? Thanks!
Created attachment 111488 [details] 'sysreport' output
Can you see any DHCP traffic on the wire (during the install)? Perhaps you can attach the output of something like tcpdump or ethereal running at the DHCP server (hopefully on an isolated network)? Thanks!
Unfortunately, I don't have any of these boxes that aren't now in production.
Considering that there have been a number of e1000 updates in RHEL3 since when this was reported (and even since comment 7) and there don't appear to be any other complaints along these lines, I'm going to have to close this out. If you or anyone else is still having this problem with the latest RHEL3 update, please reopen this bug so that we can investigate further. Thanks!