PXE boot issue with HP Probook 450 G8 (Realtek Nic)

[netbootdisk]

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.

[jtappen]

@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

[Sebastian Roth]

@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.efi as default but only set snponly.efi for specific machines like the Probook 450 G8? Does snponly.efi cause an issue for other machines? If not then you can just keep using that for all.

[george1421]

@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)

[jtappen]

@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

[jtappen]

@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

[george1421]

@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.

[jtappen]

@george1421 very strange in deed…
Anything you can suggest??

[george1421]

@jtappen Is it just this one troubled model or all of them now that you switched to snponly.efi?

[jtappen]

@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

[jtappen]

@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

[george1421]

@jtappen Well I think you have a few issues here.

1. 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.
2. 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.
3. 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.

[jtappen]

@george1421 I ran Wireshark on another machine to capture port 67…
The result shows:

Does this help solve the issue at all??

Jason

[george1421]

@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.

[Sebastian Roth]

@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.efi in your DHCP again, boot up a machine and pay attention to where the preemble tells you the version number iPXE (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.

[netbootdisk]

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

[RobertD]

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.

[george1421]

@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.

[Sebastian Roth]

@george1421 Yeah, quite possibly!

@RobertD Thanks heaps for posting this information here!

[rankinc]

@george1421 I stared at this and thought… this seems like it would break FOG. and I didn’t try it.