PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...
-
Hi all
We are having following problem when executing a PXE boot on a HP Elitebook 650 G10:
As you can see, we’re using snponly.efi and already updated the binary as mentioned here: https://docs.fogproject.org/en/latest/kb/reference/compile_ipxe_binaries/.
Snp.efi or other .efi binaries don’t work either.The DHPC options 66 and 67 are correctly specified.
Bios settings on the device
- secure boot is off
- MAC address pass through is disabled
Any advice is welcome.
Thx in advance!
-
@Dominique I guess I have a few questions in regards to this
- Is it just this specific model or all models from this network jack?
- Is this a new setup with FOG or have you used it successfully before?
From your picture I can see that you have the dhcp server setup correctly, you have secure boot off (or ipxe won’t boot), using snponly.efi will use the built-in driver that is part of the nic. You might try ipxe.efi to see if you have better luck, but snponly.efi or snp.efi is probably the best general purpose boot loader.
The no configuration methods screen is basically saying the ipxe kernel is not getting a dhcp response. I have seen this before if you have standard spanning tree enabled on your building switch. In this case you can check to see if its spanning tree issue, but placing a dumb unmanaged / cheap-o switch (like monoprice 5 port switch for $20) between the building switch and the pxe booting computer. If that solves the problem then its spanning tree causing the issue. Enable one of the fast protocols on your building switch like portfast, fastSTP, RSTP, MSTP or whatever your switch manufacture calls it.
-
- I can build other laptops on that network jack
- No new setup, have build hundreds of devices a day.
On a newly installed FOG server (for testing purposes) a device off that model can PXE boot as it should.
Already copied the snponly.efi from that FOG server, but no luck. -
@Dominique said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:
I can build other laptops on that network jack
No new setup, have build hundreds of devices a day.Ok just trying to establish what the problem isn’t. Ok so you updated your ipxe binaries to the latest version. So that’s good.
Looking at the model this hardware is pretty new (Aug 2023). Are you using the nic built into the chassis of the laptop or an external nic in a dock or usbX attached dongle?
Check to see if there is a firmware update available for this hardware. The snp.efi and snponly.efi boot loaders use the nic driver built into the UEFI firmware. On most modern uefi implementations its very robust and stable and should work right out of the box.
I would try for testing purposes to update dhcp to send ipxe.efi boot loader instead of the snp boot loader. Does that boot loader work? The ipxe.efi boot loader is a lot like the linux kernel where it has most of the common network drivers built into the boot loader.
-
I just received this exact same model laptop and I’m having the same problem. I’m using the onboard NIC with the ipxe.efi loader. The onboard NIC is an Intel 1219-V
Here is what I’ve done so far:
- Updated the ipxe.efi manually.
- Updated the BIOS to the latest version.
Using ipxe.efi it gets stuck “iPXE initalising devices…”, however if I set the snp.efi it boots successfully.
We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?
-
@RobertD said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:
We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?
Its great that you have a path to boot these system via the snp driver.
You didn’t mention if you updated iPXE to the latest release to see if the ipxe.efi boot loader works once again.
Let me (re)clarify in this thread the differences between ipxe.efi and the snpX.efi boot loaders.
ipxe.efi (uefi) and ipxe.kpxe (bios) contain all of the known drivers built into the boot loader, this makes the iPXE boot loader much larger in file size (in 1990 terms of file size) because it has to carry all known drivers onboard the boot loader. For older systems > 6 years those were the preferred boot loaders for iPXE
snp.efi, snponly.efi (uefi) and undionly.kpxe (bios) use the network adapters built in driver through the generic snp or undi interface. This boot loaders are much smaller than the ipxe.* versions since they only need to have one driver onboard (snp or undi). The undi driver (bios) has been around for 30 years and is the preferred and very stable network interface for bios computers and should always be the #1 choice. The uefi firmware has only been around for 12 years or so. The early version were very buggy so the snp driver did not work well. This is the reason why the fog developers recommended the ipxe.efi boot loader for uefi systems. In the last 6 years or so the snp and uefi firmware has matured to a level where the fog developers are recommending snp.efi or snponly.efi for all modern hardware. For bleeding edge hardware you have a better chance to get the snpX.efi bootloaders to work before the ipxe.efi bootloader, because the iPXE kernel developers will need to add the driver to the bootloader. Its just a timing issue.
Now you might ask what is the difference between the snp.efi and snponly.efi drivers. snponly.efi will only initialize a network interface from where it was loaded from. For example lets say you pxe booting a compute with 4 nics, and you pxe bootin from nic2. The iPXE boot loader would only init nic2 using the snponly.efi bootloader. In contract snp.efi would try to init all nic intefaces starting with 1, 2, 3, and then 4. The issue becomes if nic1 takes the boot loader someplace else other than to the FOG server, since the fog server is on nic2.
