error detecting hardware characteristics: unrecognised architecture: aarch64

Here's what seems to be a straightforward fix for this bug - after applying, I get further:

dannf@trusty:~$ juju add-machine ssh:arm64dannf -v
verbose is deprecated with the current meaning, use show-log
2014-02-06 06:12:54 INFO juju api.go:231 connecting to API addresses: [bootstrap.dannf:17070]
2014-02-06 06:12:54 INFO juju apiclient.go:118 state/api: dialing "wss://bootstrap.dannf:17070/"
2014-02-06 06:12:54 INFO juju apiclient.go:128 state/api: connection established
2014-02-06 06:12:54 INFO juju.environs.manual init.go:156 initialising "arm64.dannf", user ""
2014-02-06 06:12:54 INFO juju.environs.manual init.go:167 ubuntu user is already initialised
2014-02-06 06:12:54 INFO juju.environs.manual provisioner.go:260 addresses for arm64.dannf: [192.168.1.117 public:arm64.dannf]
2014-02-06 06:12:54 INFO juju.environs.manual init.go:29 Checking if arm64.dannf is already provisioned
2014-02-06 06:12:54 INFO juju.environs.manual init.go:46 arm64.dannf is not provisioned
2014-02-06 06:12:54 INFO juju.environs.manual init.go:55 Detecting series and characteristics on arm64.dannf
2014-02-06 06:12:54 INFO juju.environs.manual init.go:118 series: trusty, characteristics: arch=aarch64 cpu-cores=1 mem=16062M
2014-02-06 06:12:57 ERROR juju.cmd supercommand.go:294 no matching tools available

The attachment "recognize-aarch64.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Thanks Dann! Presumably this needs to go upstream? Adding an upstream bug task.

I don't have direct ways to test the patch, but it seems sane to me. Is there something we can get into some form of testing to make sure that we don't break this in the future? (CI testing for aarch64?)

On Fri, Feb 7, 2014 at 8:55 AM, John A Meinel <email address hidden> wrote:
> I don't have direct ways to test the patch, but it seems sane to me. Is
> there something we can get into some form of testing to make sure that
> we don't break this in the future? (CI testing for aarch64?)

I setup sinzui w/ some access earlier this week - is this the same
testing he works on?

This is the only other obvious place that grep says needs arch-enablement.

offhand, I would think we'd want to use the term "arm64" for this (to match arm), but I don't have a strong stake in what we call it.

After discussion John and Dan the mapping for arm and ppc should look like:

aarch64 should map to arm64
ppc64 should map to ppc64el

The files affected look to be /environs/manual/init.go and scripts/release-public-tools/release-public-tools.sh

-thanks,
Antonio

On Fri, Feb 7, 2014 at 10:26 AM, John A Meinel <email address hidden> wrote:
> offhand, I would think we'd want to use the term "arm64" for this (to
> match arm), but I don't have a strong stake in what we call it.

I'd prefer arm64 as well (easier to type, 1:1 mapping for dpkg arch).
It apparently isn't required that this match the dpkg arch - that
isn't the case for ARM32 where juju calls it "arm" but the relevant
corresponding dpkg arch is 'armhf'.

On Fri, Feb 7, 2014 at 7:37 PM, Antonio Rosales
<email address hidden>wrote:

> After discussion John and Dan the mapping for arm and ppc should look
> like:
>
> aarch64 should map to arm64
>

This one should be the other way around

> ppc64 should map to ppc64el
>
> The files affected look to be /environs/manual/init.go and scripts
> /release-public-tools/release-public-tools.sh
>
> -thanks,
> Antonio
>
> ** Changed in: juju-core
> Milestone: 1.18.0 => 1.17.3
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> Matching subscriptions: MOAR JUJU SPAM!
> https://bugs.launchpad.net/bugs/1276909
>
> Title:
> error detecting hardware characteristics: unrecognised architecture:
> aarch64
>
> Status in juju-core:
> Triaged
> Status in "juju-core" package in Ubuntu:
> Triaged
>
> Bug description:
> dannf@trusty:~$ dpkg -l juju
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
>
> +++-==============-============-============-=================================
> un juju <none> <none> (no description available)
> dannf@trusty:~$ cat ~/.juju/environments.yaml
> default: manual
>
> environments:
> manual:
> type: manual
> bootstrap-host: bootstrap.dannf
> bootstrap-user: dannf
> dannf@trusty:~$ juju add-machine ssh:arm64.dannf
> ERROR error detecting hardware characteristics: unrecognised
> architecture: aarch64
> dannf@trusty:~$
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1276909/+subscriptions
>

On Fri, Feb 7, 2014 at 11:40 AM, Dave Cheney <email address hidden> wrote:
> On Fri, Feb 7, 2014 at 7:37 PM, Antonio Rosales
> <email address hidden>wrote:
>
>> After discussion John and Dan the mapping for arm and ppc should look
>> like:
>>
>> aarch64 should map to arm64
>>
>
> This one should be the other way around
>
>
>> ppc64 should map to ppc64el

Apologies, there's a couple points of confusion here. To be explicit:

uname -m returns: ppc64le, aarch64
dpkg uses: ppc64el, arm64

Yes, the le/el is transposed between the two ppc64 ones. Weird, I know.
Yes, we said ppc64 above but I'm saying ppc64le now. This is because
code inspection shows that juju is using 'uname -m' here in the script
it passes to the manual provisioned hosts, and this wasn't clear when
we asked a ppc64el/le porter about it. I explicitly asked our porter
friend to run 'uname -m', and he confirmed it returns "ppc64le".

Updated patch for arm64. This one I was able to test since arm64 tools are now available in the simple stream :)

I've made a branch out of the patches (well, manually did it). @dann can I get you to give the diff a once over?

On Thu, Feb 27, 2014 at 8:20 PM, Tim Penhey <email address hidden> wrote:
> I've made a branch out of the patches (well, manually did it). @dann can
> I get you to give the diff a once over?

@Tim: Yes, looks correct to me.

Attached is the latest patch that was applied to the 1.17.4 release tarball to build a juju that understood arm64. It overlaps with the previous patches. It might just be the summation of the previous patches.

This bug was fixed in the package juju-core - 1.17.6-0ubuntu1

---------------
juju-core (1.17.6-0ubuntu1) trusty; urgency=medium

  * New upstream point release, including fixes for:
    - br0 not bought up by cloud-init with MAAS provider (LP: #1271144).
    - ppc64el enablement for juju/lxc (LP: #1273769).
    - juju userdata should not restart networking (LP: #1248283).
    - error detecting hardware characteristics (LP: #1276909).
    - juju instances not including the default security group (LP: #1129720).
    - juju bootstrap does not honor https_proxy (LP: #1240260).
  * d/control,rules: Drop BD on bash-completion, install bash-completion
    direct from upstream source code.
  * d/rules: Set HOME prior to generating man pages.
  * d/control: Drop alternative dependency on mongodb-server; juju now only
    works on trusty with juju-mongodb.
 -- James Page <email address hidden> Mon, 24 Mar 2014 16:05:44 +0000