Failed to get an IP via DHCP!

[Sebastian Roth]

@KellyG Hmm, from the output you posted it seems like it only recognized the Broadcom NetXtreme II 5709 Gigabit NIC - Quad Port. What about those two onboard NICs? Not recognized at all? I wonder why they don’t show up in the lspci listing. Can you get the PCI IDs (for onboard and the PCIe NetXtreme card) from the windows device manager - post the *full “Hardware ID” string you find in the details tab)? Possibly we need to add a firmware driver to the kernel.

[KellyG]

@sebastian-roth Those are the onboard nic’s. I had to pull the PCIe card for another server. If I have the card in the system, I can boot to the LOM, but they don’t recognize that there is a DHCP responding. The PCIe NIC will respond to the DHCP, but won’t PXE boot.
I’m not finding anything specific about the NetXtreme, are they supported for imaging?

[Sebastian Roth]

@KellyG In general the BNX2 driver is in our kernel, see here but some of those NICs need special (closed source) firmware blobs added to the kernel. We do add those as requested but we need to know exactly what card you have to figure out if firmware is needed and which one. That is why I asked for the exact PCI IDs.

I can boot to the LOM, but they don’t recognize that there is a DHCP responding

What do you mean by LOM?

[Sebastian Roth]

@KellyG Did you read what I was saying about spanning tree and trying out a dumb (unmanaged) mini switch??

[KellyG]

@sebastian-roth with regard to the switch, I’m still trying to locate a non-managed switch. According to the network team, the switch I’m using has been wiped (although I suspect something is still enabled on it). I don’t have the password for it so I can’t log in and verify spanning tree. I have a small 4 port switch at home and will try it tomorrow.

For the ID’s, I hate KVM switches when they aren’t labeled properly. I was looking at the FOG server instead of the server I’ve been trying to image. This is what I show;

$ lspci -vv |grep -e "^[0-9]" -e "Kernel driver" |grep -A 1 "net"
03:00.0 Ethernet controller: Broadcom Corporation Device 1657 (rev 01)
03:00.1 Ethernet controller: Broadcom Corporation Device 1657 (rev 01)
03:00.2 Ethernet controller: Broadcom Corporation Device 1657 (rev 01)
03:00.3 Ethernet controller: Broadcom Corporation Device 1657 (rev 01)
0a:00.0 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
               Kernel driver in use: netXen_nic
0a:00.1 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
               Kernel driver in use: netXen_nic
0a:00.2 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
               Kernel driver in use: netXen_nic
0a:00.3 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
               Kernel driver in use: netXen_nic

[george1421]

@kellyg said in Failed to get an IP via DHCP!:

the switch I’m using has been wiped (although I suspect something is still enabled on it).

The issue is a wiped switch will typically have spanning tree enabled by default. It depends on the switch mfg, but most of the time its a good then to have spanning tree enabled. So your suspicion is probably spot on.

[Sebastian Roth]

@KellyG Unfortunately those adapters seem to be a little special. Linux does not translate the PCI IDs as good as I expected it to. So I am unable to reverse those and need to ask you to run this as well: lspci -nn | grep net (sorry, should have asked for this earlier as well)
Seems like we do have the NETXEN_NIC driver in the most current kernel configs. But don’t know about the Broadcom devices - need the PCI IDs first.

Edit: From that number 1657 it looks as if this could be a “NetXtreme BCM5719 Gigabit Ethernet PCIe card” - PCI ID 14e4:1657. It’s supposed to work with the TIGON3 driver. Don’t think we need a firmware blob for this. But on the other hand I am wondering why “Kernel driver in use” is missing in the output for those Broadcom NIC(s).

[KellyG]

By the way. Thanks to the both of you for your help.

@george1421 I’ll know something tomorrow with the dumb switch. It’s an old netgear sitting in a drawer.

@Sebastian-Roth Here’s the latest data for you.

03:00.0 Ethernet controller [0200]: Broadcom Corporation Device [14e4:1657] (rev 01)
03:00.1 Ethernet controller [0200]: Broadcom Corporation Device [14e4:1657] (rev 01)
03:00.2 Ethernet controller [0200]: Broadcom Corporation Device [14e4:1657] (rev 01)
03:00.3 Ethernet controller [0200]: Broadcom Corporation Device [14e4:1657] (rev 01)
0a:00.0 Ethernet controller [0200]: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter [4040:0100] (rev 42)
0a:00.1 Ethernet controller [0200]: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter [4040:0100] (rev 42)
0a:00.2 Ethernet controller [0200]: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter [4040:0100] (rev 42)
0a:00.3 Ethernet controller [0200]: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter [4040:0100] (rev 42)

Let me know what else you need.

[Sebastian Roth]

@KellyG Ok, from what it looks to me we have the right kernel drivers included (definitely for FOG 1.4.4 and I am sure much earlier but haven’t checked).

Try the dumb mini-switch today and see what you get.

Just as a hint: The ethernet ports aren’t always “sorted” the same way. So what is eth0 on your installed OS does not have to be eth0 (most probably is not) when FOG is booting up. Please keep that in mind when trying through the ports. Our network start script should handle this though as it does enumerate the NICs found and tries them all.

[KellyG]

@sebastian-roth & @george1421
Ok… The netgear switch didn’t change anything. I’m starting to suspect the problem is in the server FOG is running on. I’ve got a meeting with HPE next week. I’ve been pinging them about this and the tech keeps telling me that there is nothing wrong with the server, however, I tried to boot the server to the corporate PXE and I couldn’t get it to even get the PXE menu. Whereas with the FOG server, I could get the PXE Menu with no problem. I will let everyone know the outcome of my meeting with HPE and we can pick it up from there.

I noticed that when I ran ifconfig on the server after booting to a Knoppix Live CD, The only adapters that were detected were the add-in cards. It registered them as a Broadcom NIC. So my assumption (I’m sure I don’t have to explain what assume means) is that the netXen nic is the LOM and the Broadcom is the PCIe. So Knoppix is registering eth0 as the Broadcom. I booted to the OS (Winblows) and it shows the LOM as the primary NICs.

[george1421]

Moderator’s note: May not be related, but cross linking threads: https://forums.fogproject.org/topic/10599/hp-proliant-dl580-g4

[Sebastian Roth]

@KellyG Any news on this?

[HEL]

Hello Guys,

thanks for all these information,

I installed FOG 1.2 (old) and updated later to the 1.4 on the same server with debian 9 .

I had the same problem
<
The server will boot to the FOG menu, but after selecting the quick registration, the system does not get an IP address

It have simply an wrong ip adresse in FOG configuration, like :
…
TFTP Server
…
Web Server
…
(wrong ip from the old install, ip adress changed)

after fixing the fog server ip address every things works fine.

Debian9 fully compatible with FOG1.4

Bye

Hassan