[Maas-devel] Support for ARM PXE booting, esp. in absence of control over DHCP

[Gavin Panella]

I just had a discussion with Robie Basak about PXE booting ARM
servers, and these are my notes. I'll cement these into a spec (or add
them to an existing spec) once everyone has had a chance to comment.

Right now, MAAS assumes that it controls DHCP on a network. It runs
the ISC DHCP server, and there's configuration in there to select the
bootloader depending on the vendor-class-identifier option.

However, we can no longer assume that we have control of DHCP, so we
cannot dispatch to a different bootloader depending on the vendor
class. Robie and I tried to come up with ways around this, and we came
up with a few options:

1. Modify U-Boot to fetch default.${arch} before default.

2. Use a MAC address database to lookup machine arch.

3. Embed Lua in U-Boot. It is already available for PXELINUX.


default.${arch} before default
------------------------------

PXELINUX - and U-Boot's PXELINUX simulation - request paths on the
TFTP server in order, until one is found:

    /mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
    /mybootdir/pxelinux.cfg/C000025B
    ...
    /mybootdir/pxelinux.cfg/C
    /mybootdir/pxelinux.cfg/default

We would submit a patch to U-Boot to ask that it requests
default.${arch} before requesting default.

The downside with this is that it requires upstream acceptance of the
change, and requires hardware manufacturers to pull in those changes,
either of which might stall or fail.


MAC database
------------

We could maintain a database of MAC addresses with their hardware
types (and other metadata, if it's interesting), and ship this with
MAAS. The dynamic TFTP server would refer to it when rendering the PXE
config file. Hardware manufacturers would provide the data for this,
but it could be augmented on-site too.

This is fairly low-tech and cheap to implement, but would be very
effective.


Embed Lua
---------

SYSLINUX/PXELINUX has a lua.c32 module to run a Lua interpreter,
allowing programmatic control of the boot sequence. Lua is
architecture independent, and the interpreter is designed to be very
easy to embed, so Lua could perhaps be added to U-Boot.

This would provide truly cross-platform boot control, and could be
considered an ideal goal, but it's exposed to similar constraints as
the default.${arch} solution: cooperation with upstream and
manufacturers.


Next steps
----------

Robie is going to follow up on the default.${arch} and Lua options,
and the Red Squad can follow up on the MAC database. The latter is
probably worth adding regardless, as a simple catch-all solution. It
may end up being all we need.