@Warsonix Great you figured out how to switch to a different iPXE binary. You are welcome. Feel free to ask whatever issue you run into in a new topic.

@george1421 Yeah, it seems it was the drivers for the ethernet port itself that needed to be updated. So weird. You’d think that would have been tested before the device was even shipped out, too, but evidently not… It really is an odd one.

Thanks for sticking it out with us! The help is much appreciated.

@Gael et al.

I’m post a more descriptive post to summarize what the issue is. I don’t know how to fix (so I’ll start there.)

TL;DR;

Linux Kernel is putting a volatile Firmware on the NIC. This happens when FOS loads and the kernel begins associating the drivers. On restart, the firmware is still existing on the NIC from the Kernel. When Windows Boots, it re-flashes the volatile firmware so subsequent elements will work. Or a full power pull will do too (completely cold boot.)

Basis:

This particular issue, is due to Linux Kernel having a firmware defined for the NIC. This is volatile. This means when power is pulled, the firmware will no longer be present and normal actions will work properly.

While the machine is in FOS, the linux kernel hands it a temporary Firmware File and this is what’s causing the strangeness with the NIC.

Pulling the power cord causes the firmware to wipe. Similarly, if booting to Windows immediately after, and then powering off the machine, it should WOL. This is because Windows has a FW being applied when it loads, overwriting whatever the Linux Kernel pushed.

@bricktop135 At which stage do you get the cursor on the black screen? Can take a series of pictures or video so we see the whole boot process?

Thank you guys! It seems to be that GPT Problem. After doing the fixparts command and deleting the GPT entries now I can upload the machine 🙂

Hopefully deploying them will work in the usual way 😉

THANK YOU!

@jonathanh Excellent. Glad to help!

Marking this issue resolved (or not, no option to…)