NBP File Downloaded successfully boot loop

[sonic136]

Hi Community

I have an Asus B560m-k motherboard with the latest version of BIOS patch. The settings for network boot is correct as it boots to the Fog tasked sequence. It then gives the attached message and then loops back.![alt text]

The Fog kernel has been updated to 5.10.50 TomElliot64 and is on version 1.5.9.

How can this be fixed?

The image that needs to be loaded is UEFI enabled (it has to be this way as the new Windows LTSC version will require this) . The machine also has a single m.2 1TB installed.

[Sebastian Roth]

@sonic136 Try using snponly.efi instead of ipxe.efi and see if that works.

The other thing is you can download the latest iPXE binaries manually and put those into /tftpboot on your FOG server and see if those make a difference.

[EduardoTSeoane]

@sonic136 @Sebastian-Roth
You can try too with the development efi files, it worked for me

You can get it from here:
https://github.com/FOGProject/fogproject/tree/dev-branch/packages/tftp

[sonic136]

Hi

Thanks for the guidance, the file changes have worked!

I now have another issue related to this, how do I get my EFI files to a thumb drive?

I have a test network running that does not have any flags set, so a thumb drive is used to get to the fog console where images can be selected. Seeing that the changes have been made to /tftpboot can the efi files be updated on the flash drives for my support team to use on these new motherboards? If so, how?

[sonic136]

@sebastian-roth Upon further investigation, it turns out that older boards dont really like the snponly.efi when PXE booting.

The machines just hang on the PXE boot screen and does not boot to Windows. The snponly.efi if default (I.E, no changes made).

This machine worked with the ipxe.efi file applied to it.

Are/ is there an option that will work across the all types of motherboards? old to new or is there something in the snponly.efi file that needs to be changed or added for the machine to complete pxe booting. side note: pxe boot - no image applied, just needs to boot to windows, but if there is an image applied then obviously the machine will complete the PXE command and the machine will begin the re-image sequence.

[george1421]

@sonic136 said in NBP File Downloaded successfully boot loop:

Upon further investigation, it turns out that older boards dont really like the snponly.efi when PXE booting.

Well this really isn’t a problem of FOG, but of your computer’s uefi firmware.

For a little clarity here.

snponly.efi is to uefi as undionly.kpxe is to bios. Both of these use the NIC’s built in network drivers. Of course undi for bios has been around for 20 years (don’t quote me) For ufei, snp hasn’t been around for that long. So the early motherboards the snp drivers were bad. Within the last 2 years the nic/motherboards with snp are much better where snponly.efi works well.

Now ipxe.efi is to uefi and ipxe.kpxe is to bios. In this case the ipxe.??? boot loader contains all of the common nic drives built into the boot loader, much like linux has all of its drivers in the linux kernel. This is where ipxe falls behind new and current hardware. Since ipxe needs the drivers someone needs to write them for inclusion into iPXE.

In the end its the responsibility of the hardware manufacture to get the uefi firmware and snp driver working correctly. That is why the snponly.efi works on some computers and not others.

[sonic136]

SOLVED! Thank you for the assistance!

[Tom Elliott]

@sonic136 Can you describe what you did to fix the issue rather than just saying solved? I’m still “coming back” but I think a more descript message of what you did to fix the issue can help others more readily too.

[sonic136]

We had to enable 2 flags on the network side of things a C flag has been set to ipxe.efi and a d flag as been assigned to snponly.efi. when a new machine comes in, its registered on the network and assigned either one of these flags. The machine then “knows” to pull the corresponding file for a successful PXE boot.

[***Redbob]

Let me give a feedback to this issue, as I faced it recently. In my case, the culprit was faulting parameters in Microsoft DHCP.

It was faulting “MSFT Quarantine” User Class and PXE Vendor Class is not properly configured (It was typed “PXEclient:Arch:00007” instead of “PXEClient:Arch:00007”).

After doing this corrections, PXE got successfully redirected Boot instructions to FOG Server.