I wonder if is a miracle that it has worked well until now in the other hardwares
I’m glad you have it working now. Yes its strange why you didn’t find another system with the same issues. But that is why I included both, I ran across a system that would boot with the netboot info alone.
Fired up my test Dell Inspiron 7559 through UEFI boot and it first failed but that was my fault. I forgot to undo all the changes to the ltsp.conf I had done on Friday. After I changed the boot files all back to ipxe.efi the Dell 7559 booted just fine to the FOG menu and also successfully registered with the FOG server using the quick registration. I guess your assumption was correct about the funky setup of the Parallels UEFI VMs. BIOS works GREAT on those VMs, it’s just the EFI boot that doesn’t get through the bzImage phase.
@AeonLucid Awesome debugging information!!! Lots of thumbs up for you. I am a bit late now but I did see the post just now. Funny that but I had the exact same thing happening with my home router when trying to debug some other iPXE stuff at home. It seams like there are DSL routers out there which send ‘next-server’ in their DHCP OFFER/ACK without handing a filename to the client. I am not sure why they do (and I guess most don’t). So your client asks for PXE boot. Gets next-server from the router DHCP and your proxy. It seams to be fine in the first run where Intel PXE ROM boots up but as iPXE comes up it uses the next-server send by your router instead of the proxy one. Run wireshark on your FOG server and you should see it in the DHCP packets broadcasted by your router (original firmware).
Instead of flashing the router you could have also build your own iPXE binary with a customized script - I talked to Tom and we might add that at some point anyway, now that we know more people see this.
Let me know if you want to know more about custom iPXE…