[Dnsmasq-discuss] Fwd: [PATCH] Re: pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Alkis Georgopoulos
alkisg at gmail.com
Fri Oct 15 11:46:26 UTC 2021
@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
More information about the Dnsmasq-discuss
mailing list