enlistment fails: /tmp/sh.UZ7qJT/bin/maas-enlist: archdetect: not found

[dann frazier]

MAAS Version 2.0.0 (beta2+bzr4882)
commissioning release = xenial
image stream = daily
Architecture: arm64

Enlistment has started failing, though it worked before (~week ago?). See the attached log. I was able to workaround this by manually installing archdetect-deb into my root-image. I'm wondering if MAAS is maybe depending on archdetect-deb being installed in the maas images, and for some reason it has been removed. Perhaps maas should be explicitly installing this dependency itself?

[Sean Feole (sfeole)]

This bug also affects Maas 1.9.1 that currently lives in ppa lp:maas/stable for trusty.

[Andres Rodriguez (andreserl)]

Hi Dann,

This may be an issue with the arm64 image actually, rather than MAAS. I'll verify with daily images of amd64... but on my latest tests I have not seen this issue.

[Andres Rodriguez (andreserl)]

Ok, I've tested with latest xenial image, and I've been unable to reproduce this issue.

[Scott Moser (smoser)]

I marked this 'wont fix' for maas-images.
MAAS sends the maas_enlist script to cloud-init to execute (etc/maas/templates/commissioning-user-data/snippets/maas_enlist.sh)
It is up to that program to make sure it can run. The images have not had archdetect in them for probably almost all of xenial cycle and probably part of wily.

The maas images now are exactly same content of cloud images and we dont want to change that. We also do not want to arbitrarily add packages to cloud images.

So, the suggestion i have is to have maas either
a.) work around this by implementing the same logic in that script that archdetect does (i suspect its fairly easily done with dpkg and some checks in /sys)
b.) install it if it is not there:
   which arch-detect || apt-get install archdetect || fail "sorry!"

[dann frazier (dannf)]

+1 - maas already installs things it explicitly calls - e.g. freeipmi - seems like archdetect-deb should be installed the same way.

[dann frazier (dannf)]

> Ok, I've tested with latest xenial image, and I've been unable to reproduce this issue.

And did you test with arm64? Two of us have reproduced this, and I'm not sure what info is missing, so moving from Incomplete to Confirmed. If you are still unable to reproduce *on arm64*, please let us know.

[Scott Moser (smoser)]

So i was looking at the use of archdetect in etc/maas/templates/commissioning-user-data/snippets/maas_enlist.sh .
its used in 2 places
a.) get_host_architecture
  this i'm pretty sure can be replaced with dpkg --print-architecture
b.) get_host_subarchitecture
  here, archdetect is not used on i386|amd64|arm64|ppc64el)

So if this is only failing for you on arm64, then on arm64 you only ever use archdetecdt to get you the bit of information that could be provided by dpkg --print-architecture.

In cases where we do use archdetect to get the subarchitecture,
1.) i think that is limited to armhf
2.) i'm pretty sure we'll end up reporting invalid subarch in many cases. src/provisioningserver/drivers/__init__.py has a list of Architectures:
        amd64/generic
        arm64/generic
        arm64/xgene-uboot
        arm64/xgene-uboot-mustang
        armhf/generic
        armhf/highbank
        armhf/keystone
        i386/generic
        ppc64el/generic

Looking at libdebian-installer-0.102ubuntu1/debian/changelog it seems that archdetect now just returns 'generic' rather than 'highbank'. I think that is also the case on debian.

I might be missing something, but I'm pretty sure that this patch would work everywhere.