[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
Sat Oct 16 05:21:10 UTC 2021
@Alkis Georgopoulos <alkisg at gmail.com> Though no changes may be needed in
the existing ltsp-dnsmasq.conf, I just recalled that I had made some
modifications (lines 35-54) in mine for the sake of clarity for any future
hardware specific scenarios that I may encounter. Herein is attached the
no-proxy version of the same.
On Fri, 15 Oct 2021 at 18:41, Shrenik Bhura <shrenik.bhura at gmail.com> wrote:
> 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/20211016/a1e72fa3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltsp-dnsmasq-noproxy.conf
Type: application/octet-stream
Size: 3459 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211016/a1e72fa3/attachment-0001.obj>
More information about the Dnsmasq-discuss
mailing list