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):
Steps to Reproduce:
1. Install Taroon-beta2 on HP GL380G3 w/ HP NC6136 fiber card.
2. Choose 'Get IP automatically' in installer.
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.
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.
- 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
- 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.
Could you attach the output from running 'sysreport'? Thanks!
Created attachment 111488 [details]
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
Unfortunately, I don't have any of these boxes that aren't now in
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.