On 08/30/2012 01:42 AM, Robie Basak wrote:
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 the DHCP string, we're currently using armv7 as part of it. Is arm too generic? With "single" kernels, we will have armv4/5, armv6/7, armv7, armv7-pae and armv8 kernels. Or will subarch just become v4, v7, v8, etc.?
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.
In general, I'm fine with this change, and it is fairly trivial.
Rob
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro