[Dnsmasq-discuss] Fwd: [PATCH] Re: pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
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.
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!
> 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.
> ---------- 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
> 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
> 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 (
> > ) ?
> 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 -
> 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.
> > 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
> 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.
> > 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 . 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
> > >
> > > 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...
More information about the Dnsmasq-discuss