<div dir="ltr"><div>Hi all,</div><div><br></div><div>Alkis has highlighted the main question once again. Thanks Alkis.</div><div><br></div><div>Now trying to provide the answers to Petr's queries - <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
It seems to me the answer lies only on its boot rom
firmware. I just expect both used matching configuration and
dnsmasq version.
</div></blockquote><div><br></div><div>This is the case with an Intel NUC NUC5CPYH mini PC, Dell Optiplex 3040 desktop PC and an old Thinkpad X1 laptop. So definitely not a unique case with just one boot ROM firmware. But works fine with qemu. It is because qemu "uses iPXE to implement the VM's PXE firmware".[1] <br></div><div>So comparison with output from qemu is not an ideal one. Maybe Alkis can help with the pcap and logs from efi hardware that is booting fine in the non-proxy mode.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Does it fail with any error code? Does
it print any error? At least screenshot would be useful. It seems
to me the problem is somewhere in its PXE implementation, which we
cannot solve in dnsmasq.
</div></blockquote><div><br></div><div>This is visible on the screen for a very brief period of time -<br></div><div>
<span><tt>PXE-E21:
Remote boot cancelled.</tt></span>
</div><div><br></div><div>Once again, it doesn't seem to be a very specific problem in only a specific hardware's PXE implementation since I am experiencing it in hardware from several vendors. An extra observation - all my test hardwares' manufacturing is older than 2017.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Because it even does not try to download
and execute snponly.efi, even iPXE build with debug logs (which I
am not sure how to enable btw) would not help.
</div></blockquote><div><br></div><div>Based on your earlier guidance, we had enabled the iPXE logging as per the instructions on their website but yet got nothing helpful for the failed cases to diagnose this issue. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Does it have the latest bios firmware
available? Would this machine boot at least snponly.efi if
pxe-service were commented out?
</div></blockquote><div><br></div><div>Yes, the Intel NUC has the latest BIOS firmware from 2019. Thereafter, this hardware has reached end-of-life and Intel no longer provides support for it. Yes, this machine boots perfectly fine with pxe-service commented out.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
It seems similar to previous
intel_nuc_efi_with_ltsp-pxeservice.pcapng file requests, but it
does use proxyDHCP requests like the old one. </div></blockquote><div><br></div><div>The nuc-efi.pcapng shared (<a href="https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing">https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing</a>) in the last email is from a similar model Intel NUC NUC5CPYH machine but not the exact same device. As you had correctly pointed out, the intel_nuc_efi_with_ltsp-pxeservice.pcapng was the wrong file that I had shared earlier via this link - <a href="https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing">https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing</a> on 27th September. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>How changed dnsmasq
configuration to make this change? How does dnsmasq.conf look like
for it?
</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Used config
file of dnsmasq is not attached this time, I can only guess. HW
address is different, not sure how different is used machine. <br></div></blockquote><div><br></div><div>The dnsmasq conf that does not work is attached below - ltsp-dnsmasq-default-with-pxe-service.conf</div><div>The dnsmasq conf that works is also attached below - ltsp-dnsmasq-default-without-pxe-service.conf</div><div>HW address is different because we used another device of the same model as already stated above.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Was it this machine, which returned <span><tt>PXE-E21:
Remote boot cancelled.<span style="font-family:arial,sans-serif">?</span></tt></span><span style="font-family:arial,sans-serif">
</span>Returned control to LoadFile control seems suspicious. May it require non-efi image instead? If you can reach support for this machine, I think it might be reported to them. Especially about how PXE menu can specify Local Boot?</div></blockquote><div><br></div><div>Yes, all machines that I have tested booting with EFI booting in non-proxy mode are returning this. All these machines boot fine with BIOS in non-proxy mode i.e. when supplied with undionly.kpxe instead of snponly.efi. Support for any of my test machines is not available any more from the hardware vendors as the models have all reached end-of-life. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> If one machine can boot with the same setup that another cannot, it is up to you to find commonly working configuration.</div></blockquote><div><br></div><div>I don't have any machine that boots and I would not count QEMU as a worthy comparison for this case.[1] <br></div><div>@Alkis, may I request you to provide the pcap and logs for a case where an efi client boots successfully in non-proxy mode?</div><div>and / or </div><div>@Petr is it possible to try simulating the same scenario at your end with the provided conf files?</div><div><br></div><div>Thanks & regards,<br></div><div>Shrenik<br></div><div><br></div><div>[1]<i> As a special case (in a positive sense), when PXE-booting a KVM virtual machine the very first request that the server sees already comes from iPXE, since that's what qemu uses to implement the VM's PXE "firmware".</i> - from <a href="https://backreference.org/2013/11/24/pxe-server-with-dnsmasq-apache-and-ipxe/">https://backreference.org/2013/11/24/pxe-server-with-dnsmasq-apache-and-ipxe/</a><br></div></div>