Hi,

We (MAAS upstream) are having some issues figuring out how to
effectively detect the architecture of a system booting using U-Boot
pxelinux emulation in order to send back an appropriate kernel and
initrd.

In short, we'd like a mechanism that is separate from the DHCP vendor
option which I believe is the only way to differentiate at the moment.

I proposed an alternative mechanism in
https://launchpad.net/bugs/1041092 (description copied below) and it was
suggested to me that I could get feedback from this list.

If this mechanism is appropriate and we can get vendor consensus on it,
then I can continue and implement the other end of it in MAAS. If it is
not suitable then I'd love to hear about alternatives. Either way, I'd
really like to move within a couple of weeks so that I can make our
12.10 release in October.

Without a non-DHCP mechanism for architecture detection, MAAS will be
stuck having to be configured for homogeneous architecture clusters
only, which would be unfortunte.

What do you think? The full text of the bug is below.

Thanks,

Robie


An outcome of a recent MAAS-related sprint is the conclusion that MAAS needs
to be able to operate in an environment where it cannot control the DHCP
server.

This means that we cannot rely on the ability to differentiate architectures
based on ISC dhcpd.conf conditional statements on vendor-class-identifier
setting alternate next-server filenames as we are doing at the moment (see bug
927781 for details of this mechanism).

Instead we need some other way for MAAS to detect the architecture of the
booting system in order to send it the correct architecture kernel/initrd.

If this doesn't happen, then MAAS will have to resort to guessing based on MAC
addresses supplied by vendors, or the user entering in the information on a
per-MAC basis manually, or the user nominating an entire MAAS cluster as
homogeneous on a particular architecture. None of these options are ideal.

Instead, I propose the following minor change to U-Boot to enable architecture
detection outside of DHCP.

The original (Intel) pxelinux.0 falls back through MAC addresses, IP address
and subnets and then to "default". Prior to U-Boot pxelinux emulation, a TFTP
server could assume that sending an i386 kernel would always work.

pxelinux emulation on other architectures breaks this assumption. So I propose
that all alternative architecture pxelinux emulators (eg. U-Boot) fall back to
"default.<arch>-<subarch>" and then "default.<arch>" before further falling
back to "default" as usual.

<arch> and <subarch> must be defined in a new pxelinux emulator namespace, and
MAAS will consequently need to map this namespace to Ubuntu's architecture and
kernel flavour names. But to start with, they'll probably match 1-1.

So: default.arm-highbank default.arm-armadaxp default.arm-omap4

For this proposed change to work, we need all vendors to take this up. I think
the change would be trivial, but I would appreciate feedback from U-Boot
maintainers and vendors before we commit to this direction.

_______________________________________________
cross-distro mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/cross-distro

Reply via email to