On Mon, Jan 23, 2017 at 09:57:28PM +1100, Jonathan Gray wrote:
> On Mon, Jan 23, 2017 at 08:39:17PM +1000, Jonathan Matthew wrote:
> > For network boot clients, dhcpd(8) can supply a filename for the initial
> > boot file for the client, which is something like pxeboot (or pxelinux.0).
> > EFI and BIOS clients need different boot files, though, so the server
> > needs to know what mode the client is booting in, in order to supply the
> > right filename. RFC 4578 defines DHCP client option 93 for this purpose.
> >
> > The ISC dhcpd approach to using this looks something like this:
> >
> > option arch code 93 = unsigned integer 16;
> >
> > if option arch = 00:00 {
> > filename "bios/pxelinux.0";
> > } elsif option arch = 00:07 {
> > filename "efi.x64/syslinux.efi";
> > }
> >
> > which seems a bit complicated, and also a lot of work to implement. Instead
> > I propose adding 'efi-filename' (and 'efi32-filename', though I'm not sure
> > that's worth doing) next to the existing 'filename' statement and having
> > dhcpd itself interpret the option values to figure out which one should be
> > used.
> >
> > I don't actually need this yet because we don't have many EFI-only client
> > machines, so we can just run everything in legacy mode, but some day this
> > may change.
> >
> > Does this seem reasonable?
>
> How will values 10 (32 bit arm) and 11 (64 bit arm) be handled
> in future if this went in? Wouldn't it be better to map the arch numbers
> to strings?
>
> The uefi spec refers to
> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#processor-architecture
> Which also lists different numbers for PXE vs boot from HTTP.
If we have more than a couple of architectures to deal with, we probably
need something smarter. Adding arm-filename and arm64-filename in the
same way seems ugly. I don't think our dhcpd has any existing mechanisms
that would support this kind of thing, so some actual thought may be
required.
