PXE boot issue with HP Probook 450 G8 (Realtek Nic)
-
We just started to get these laptops (HP Probook 450 G8)
These do NOT allow legacy boot in bios…We can NOT get them to pxe boot…
Here are some screen shots…
We have NO IDEA on what the issue might be… we can pxe boot many other devices… just not this new model…
Thanks in advance for any suggestions
-
@jtappen TBH I can’t remember if I responded to you or another poster in a different thread, but we’ve seen an uptick of issues with these new HP generation using the realtek nics.
This issue is specific to iPXE and the HP hardware. So for uefi there are a few .efi boot loaders I want you to try.
The default is ipxe.efi this contains all of the known (at the time of compiling) nic drivers. This boot loader is much like linux where the divers are compiled into the operating system.
The second is snponly.efi. This boot loader uses the driver built into the network cards. This should have the maximum compatibility. I would suggest that you try this to see if it works for these hp computers.
The third boot loader I want you to try is realtek.efi. This boot loader has only the realtek drivers compiled into the boot loader. See if this one works.
For reference you have iPXE version [g4bd0]
Do you have a cheap unmanged switch that we can have you insert between this computer and the building network switch? I’d like to see if you can get an IP address with that cheap switch in between the computer and the building switch. We need to do this test to rule out something common.
-
@jtappen If you have the capabilities to run wireshark on a witness computer connected to the same subnet as this pxe booting computer I’d like to see the pcap of that. Use the capture filter of
port 67 or port 68to capture only the dhcp bits we need.Specifically we should see the PXE dora process of Discover, Offer, Request, Ack. Then as iPXE starts up we should see the repeat of the DORA. It would be interesting to know if iPXE is sending out a DISCOVER but no one can satisfy the request so we will see a series of Discover, Offer, Pause, Discover, Offer, until ipxe gives up.
-
I had the same battle with these 450 G8’s, and new HP Elitedesk 600 G6 micro desktops. But I now have it working!
My real problem was rEFInd hanging after the PXE boot menu. I updated /var/www/fog/service/ipxe/refind.efi on the primary fog server, with the copy from the latest FOG 1.5.9 zip. (The refind.efi copies on any storage nodes isn’t used?)
I’m PXE booting with ipxe.efi also from FOG 1.5.9
Then in the HP BIOS, the HP SureProtect stuff was all disabled too
Unrelated but the bzImage kernel also needs to be the latest build so the NIC is detected on it. The new February 2021 build solved that one.
EDIT: I’m sure I’ve seen your original error message too about no configuration methods. I can’t remember if this was solved via BIOS update - or if it was more switch-port related.
-
@george1421 So we changed all of our DHCP settings to point to snponly.efi and we are able to pxe boot into FOG…
So a question, once it is able to FOG boot… is there a way (in fog or something) to see the Arch info needed to configure for ipxe.efi?
Thanks again for your assistance
Jason
-
@jtappen said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):
So we changed all of our DHCP settings to point to snponly.efi and we are able to pxe boot into FOG…
Well that’s good news!
So a question, once it is able to FOG boot… is there a way (in fog or something) to see the Arch info needed to configure for ipxe.efi?
Do you mean you want to use
ipxe.efias default but only setsnponly.efifor specific machines like the Probook 450 G8? Doessnponly.eficause an issue for other machines? If not then you can just keep using that for all. -
@jtappen What is your dhcp server?
Also in theory snponly.efi “should” work universally. snponly.efi uses the same concept as undionly.kpxe (for bios).
to say it another way.
snponly.efi is to undionly.kpxe (uses the driver built into the network adapter)
as
ipxe.efi is to ipxe.kpxe (the ipxe.xxxx uses its own internal network drivers) -
@sebastian-roth We are in process of testing a few other machines…
1 thing I notice on this machine if I PXE boot, but then tell it to boot hard drive it gets stuck on the "rEFInd - initializing… "
I have tried setting the option under this host to just EXIT, as well as GRUB_FIRST_HDD and both have failed as well…
Any other suggestion on that?
We have never had issues booting to HDD after PXE booting when it was set to ipxe.efi and our exit type set to rEFInd
Thanks again for every ones assistance…
Jason
-
@george1421 Our server is 2012 R2 (I am told)
only issue now so far is if we have bios set to network boot first, once in fog menu, the boot to HDD fails… with every exit type I have tried so far…
Jason
-
@jtappen That is strange why ipxe.efi and snponly.efi exit differently and why refind.efi (totally different program) hangs during initialization. The refind.efi program (project) is not associated with the ipxe developers at all.
-
@george1421
very strange in deed…
Anything you can suggest?? -
@jtappen Is it just this one troubled model or all of them now that you switched to snponly.efi?
-
@george1421 So far I have only tested a few of our models… and have had mixed results… some of our older models can not even PXE boot now
ugh
Jason -
@sebastian-roth is there any way to fix this device in ipxe.efi ?? as I know we had good luck with ipxe.efi & REFIND_EFI as the exit type un until now…
Thanks again for your assistance.
Jason
-
@jtappen Well I think you have a few issues here.
- The Microsoft DHCP server is not quite as flexible as, say a linux based dhcp server. If you have used this tutorial on setting up your dhcp server you will see that you can create filters to change the boot file name based on a vendor defined class: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy This is how you can send uindonly.kpxe for bios computers and ipxe,efi for uefi computers. It might be possible to create a filter that is hardware specific but that will be unreliable.
- Is possible that the version of iPXE that FOG is deploying is old and the current version (from the iPXE developers) has addressed this issue.
- Its just crappy firmware on this computer, where you need to wait for the vendor to fix their firmware so you can go back to the way you have been deploying all along.
-
@george1421 I ran Wireshark on another machine to capture port 67…
The result shows:
Does this help solve the issue at all??
Jason
-
@jtappen It would if the UUID is not globally unique and a part of the UUID indicates the model. While I have not done this with MS Windows dhcp server but with linux dhcp AND “eac7bf8-” (or some part of it) being the model identifier then a policy rule could be crafted. But we found the hardware vendors are in charge of the UUID and they do some random and vendor specific things with it.
-
@george1421 said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):
The Microsoft DHCP server is not quite as flexible as, say a linux based dhcp server.
Can you define different DHCP policies and apply those bound to a certain MAC address with Windows DHCP? I don’t know much about Windows DHCP, so just wondering.
@jtappen Yes George is totally right, you can build new iPXE binaries from the very latest github code and see if this works with your devices. Assuming you have the FOG stuff in /root/fogproject try this:
sudo -i cd /root/fogproject/utils/FOGiPXE/ ./buildipxe.sh cp ../../packages/tftp/ipxe.efi /tftpboot/Pay attention to the long output when running ./buildipxe.sh as it might fail for whatever reason. If you feel it ends with an error, post the last 10 lines of the output here and we will have a look.
Now set
ipxe.efiin your DHCP again, boot up a machine and pay attention to where the preemble tells you the version numberiPXE (g.....). That should be different to what we have in the picture you posted earlier, then you know you have the new iPXE in use. -
I did some further testing.
With BIOS Mac-address pass-through set to ‘disabled’ - ipxe.efi works fine.
However with BIOS Mac-address pass-through set to ‘system mac’ - ipxe.efi fails as per the original posters screen shot of ‘no configuration methods’. However using snponly.efi did work in this mode
-
Hey guys we just ran into this same exact problem. We found that if you disable DMA Protection in the BIOS it will PXE boot no problem. Just wanted to leave this out there for you to try.
