maas-builds team mailing list archive

[Jeroen Vermeulen <jeroen.vermeulen@xxxxxxxxxxxxx>]

On 02/26/2014 11:01 PM, Raphaël Badin wrote:

> What happens, apparently, is that the amd64 nodes are given an ARM kernel:
> 2014-02-26 04:16:36-0500 [TFTP (UDP)] Datagram received from
> ('192.168.21.14', 49163):
> <RRQDatagram(filename=armhf/generic/trusty/commissioning/linux,
> mode=octet, options={'tsize': '0', 'blksize': '1408'})>
> 
> We suspect that BootImage.objects.get_default_arch_image_in_nodegroup()
> (called from src/maasserver/api.py:pxeconfig) might be responsible for
> this but haven't got to the bottom of it yet. This needs further
> investigation.

This is what happens when the call to pxeconfig() specifies no 'arch',
and the call is for/from an unknown node.  Which I guess is the normal
situation for an enlistment boot.

The comment in pxeconfig() says that
get_default_arch_image_in_nodegroup() falls back to i386 as a default,
but that is simply not true.  It picks the first architecture in
alphabetical order — inane, but good enough for what its docstring promises.

One thing that would cause this to break is a change in architectures
that we import images for.  For example, if we previously had amd64,
armhf, and i386 images, but the amd64 one went missing somehow.  The
fact that amd64 comes before armhf in the alphabet would hide the
problem until the amd64 image disappeared.

How could that happen?  Well, get_default_arch_image_in_nodegroup()
looks for images for a specific release and purpose.  The purpose would
be "commissioning" and the release would be the commissioning series —
which we just changed from "precise" to "trusty."  So, if we had no
commissioning images for Trusty on amd64, we'd see this error.  Do we
have those images?  And do we run the import script as part of the tests?

Meanwhile, I'm putting up a branch to make
get_default_arch_image_in_nodegroup() prefer i386 like that comment says.


Jeroen