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 > [email protected] > http://lists.linaro.org/mailman/listinfo/cross-distro > _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
