[Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot

Shrenik Bhura shrenik.bhura at gmail.com
Wed Oct 6 07:14:52 UTC 2021

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 (
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 -
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 -
The dnsmasq conf that works is also attached below -
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,

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211006/759f7397/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltsp-dnsmasq-default-with-pxe-service.conf
Type: application/octet-stream
Size: 2710 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211006/759f7397/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltsp-dnsmasq-default-without-pxe-service.conf
Type: application/octet-stream
Size: 2715 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211006/759f7397/attachment-0003.obj>

More information about the Dnsmasq-discuss mailing list