<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 7, 2016 at 9:49 PM, Simon Kelley <span dir="ltr"><<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 06/05/16 12:58, Jaroslaw Polok wrote:<br>
> Hi<br>
><br>
> On 06/05/16 12:40, Dreamcat4 wrote:<br>
><br>
>><br>
>> Perhaps later down the line (once more people get onboard and can start<br>
>> using it), then this pxe UEFI mode can be improved even further. Either<br>
>> buy some fresh eyes coming along to fix problems in ipxe.efi, or else<br>
>> here in the dnsmasq behaviour. Or both. But we need to make it easier<br>
>> for those guys to run it at least, so can see ahead to the next problem.<br>
><br>
> In case you would be interested:<br>
><br>
> <a href="http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010383.html</a><br>
><br>
> That is my version of the patch, using a configuration option<br>
> to allow more fine-grained control on how systems boot<br>
> (by optionally matching by tag and/or architecture).<br>
><br>
> We are using that patch in production since two months<br>
> successfully booting all PXE/UEFI systems (x64 and aarch64)<br>
> we have used so far (about 10 different x64 and 3 different<br>
> aarch64 systems, plus qemu-kvm with Tianocore firmware)<br>
><br>
> Dear Simon: would it be possible to review and include one<br>
> of this patches in dnsmasq please ?<br>
><br>
<br>
<br>
</span>Yes, That's the last thing on my list to do before I start to release<br>
2.76. You and Dreamcat are going to have to help me though, since I<br>
don't have a usable test environment for this stuff, and my PXE<br>
knowledge is buried under several years of other stuff.<br></blockquote><div><br>No problem, happy to help.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My main question is, is there a way to make this work without needing<br>
the --pxe-skip-menu option. I appreciate that this engages a workaround<br>
for buggy UEFI netboot implementations, but what's wrong with doing that<br>
automatically when there's only one possible boot?</blockquote><div><br>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.<br><br>It is a lot to do with how-to-set-options in dnsmasq (the options conventions of your program).<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Are we loosing<br>
functionality (maybe with a hypothetical fully working BIOS) by doing that?<br></blockquote><div><br></div><div>OK lets start with what we know:<br></div><div><br>pxe-skip-menu=X86-64_EFI<br>pxe-skip-menu=BC_EFI<br><br></div><div>is the best thing to cover all of the regular PC users. Which is nearly everybody. That is great.<br><br><br>====<br>Now lets imagine we take away the option. So there is no exposed option whatsoever.  New Drawback: <br><br>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.<br><br><a href="http://serverfault.com/questions/349693/pxe-architecture-bc-efi">http://serverfault.com/questions/349693/pxe-architecture-bc-efi</a><br><br>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.<br><br></div><div>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).<br><br>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.<br></div><div><br></div><div>But it is bad for each UEFI pc users going forwards to know to need to manually specify:<br><br>pxe-skip-menu=X86-64_EFI<br>pxe-skip-menu=BC_EFI<br><br></div><div>Every time around. Because that is nearly everybody going forwards. How to solve? Can we then make the option logic work better?<br><br>===<br>What about this idea:<br><br><br>Solution Part a)<br><br>Modify existing patch, make it a single string list of all CSAs for doing pxe-skip-menu.<br><br>* Default value:<br><br>pxe-skip-menu="X86-64_EFI, BC_EFI".<br><br><div>* 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.<br></div><br>* 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):<br><br>pxe-skip-menu="<CSA1>,<CSA2>" <br><br></div><br>Solution Part b)<br></div><div class="gmail_quote"><div><br>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.<br><br><br> </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
<br>
Simon.<br>
<div><div><br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</div></div></blockquote><div> </div></div></div></div></div>