PXE Boot Error (NO DHCP Repsonse) - Realtek Driver - HP ProBook G3

[george1421]

@noelpd Just to be sure I didn’t loose my place here.

The original post was that when you select full inventory from the iPXE menu you get an error message in the FOS boot about no dhcp response on interface eth0? If this is the case they your iPXE boot file is correct with undionly.kpxe, IMO the issue is a FOS driver one. We’ve kind of ruled out a spanning tree issue (typically what we see here).

We will need the vendor and device code that I mentioned before.

[noelpd]

@george1421 Ok, i am looking at the list now via the lspci command, however there are about 14 lines represented by the 8086, i dont see anything in relation to the mac address. Anyway to identify which one is the correct one I should be giving you?

[george1421]

@noelpd Remember I said that number starting with 8086 was made up. Actually the vendor code 8086 is for intel, so I hope you would not find it there.

try this one if there is a lot of lines lspci -nn | grep rnet

[noelpd]

This post is deleted!

[noelpd]

@george1421 Ok pretty sure I found the line that you need…

02:00.0 “0200” “10ec” “8168” -r15 “103c” “8102”

I figured this was the right one because I ran lspci by itself and the realtek NIC was identified by the 02:00.0

[george1421]

@noelpd OK maybe the lspce -nn doesn’t return what I expected in FOS. In centos 7 it returned something like this:

0b:00.0 Ethernet controller [0200]: VMware VMXNET3 Ethernet Controller [15ad:07b0] (rev 01)

Try it with only one -n

[noelpd]

@george1421 That was my bad, I was not doing nn

nn seems to work. I got the following result

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)

[george1421]

@noelpd Nice, now when the developers get back then can see if that hardware is supported (it should be based on the title).

[Tom Elliott]

Did you use ipxe.pxe or ipxe.kpxe?

[noelpd]

@Tom-Elliott Looks like we tried ipxe.kpxe and not ipxe.pxe

[Tom Elliott]

@noelpd Can you try ipxe.pxe?

[noelpd]

@Tom-Elliott We made the change on the DHCP to ipxe.pxe and updated to RC-13 with ipxe.pxe in the .fogsettings file. Still no go. Any ideas? Is there another file location on the server that needs to be changed to ipxe.pxe to make it work?

[Sebastian Roth]

@noelpd Re-reading your inital post I see that you were saying that you got the message “No DHCP Response on interface eth0”. This is happening way beyond the iPXE stuff within the linux network startup script (code here: https://github.com/FOGProject/fogproject/blob/dev-branch/src/buildroot/system/skeleton/etc/init.d/S40network). AFAIK there is no way you can change this by using a different iPXE binary!

We have seen different timing issues with the network stuff. More often than not this is caused by spanning tree protocol (STP) being enabled on the switch but the client port not being set to port fast. Please get a dump mini switch and connect it between the client and your main switch. See if the problem goes away then.

[george1421]

@Sebastian-Roth That what I was seeing. The issue is in the kernel (??). The OP pulled this information from the running FOS kernel.

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)

That realtek nic should be supported. The only thing I can think is that the device id [10ec:8168] is not in the hardware list, but I suspect that is not the case since 10ec:8168 IS the device name too. Could this be another slow start interface?

[Tom Elliott]

I’ve been under the impression that the issue was with PXE after it initially booted into FOG. Meaning, the first go around all worked fine, but after that, the iPXE side is having issues loading.

Am I incorrect with this?

[noelpd]

@Tom-Elliott With the HP 470 G3 I can get to the FOG Menu itself, but after the menu when I go to inventory the machine I get the mentioned error messages.

[Sebastian Roth]

@noelpd As I said already: We have seen different timing issues with the network stuff. More often than not this is caused by spanning tree protocol (STP) being enabled on the switch but the client port not being set to port fast. Please get a dump mini switch and connect it between the client and your main switch. See if the problem goes away then.

[Wayne Workman]

@noelpd I concur with Sebastian. You need to try a dumb unmanaged mini-switch between the computer and the building. Most I.T. places have a few laying around. If you don’t have one, they are pretty cheap to get - you should go out and get one.

You should also try brand-new patch cables too.