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

Shrenik Bhura shrenik.bhura at gmail.com
Fri Oct 15 13:11:23 UTC 2021


No changes need in ltsp-dnsmasq.conf . Just checked out from Petr's branch,
compiled and replaced /usr/sbin/dnsmasq with the new one.

Regards,
Shrenik

On Fri, 15 Oct, 2021, 17:16 Alkis Georgopoulos, <alkisg at gmail.com> wrote:

> @Petr, thank you very much for troubleshooting this!
>
> @Shrenik, are any changes required in ltsp-dnsmasq.conf?
> Or we just need to apply Petr's patch, compile/install, and it works?
> Thank you as well for your persistence and testing!
>
> Cheers,
> Alkis
>
> On 10/15/21 2:42 PM, Shrenik Bhura wrote:
> The below response is to be read in the thread prior to the "all success
> scenario" email.
>
> Apologies for the confusion but I only realised now that the post went
> off-list just to Petr.
>
> Regards,
> Shrenik
>
> ---------- Forwarded message ---------
> From: *Shrenik Bhura* <shrenik.bhura at gmail.com
> <mailto:shrenik.bhura at gmail.com>>
> Date: Tue, 12 Oct, 2021, 09:58
> Subject: Re: [Dnsmasq-discuss] [PATCH] Re: pxe-service entries in
> dnsmasq conf seem to fail non-proxy EFI boot
> To: Petr Menšík <pemensik at redhat.com <mailto:pemensik at redhat.com>>
>
>
> Thanks Petr for the detailed revert.
>
> I shall try again with the pxe-services branch and revert with my test
> results.
>
> Meanwhile I am trying to answer few of your queries -
>
>   > I have had trouble with proxy mode and I am not sure what is its
> purpose. Do you know when proxy mode should be used? When is it required?
>
> proxy mode is being used when we have another server/router on the same
> network that is handling dhcp and dhcp is not being done by dnsmasq
> "authoritatively". Line 29 in ltsp-dnsmasq-proxy.conf
> dhcp-range=set:proxy,192.168.2.0,proxy,255.255.255.0 takescare of that.
>
>  > It does not rely on option 43 PXE menus support, just plain old DHCP
> boot file. Requires dnsmasq to be the (authoritative?) DHCP server on
> the network.
>
> I actually had no problem with proxy mode with the current stable
> release. My only issues have been with non-proxy + efi scenarios.  So
> what you have suggested, already works for me.
>
> Just to clarify further -
> When I am testing dnsmasq in non-proxy mode I use
> ltsp-dnsmasq-noproxy.conf.
> When I am testing dnsmasq in proxy mode I use ltsp-dnsmasq-proxy.conf.
> The only difference is line 29 being commented or not respectively. I
> hope you had made the switch of the configuration and had another device
> on your network to serve dhcp requests.
>
> All the very best.
>
>
> On Tue, 12 Oct 2021 at 07:12, Petr Menšík <pemensik at redhat.com
> <mailto:pemensik at redhat.com>> wrote:
>
>      Okay, sorry for omitting others.
>
>      On 10/9/21 11:49, Shrenik Bhura wrote:
>  >     Adding Alkis and Jigish back to the thread via cc.
>  >>
>  >     On Sat, 9 Oct 2021 at 15:18, Shrenik Bhura
>  >     <shrenik.bhura at gmail.com <mailto:shrenik.bhura at gmail.com>> wrote:
>  >>
>  >         Hey Petr,
>  >>
>  >         I have read your post a few times but am only partially able
>  >         to understand everything. It may be my lack of knowledge of
>  >         the inner workings of all things involved. I shall give it a
>  >         go again later and even try the patch. But where do you want
>  >         me to apply the patch - on the master branch or on your
>  >         pxe-services branch (
>  >
> https://github.com/InfrastructureServices/dnsmasq/tree/pxe-services
>  >
> <https://github.com/InfrastructureServices/dnsmasq/tree/pxe-services>
>  >         ) ?
>  >>
>      That patch is against master from Simon's official repository. I
>      have rebased that branch on github, the change is already there. You
>      can just try that branch code as it is. That patch were more for
>      Simon, because he does not merge remote branches directly.
>  >>
>  >>
>  >         Meanwhile, from a novice point of view and from what I know
>  >         works in dnsmasq, I have this query -
>  >>
>  >         Could dnsmasq not be made to ignore the pxe-service lines or
>  >         bypass the corresponding logic from the ltsp-dnsmasq.conf when
>  >         1. is_tag_set("proxy") == "False" i.e ignore these lines -
>  >
> pxe-service=tag:proxy,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
>  >
>
> pxe-service=tag:proxy,tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
>  >
> pxe-service=tag:proxy,tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
>  >
> pxe-service=tag:proxy,tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
>  >>
>      My change attempts to do exactly that. Current released code enables
>      special handling when pxe-service is present in configuration.
>      Without any relation about required tags for it. I have tried to
>      modify it to require matching pxe-service to be found for current
>      request. In a case any service does not match, it should fallback to
>      classic DHCP. Could you try how much I were successful? This should
>      work on my pxe-services branch.
>  >>
>  >>
>  >         2. and when is_tag_set("rpi") == "False" i.e. ignore this line
>  >         or bypass corresponding logic -
>  >         pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused
>  >         when dnsmasq is processing a request in /non-proxy mode/ and
>  >         the request is from /X86-64_EFI clients/?
>  >>
>      Again, should work with my change. You should use a number to set a
>      type, with 0 being order to boot from local disk instead.
>
>      pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot   ",0
>
>      Note other pxe-services should not match rpi tag, so only above is
>      offered to RPi.
>
>
>
> pxe-service=tag:proxy,tag:!rpi,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
>
>
> pxe-service=tag:proxy,tag:!rpi,tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
>
> pxe-service=tag:proxy,tag:!rpi,tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
>
>
> pxe-service=tag:proxy,tag:!rpi,tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
>
>  >>
>  >         If possible, then everything would just work as expected for
>  >         all scenarios - *(BIOS or UEFI or RPI) and proxy*, *(BIOS or
>  >         UEFI or RPI) and non-proxy*.
>  >         It may be possible to handle this just within dnsmasq.
>  >>
>      In ipxe.efi you have sent there seems to be missing support for
>      menus defined by pxe-service (and option 43). That is a reason why
>      pxe-service and pxe-prompt is there. If you don't need those menus,
>      I would suggest using tags for
>      dhcp-match=set:efi,option:client-arch,7 instead and using just pure
>      dhcp-boot or dhcp-option=option:bootfile-name. Those should work
>      more reliably and contrary to pxe-service should work also on IPv6.
>
>      I were not successful booting with ipxe.efi built you sent and
>      pxe-service=*,X86-64_EFI,*. It just did not work on my Lenovo laptop
>      or brother's Dell. I don't have more machines to test EFI. pcbios
>      mode worked fine with menus, their support is enabled in ipxe bios
>      builds by default.
>
>  >>
>  >         Please do consider this if not already done so.
>  >>
>      I have had trouble with proxy mode and I am not sure what is its
>      purpose. Do you know when proxy mode should be used? When is it
>      required? It seems to be related to pxe-service, which I think does
>      not work reliably on EFI. Should it be possible to offer PXEClient
>      next-server and it would ask that server via pxe 4011 port? Do you
>      need it somewhere in a real world?
>
>      Would this config work instead, without any pxe-service enabled?
>
>      # Specify the boot filename for each tag, relative to tftp-root.
>      # If multiple lines with tags match, the last one is used.
>      # See: https://www.syslinux.org/wiki/index.php?title=PXELINUX#UEFI
>      <https://www.syslinux.org/wiki/index.php?title=PXELINUX#UEFI>
>      dhcp-vendorclass=set:pxe,PXEClient
>      dhcp-boot=tag:!rpi,tag:!ipxe-ok,tag:pxe,tag:X86PC,ltsp/undionly.kpxe
>
>  dhcp-boot=tag:!rpi,tag:!ipxe-ok,tag:pxe,tag:X86-64_EFI,ltsp/snponly.efi
>      dhcp-boot=tag:!rpi,tag:ipxe-ok,ltsp/ltsp.ipxe
>
>      It does not rely on option 43 PXE menus support, just plain old DHCP
>      boot file. Requires dnsmasq to be the (authoritative?) DHCP server
>      on the network.
>
>      Hope that helps.
>
>      Cheers,
>      Petr
>
>  >>
>  >         Thanks,
>  >         Shrenik
>  >>
>  >         On Sat, 9 Oct 2021 at 03:43, Petr Menšík <pemensik at redhat.com
>  >         <mailto:pemensik at redhat.com>> wrote:
>  >>
>  >             I have made some attempts at PXE booting. I have to say,
>  >             it is a mess.
>  >>
>  >             Put my booting attempts at fedorapeople [1]. I have asked
>  >             on #ipxe IRC
>  >             channel. It seems pxe-service works only on biospc,
>  >             client-arch == 0. I
>  >             were able to make simple menu on my father's lenovo
>  >             desktop and my work
>  >             Thinkpad 490s. One instance of Raspberry 3. In Legacy
>  >             mode, it works
>  >             somehow well. You are even to make local boot menu
>  >             entries. I made it
>  >             possible to boot to memtest just fine.
>  >>
>  >             However, any my attempt in EFI mode to boot using menus
>  >             failed. There is
>  >             special function pxe_uefi_workaround, but to me it did not
>  >             work. Current
>  >             code did never return reply from pxe port request. Because
>  >             my laptop
>  >             does not send option 43 stuff in ipxe.efi request and I
>  >             have not used
>  >             proxy, it just does not answer. I were able to make it
>  >             return something.
>  >             It seems not well supported and should be avoided.
>  >>
>  >             Guys at ipxe channel told me EFI does not include option
>  >             43 menu
>  >             support, which seems to be true. At that results, I think
>  >             pxe-service
>  >             should be in general avoided if you want to support EFI.
>  >             Just use tags
>  >             to offer first boot-file as ipxe.efi, then use ipxe script
>  >             with possible
>  >             menus inside. That seems to be more reliable and well
>  >             documented way.
>  >>
>  >             I have fixed previous patch, it has to offer just based on
>  >             boot item
>  >             supplied type. Client arch is not always sent in a
>  >             request, even when it
>  >             is always present in discover, as I have noticed in
>  >             Shrenik's dumps. I
>  >             think that patch makes improvement and allows pxe-service
>  >             work just for
>  >             platforms related. Others should use dhcp-file with tags,
>  >             depending on
>  >             their clients.
>  >>
>  >             Custom setting of tags depending on option:client-arch
>  >             seems to be more
>  >             understandable and reliable.
>  >>
>  >             I have had enough of PXE today.
>  >>
>  >             Cheers,
>  >             Petr
>  >>
>  >             1. https://pemensik.fedorapeople.org/dnsmasq/
>  >             <https://pemensik.fedorapeople.org/dnsmasq/>
>  >>
>  >             On 10/7/21 23:10, Simon Kelley wrote:
>  >             > As an aside the the discussion, can I just point out
>  >             that I don't have
>  >             > any way to test any of this dnsmasq functionality at the
>  >             moment, and I'm
>  >             > very rusty on the PXE spec, especially as it relates to
> EFI.
>  >             >
>  >             > I don't therefore have much to contribute to this
>  >             discussion, but I do
>  >             > think this is valuable work, and when you find a
>  >             solution, I'll give the
>  >             > resulting patchset my full attention.
>  >             >
>  >             >
>  >             > Cheers,
>  >             >
>  >             > Simon.
>  >>
>      --
>      Petr Menšík
>      Software Engineer
>      Red Hat,http://www.redhat.com/  <http://www.redhat.com/>
>      email:pemensik at redhat.com  <mailto:pemensik at redhat.com>
>      PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211015/d68c1960/attachment-0001.htm>


More information about the Dnsmasq-discuss mailing list