[Dnsmasq-discuss] pxe-service line for UEFI system?
stappers at stappers.nl
Wed Jan 22 20:28:34 GMT 2020
On Mon, Jan 20, 2020 at 11:34:01PM +0100, Michal Zatloukal wrote:
> On Mon, 20 Jan 2020 at 21:38, Geert Stappers wrote:
> > On Sun, Jan 19, 2020 at 10:40:28PM +0100, Michal Zatloukal wrote:
> > > On Sun, 19 Jan 2020 at 21:45, Geert Stappers wrote:
> > > >
> > > > Please do make the extra mile
> > > > and express how dnsmasq could be better.
> > > >
> > >
> > > What is expected of dnsmasq - a DHCP offer with either a populated
> > > menu, or a populated boot-filename option. As mentioned in the OP,
> > > currently dnsmasq provides broken menu (no items present) and empty
> > > boot-filename, unless another "phantom" boot option is also defined
> > > (in which case it provides the populated menu).
> > >
> > > I looked over the dnsmasq docs again and noticed this bit in pxe-prompt:
> > > } If --pxe-prompt is omitted the system will wait for user input if
> > > } there are multiple items in the menu, but boot immediately if there
> > > } is only one.
> > > As I understand it, if pxe-prompt is defined in the config, the
> > > services should be sent regardless of their count. So that's a bug,
> > > unless...
> > > I also looked at the changelog and found this in the 2.76 release:
> > >
> > > } Workaround problems with UEFI PXE clients. There exist
> > > } in the wild PXE clients which have problems with PXE
> > > } boot menus. To work around this, when there's a single
> > > } --pxe-service which applies to client, then that target
> > > } will be booted directly, rather then sending a
> > > } single-item boot menu.
> > >
> > > It seems like these 2 parts of the code are interacting incorrectly.
> > > 1) the pxe-service exit item is ignored, that's why the phantom option is needed
> > > 2) if pxe-prompt is explicitly defined, what _is_ supposed to happen
> > > for UEFI clients?
> > > TBH, I don't see why this UEFI issue even requires a UEFI-specific
> > > code workaround - shouldn't a config like this  avoid the problems,
> > > no code workaround needed?
> > >
> > > MZ
> > >
> > > 
> > > dhcp-match=set:efi-x86_64,option:client-arch,7
> > > dhcp-match=set:efi-x86_64,option:client-arch,9
> > > pxe-prompt=tag:!efi-x86_64,"dnsmasq PXE menu"
> > > pxe-service=7,...
> > > pxe-service=9,...
> > Seen it. I still don't understand the OP problem.
> The OP was asking if their configuration of pxe-prompt/pxe-service
> options was correct, as the UEFI client was neither booting nor
> showing the menu from the provided DHCPOFFER. A packet capture
> revealed the problem - missing PXE menu items in the provided
> DHCPOFFER. (DHCP option 43, suboption 9).
> > For some reason I do feel my wish to improve dnsmasq
> > is getting in the way. I'm gonna spend my energy elsewhere.
> > Advise to Original Poster: Make your problem reproducable.
> I'm not sure I understand - are you saying your UEFI client gets a
> DHCPOFFER with a valid PXE boot menu when you configure the following
> pxe-prompt="dnsmasq menu"
> pxe-service=7, "Boot UEFI CSA 7", efi64/syslinux.efi
> pxe-service=7, "Exit menu"
Over here is "PXE service" not used. I have no idea what I might be
missing. My reason for involvement in this thread is finding what use
case O.P. has for dnsmasq. Finding out if it can improve my use case,
finding out if it can improve dnsmasq (which also benefits me).
> > The idea of it is getting a "shared problem". And from
> > a shared problem to get to a shared solution.
> A shared problem: Make UEFI PXE client display 2 boot options - one
> for an existing boot image, and one to exit PXE (boot from disk,
My approach is default boot from disk and netbooting for a (re)install.
Back to "pxe service". It is a server-client-combo-issue.
Here on this mailinglist is dnsmasq the only common factor.
Dnsmasq is at server side. The explain the server-client-combo-issue
needs the client side extra care. So tell about client site.
That includes the risk of losing audience here due "I don't have such
clients". Increase audience numbers by "The seen behaviour can be
reproduced with this libre virtualisation platform".
Leven en laten leven
More information about the Dnsmasq-discuss