iBFT table lost / not found after iSCSI boot

[qon]

I am trying to network-boot a windows 10 using iPXE in the uefi version (snponly.efi) from a linux system.
I have one client PC that boots windows successfully (which tells me that my setup is ok in general) but another client PC with different hardware that always fails with INACCESSIBLE_BOOT_DEVICE error.

Unfortunately, due to missing logging in windows, this is a bit difficult to debug. I have checked many possible problems pointed out in other posts (LFW bindings, critical device database, start mode of network device) but no luck, and also all these are identical for my 2 client PCs, so it should be fine (even though it seems to me that all this stuff isn't needed anymore). I have bootet the windows from a local disk on the failing PC locally, which works and also the NIC is correctly installed. So also the windows installation should be fine. That made me look into other directions, so I started looking in the iSCSI / iBFT part.

Clearly, iSCSI itself is working, since I am reading the windows bootloader from the iSCSI target.

Thus, I started a network linux (using nfs, not iscsi) on both PCs, to investigate a bit further (same image on both client PCs).
What I see that:
- Loading the iscsi_ibft kernel module on the good client, the kernel log tells me the iBFT is detected.
- On the client that fails to boot, linux tells me that no iBFT is detected.
So I guess the problem is that on that PC the iBFT table is not created correctly or is overwritten afterwards somehow.

For the sake of it, I retried a legacy boot with Linux instead of UEFI (undionly.kpxe instead of snponly.efi). In that case, linux actually detects the iBFT on both clients.
Next, I want to try to network-boot a windows using legacy boot. If that works on the client failing in efi, it would confirm that it is indeed an efi-related problem. Unfortunately, right now I have some trouble with the legacy boot bootsector also on the good client. But in the end I need to boot via efi in any case, so this test is only for understanding the problem.

In case it is relevant: the failing client is an AMD Threadripper on an ASUS Zenith II Extreme Alpha motherboard. I am booting from dnsmasq. I have tried ipxe.efi instead of snponly.efi, but no difference. I also have tried several ipxe binaries and I have built the latest branch from scratch, didn't help.


That is how far I am so far. Any suggestionsor ideas would are very welcome.

[qon]

Here is a quick update after some progress I made: I fixed the windows legacy boot problem and I am now able to boot windows via legacy boot over ipxe/iscsi on all clients.
So the problem is definitely that the iBFT table is either not created or overwritten when booting in UEFI on that particular client.

In the meantime I have also tried a different Intel NIC, and also a Mellanox Connect-X 3 NIC that has an ipxe in its UEFI boot ROM, all with the same result. It works in legacy boot, but with UEFI it fails due to missing iBFT table.

I am wondering whether there is a simple way to check at boot time whether the iBFT table is created correctly. Apparently with UEFI the iBFT spec works differently and the table should be created as ACPI table.

[qon]

Just to document a bit the status. With the UEFI boot, the iBFT should be an ACPI table. I have compiled the AcpiViewApp from the tianocore edk2 Uefi shell package, to dump the ACPI tables at boot time. On all other systems, I see the iBFT ACPI table present after running iPXE, but on the ASUS Zenith ii board, the iBFT ACPI table is not created. That must be the problem.

It is still not clear whether iPXE fails to create the table, or whether the memory is somehow write-protected / overwritten...
In any case, I do not see any error message by iPXE. Will have to add some debug code to iPXE to understand what happens.

[qon]

Final comment on this. After adding some debug code to ipxe, it turned out that when iPXE calls the Uefi protocol to install the ACPI table the first time, nothing happens on the ASUS board. On other system this works correctly. Thus, I assume the problem is with the ASUS firmware, and I have reported it to ASUS.