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

Shrenik Bhura shrenik.bhura at gmail.com
Sat Oct 9 09:49:34 UTC 2021

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> 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 ) ?
> 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
> 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*?
> 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.
> Please do consider this if not already done so.
> Thanks,
> Shrenik
> On Sat, 9 Oct 2021 at 03:43, Petr Menšík <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/
>> 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.
>> >
>> > _______________________________________________
>> > Dnsmasq-discuss mailing list
>> > Dnsmasq-discuss at lists.thekelleys.org.uk
>> >
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>> >
>> --
>> Petr Menšík
>> Software Engineer
>> Red Hat, http://www.redhat.com/
>> email: pemensik at redhat.com
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211009/ce8af57c/attachment.htm>

More information about the Dnsmasq-discuss mailing list