[Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents

[Dreamcat4]

On Sat, May 7, 2016 at 9:49 PM, Simon Kelley <simon at thekelleys.org.uk>
wrote:

> On 06/05/16 12:58, Jaroslaw Polok wrote:
> > Hi
> >
> > On 06/05/16 12:40, Dreamcat4 wrote:
> >
> >>
> >> Perhaps later down the line (once more people get onboard and can start
> >> using it), then this pxe UEFI mode can be improved even further. Either
> >> buy some fresh eyes coming along to fix problems in ipxe.efi, or else
> >> here in the dnsmasq behaviour. Or both. But we need to make it easier
> >> for those guys to run it at least, so can see ahead to the next problem.
> >
> > In case you would be interested:
> >
> >
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html
> >
> > That is my version of the patch, using a configuration option
> > to allow more fine-grained control on how systems boot
> > (by optionally matching by tag and/or architecture).
> >
> > We are using that patch in production since two months
> > successfully booting all PXE/UEFI systems (x64 and aarch64)
> > we have used so far (about 10 different x64 and 3 different
> > aarch64 systems, plus qemu-kvm with Tianocore firmware)
> >
> > Dear Simon: would it be possible to review and include one
> > of this patches in dnsmasq please ?
> >
>
>
> Yes, That's the last thing on my list to do before I start to release
> 2.76. You and Dreamcat are going to have to help me though, since I
> don't have a usable test environment for this stuff, and my PXE
> knowledge is buried under several years of other stuff.
>

No problem, happy to help.

My main question is, is there a way to make this work without needing
> the --pxe-skip-menu option. I appreciate that this engages a workaround
> for buggy UEFI netboot implementations, but what's wrong with doing that
> automatically when there's only one possible boot?


Yeah I was thinking that too. But then I looked more carefully at Jarek's
patch this morning. And it gets me to understanding why he made the option
that way around.

It is a lot to do with how-to-set-options in dnsmasq (the options
conventions of your program).


> Are we loosing
> functionality (maybe with a hypothetical fully working BIOS) by doing that?
>

OK lets start with what we know:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

is the best thing to cover all of the regular PC users. Which is nearly
everybody. That is great.


====
Now lets imagine we take away the option. So there is no exposed option
whatsoever.  New Drawback:

we cannot accomodate the situation where there are different behaving
clients identifying under a single CSA type. Which seems to be the case
(already known) for BC_EFI.

http://serverfault.com/questions/349693/pxe-architecture-bc-efi

What that link says ^^ is that BC_EFI is a non-descript (generic) client.
Which may be odd ones, like an old PowerPC mac or IBM PowerPC server. Or
equally it could be some early x86 UEFI client. That is a potential to need
to be flipped on/off a case-by-case basis. Depending upon the specific set
of client hardware models which exist at that site.

It may be true or false for lesser CSA types too. (depending the model of
hardware). 2nd example I can think of now is ARM64 uefi. Because IPXE
project just added support for ARM64 efi booting. For devices like rPi /
similar - very popular now. Don't see it listed as a CSA named type. Maybe
its going to identify as some new (higher) CSA number. Else re-use again
that generic catchall BC_EFI (yet again).

That is why I think having some kind of a user setting might be worth it.
For best comptibility to all users. We cannot be expected to know / test
all possible hardware. And there are many types of speciality devices /
quirky hardware.

But it is bad for each UEFI pc users going forwards to know to need to
manually specify:

pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI

Every time around. Because that is nearly everybody going forwards. How to
solve? Can we then make the option logic work better?

===
What about this idea:


Solution Part a)

Modify existing patch, make it a single string list of all CSAs for doing
pxe-skip-menu.

* Default value:

pxe-skip-menu="X86-64_EFI, BC_EFI".

* So if user says nothing, it 'just works'. If its wrong, simple for other
guys to come along later, tell us to update the setting ^^. Like to add
another one etc.

* User can overide it however they wish. To cover any quirky hardware they
might have (including to omit the troublesom BC_EFI on a per-user basis):

pxe-skip-menu="<CSA1>,<CSA2>"


Solution Part b)

Add in to the man page a clear paragraph, saying what is the SYMPTOM (of a
UEFI hanging boot). Which is exactly why / when the user should be setting
this option to override the mask list of CSAs.




> Cheers,
>
> Simon.
>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160508/43b969e9/attachment.html>