PXE Boot Error (NO DHCP Repsonse) - Realtek Driver - HP ProBook G3
-
@george1421 New ones we just got in. ProBook 470 G3, looks like its using a Realtek NIC
-
@noelpd These are new like just from china new?
If that is the case the FOS Engine may not have the proper driver for it. I do see the ProBook 470 G2 are supported but no mention of the G3.
OK here is what I need you to do. I need you to manually register this computer and then schedule a capture or deploy it doesn’t matter because when you create the task, make sure you select the debug capture/deploy option. Then PXE boot this new G3.
It should take you right to what ever mode you selected, but don’t worry its not going to do anything. After a few pages where you have to hit enter you will be dropped to a linux command prompt. This is the shell of the FOS Engine.
Now we need to see what the FOS Engine sees for hardware. I need you to key in
lspci -nnThis should give you a list of built in hardware, you need to look through the list for the ethernet adapter. On that line, there will be a hex code like (8086:3D12) [that was made up]. We need to know that code. The @developers will need to see if that driver is included in the FOS kernel. -
This is the firmware.
Change the bootfile to ipxe.pxe and all should start working for those devices.
-
@Tom-Elliott We did that and it boots to a iPXE command line interface, still not working with that change.
-
@Tom-Elliott and also by changing it to ipxe.pxe it tanks our other computers and they won’t boot to FOG. Mostly the HP ProBook 6470 G1 and 640 G2 laptops.
-
@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.
-
@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?
-
@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 -
This post is deleted! -
@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
-
@noelpd OK maybe the
lspce -nndoesn’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 -
@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)
-
@noelpd Nice, now when the developers get back then can see if that hardware is supported (it should be based on the title).
-
Did you use
ipxe.pxeoripxe.kpxe? -
@Tom-Elliott Looks like we tried ipxe.kpxe and not ipxe.pxe
-
@noelpd Can you try
ipxe.pxe? -
@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?
-
@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.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@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?
-
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?
