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, <alk...@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.bh...@gmail.com > <mailto:shrenik.bh...@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 <pemen...@redhat.com <mailto:pemen...@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 <pemen...@redhat.com > <mailto:pemen...@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.bh...@gmail.com <mailto:shrenik.bh...@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 <pemen...@redhat.com > > <mailto:pemen...@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:pemen...@redhat.com <mailto:pemen...@redhat.com> > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > >
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
