Comment 12 for bug 1752687

Andres, the fragments you're seeing in the pcap file look like GRUB code to me. Keep in mind that's just a raw capture of EVERYTHING that passed over the MAAS server's local interface for the time during which I was booting the node, so that includes the GRUB binary that was passed from the MAAS server to the node, and even a few interactions with unrelated machines. You'd need to use wireshark or something similar to properly decode it.

As noted in my comment #9, above, it looks to me like ARP responses from the MAAS server are getting lost by the node AFTER GRUB has been (presumably successfully, although I've not tried to analyze the tcpdump results to verify this) delivered to the node. This could be a GRUB bug, a Quanta firmware bug, or a bug in how the two interact with each other. Then too, my knowledge of how they all interact is limited, so my conclusion may be in error.

As to the rest, both Jeff and I tried completely disabling each of the machine's two network ports (they're 10Gbps fiber connections, FWIW). In some of my own tests, I tried typing "exit" at the "grub>" prompt. When both ports were enabled, this resulted in a second boot attempt, presumably one from each device. The TFTP request log snippet you've quoted looks consistent with one of those runs.

Other EFI machines do work fine; I deployed two yesterday, for instance. (They were both Quanta machines, but a different model.)