Hi all, Alkis has highlighted the main question once again. Thanks Alkis.
Now trying to provide the answers to Petr's queries - It seems to me the answer lies only on its boot rom firmware. I just expect > both used matching configuration and dnsmasq version. > 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] 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. 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. > This is visible on the screen for a very brief period of time - PXE-E21: Remote boot cancelled. 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. 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. > 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. Does it have the latest bios firmware available? Would this machine boot at > least snponly.efi if pxe-service were commented out? > 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. It seems similar to previous intel_nuc_efi_with_ltsp-pxeservice.pcapng file > requests, but it does use proxyDHCP requests like the old one. > The nuc-efi.pcapng shared ( https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing) 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 - https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing on 27th September. > How changed dnsmasq configuration to make this change? How does > dnsmasq.conf look like for it? > 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. > The dnsmasq conf that does not work is attached below - ltsp-dnsmasq-default-with-pxe-service.conf The dnsmasq conf that works is also attached below - ltsp-dnsmasq-default-without-pxe-service.conf HW address is different because we used another device of the same model as already stated above. Was it this machine, which returned PXE-E21: Remote boot cancelled.? 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? > 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. If one machine can boot with the same setup that another cannot, it is up > to you to find commonly working configuration. > I don't have any machine that boots and I would not count QEMU as a worthy comparison for this case.[1] @Alkis, may I request you to provide the pcap and logs for a case where an efi client boots successfully in non-proxy mode? and / or @Petr is it possible to try simulating the same scenario at your end with the provided conf files? Thanks & regards, Shrenik [1]* 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".* - from https://backreference.org/2013/11/24/pxe-server-with-dnsmasq-apache-and-ipxe/
ltsp-dnsmasq-default-with-pxe-service.conf
Description: Binary data
ltsp-dnsmasq-default-without-pxe-service.conf
Description: Binary data
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
