PXE boot issue with HP Probook 450 G8 (Realtek Nic)
-
@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.
-
@robertd said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):
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.
@Developers I wonder if this is the root of ALLLLLL of the issues we’ve been seeing in the last few weeks in regards to pxe booting, specifically with the HP models.
-
@george1421 Yeah, quite possibly!
@RobertD Thanks heaps for posting this information here!
-
@george1421 I stared at this and thought… this seems like it would break FOG. and I didn’t try it.
-
@rankinc said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):
this seems like it would break FOG
Well without the actual hardware in front of the developers, they have to rely on fog admins to try different things with their harware until they find a working path. So well done!!
-
@george1421 I could be missing another setting, but my fix is copying refind.efi to refind_x64.efi. the original refind_x64.efi, v12 and v13 did not work even after DMA disable.
-
@rankinc The developers shipped 0.11.0 for a long time with FOG. Sometimes when the newer ones fail we would recommend testing 0.11.0 to see if that masked the issue. But really we need to find out why the newer ones are failing so FOG can stay current with iPXE
