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

Shrenik Bhura shrenik.bhura at gmail.com
Mon Sep 27 16:11:59 UTC 2021


My bad. Just realised that my previous post with logs and pcap dumps has
been held for moderator approval.

Herein is the post again with links to the files -

It does seem that dhcp-boot is being reached even when pxe-service is
successfully executed. Taking a hint from this discussion on UEFI and PXE (
https://bbs.archlinux.org/viewtopic.php?id=237655), we tried this custom
configuration -

pxe-prompt="Press any key for boot menu",2
pxe-service=X86-64_EFI,"PXELINUX (X86-64_EFI)",ltsp/snponly.efi
pxe-service=7,"PXELINUX (EFI)",ltsp/snponly.efi
dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe
dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi
dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe

(full file included in the link below)

Server does proceed to offering ltsp.ipxe to the client via dhcp but is
eventually not being transferred via tftp.

Have attached logs, pcap and dnsmasq configuration of three scenarios -
1. Default dnsmasq config with default ltsp's pxe-service entries -
https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing
2. Custom pxe-service entries -
https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing
3. Without pxe-service entries -
https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing

We have tested these with two systems - Intel NUC and Dell Optiplex 3040
with their updated firmware and have found the same results.

I hope this helps to zoom further into the problem area.

Best regards,
Shrenik


On Mon, 27 Sept 2021 at 20:56, Shrenik Bhura <shrenik.bhura at gmail.com>
wrote:

>
> Hi Petr,
>
> The proposed config (also given below) doesn't work in non-proxy mode. I
> tested it with a RPi 4B and Intel NUC in non-proxy mode.
>
>
>
>
> *pxe-service=tag:!iPXE,X86PC,ltsp/undionly.kpxe
> pxe-service=tag:!iPXE,X86-64_EFI,ltsp/snponly.efi
> pxe-service=tag:iPXE,X86PC,ltsp/ltsp.ipxe
> pxe-service=tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe*
> *# fallback for BIOS-only clients without PXE support*
> * dhcp-boot=tag:!iPXE,ltsp/undionly.kpxe*
>
> On NUC*, *we get this after fetching IP -
> PXE-E77: Bad or missing discovery server list
>
> On RPi it endlessly loops at -
> [43:9]: 'ltsp/undionly.kpxe   '
>
> However, your proposed config works fine in proxy mode with just one
> addition for RPi -
> pxe-service=tag:rpi,X86PC,unused
>
> But this is already known and that's why tag:proxy was introduced to bring
> into play pxe-service only when using in proxy mode.
>
> I have this more precise finding and at the risk of repeating myself -
> With the below configuration in non-proxy mode, RPi and Intel NUC boot
> BIOS boot fine but Intel NUC in UEFI mode doesn't.
> pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot    ",unused
> dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe
> dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi
> dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe
>
> However, if I just comment out the pxe-service line, all works fine for
> Intel NUC in BIOS and UEFI mode but now RPi won't boot. This is exactly
> what I had started this thread with. Hence I shared the pcap dump and logs
> in the previous post.
>
> Best regards,
> Shrenik
>
>
> On Mon, 27 Sept 2021 at 19:40, Petr Menšík <pemensik at redhat.com> wrote:
>
>> I think this should have been:
>>
>> pxe-service=tag:!iPXE,X86PC,ltsp/undionly.kpxe
>> pxe-service=tag:!iPXE,X86-64_EFI,ltsp/snponly.efi
>> pxe-service=tag:iPXE,X86PC,ltsp/ltsp.ipxe
>> pxe-service=tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe
>> # fallback for BIOS-only clients without PXE support
>> dhcp-boot=tag:!iPXE,ltsp/undionly.kpxe
>>
>> Does LTSP still support booting outside PXE standard? Does it need to be
>> supported? I think only non-PXE capable clients should fall back to to
>> dhcp-boot parameters. All others should have some pxe-service entry.
>> Current code does not allow different configuration I think. Even without
>> iPXE, PXEClient will get boot parameter ONLY from pxe-service. It would get
>> dhcp-boot parameter only if there is no pxe-service used at all.
>>
>> It seems pxe-service is IPv4 only at the moment. Any device trying to
>> boot over IPv6 would probably boot only using:
>>
>> dhcp-option=option6:bootfile-url,ltsp/ltsp.ipxe
>>
>> Which is a bit sad. I guess only input parameters and output options are
>> somehow different. But it should offer similar paths also on IPv6. Maybe
>> time would be found sometime to implement also IPv6 support.
>>
>> Cheers,
>> Petr
>> On 9/25/21 13:14, Shrenik Bhura wrote:
>>
>> Hi Geert,
>>
>> Your advice doesn't seem to work. Gives an error on the very first line
>> that has been changed.
>> tag:!iPXE,X86PC,ltsp/undionly.kpxe
>>
>> Thanks,
>> Shrenik
>>
>> On Fri, 19 Mar, 2021, 15:54 Geert Stappers via Dnsmasq-discuss, <
>> dnsmasq-discuss at lists.thekelleys.org.uk> wrote:
>>
>>> On Fri, Mar 19, 2021 at 11:05:05AM +0200, Alkis Georgopoulos wrote:
>>> > Hi all,
>>>
>>> ;-)
>>>
>>>
>>> > I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq
>>> > mailing list because I feel this might be a dnsmasq issue.
>>> >
>>> > Specifically, success or failure depends on whether these five lines
>>> are
>>> > commented out or not:
>>> >
>>> >
>>> #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
>>> >
>>> #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
>>> > #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
>>> > #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
>>> > #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot   ",unused
>>> >
>>> > You may find the full configuration files and logs at:
>>> > https://github.com/ltsp/ltsp/pull/417
>>> >
>>> > The reason I feel it might be a dnsmasq issue, is that these tags are
>>> NOT
>>> > matched in Shrenik's use case. He's not using proxy mode and he's not
>>> > booting a Raspberry Pi.
>>> >
>>> > So, "pxe-service" lines that are NOT matched, cause the problem,
>>> > yet if they're commented out, the problem is gone...
>>> >
>>> > Would that be an issue with dnsmasq, or with the UEFI PXE stack?
>>>
>>> I go for something inbetween:
>>>   UEFI PXE stack insisting on something that dnsmasq **configuration**
>>>   doesn't yet provide. Or server side **configuration** is something
>>>   that the client can't handle.
>>>
>>>
>>> Advice:
>>>   Leave out `pxe-service`, skip "PXE". Yes, do  iPXE    ;-)      [1]
>>>
>>> Transform
>>> |
>>> #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
>>> |
>>> #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
>>> | #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
>>> | #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
>>> | #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot   ",unused
>>> into something like[2]:
>>> | tag:!iPXE,X86PC,ltsp/undionly.kpxe
>>> | tag:!iPXE,X86-64_EFI,ltsp/snponly.efi
>>> | tag:iPXE,X86PC,ltsp/ltsp.ipxe
>>> | tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe
>>> | tag:rpi,X86PC,unused
>>>
>>>
>>> Request:
>>>   Report back
>>>
>>>
>>>
>>> Groeten
>>> Geert Stappers
>>> Voetnoten:
>>>  [1] iPXE  stands for  "It doesn't do PXE"
>>>  [2] actual syntax not verified
>>> --
>>> Silence is hard to parse
>>>
>>> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing listDnsmasq-discuss at lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>
>> --
>> Petr Menšík
>> Software Engineer
>> Red Hat, http://www.redhat.com/
>> email: pemensik at redhat.com
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210927/a5deceff/attachment-0001.htm>


More information about the Dnsmasq-discuss mailing list