PXE boot issue with HP Probook 450 G8 (Realtek Nic)
-
@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
-
@rankinc FWIW the only thing we did was, disabled secure boot, disabled DMA protection, changed the UEFI boot order to nic first (I also disabled all the other options) and it started working.
We were facing the exact same problem in the screenshots above. We are using ipxe.efi
EDIT: My machine also hangs at “rEFind - Initializing” after the image has been deployed, but we are just going back into the BIOS and setting the HDD as the first boot device after the image has been pushed. I don’t know where to begin troubleshooting this part of the process. Legacy BIOS was so much easier…
-
@robertd said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):
My machine also hangs at “rEFind - Initializing” after the image has been deployed, but we are just going back into the BIOS and setting the HDD as the first boot device after the image has been pushed. I don’t know where to begin troubleshooting this part of the process. Legacy BIOS was so much easier…
I can only give you a perspective from a Dell shop. In our case we do not boot through the fog server, but instead I require the IT techs to sit in front of the computer and press the F12 button during booting to get into the firmware boot manager, then select network boot. The default boot order is hard drive, so once imaging is done it boots back to the local hard drive. So personally I have not seen refind hanging, because we never really get there since we don’t boot through the fog menu. I’m not saying its a right or wrong way, just a different way.
-
@george1421 Understood.
For us it’s just extra steps we try to eliminate. We are a pretty large school district with over 65K students and 10K employees and a lot of machines. We have more then once had to re-image an entire campus because a virus outbreak and being able to push an image to a school and just telling them to reboot has saved us a lot of time in the past. Thankfully this hasn’t been an issue in a long time. Maybe times are changing and UEFI is going to force our hand…
-
Hello,
I have the exact same problem “no configuration method succeeded” with a Lenovo Laptop 20VE series
this is a realtek 8168 nic.I tried to change the ipxe.efi to snponly.efi and it is working fine.
Since I don’t know what are the differences between ipxe.efi and snponly.efi. I’m going to stay on snponly.efi.
I didn’t try realtek.efi since this snponly is working for me.
Thank you for your help
-
Yeah, switching to a different iPXE binary can help in some cases too.
Though I want to bring up what I have posted two weeks ago as well: https://forums.fogproject.org/post/141320 (compiling the latest version of iPXE)
-
Chiming in here… I’ve been stumped for some time after I too purchased a handful of new G8 HP Laptops.
Fortunately I found this thread, and I am glad to say that snponly.efi worked for me!
I figured posting might keeps this thread alive and relevant for others.
-
@ayy_nelson said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):
I too purchased a handful of new G8 HP Laptops.
Some things we found with this new generation of systems with this realtek network adapter. Update your FOS Linux kernel to 5.15.x series (we just discovered this) and also update your iPXE version using this method. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
Right now we only have anecdotal evidence that it fixes what changed in this generation of hardware.
