Armhf support on bionic


When using Bionic (via armbian) on a armhf (ARMv7 compatible cpu), it is no longer possible to add this machine to a juju model.

Bionic support is an ‘port’ form the armhf platform (Raspberry PI 2 / Orange PI Zero etc), which would be great if it could be supported.
As Xenial was supported I could find that it is basically missing an entry in the ‘streams’ where it tries to find the client agent.

Is there a way to get this supported (or a way to trick the Xenial version installed, as I think that should be compatible, since go does not depend on to many external libraries)


Unfortunately Juju dropped 32 bit support for bionic.
You could grab the json streams metadata files and edit them to include armhf for bionic, and bootstrap with the --metadata-source option to upload custom metadata. See also juju metadata generate-agents --help for a command which will generate fully custom metadata for a geven agent tarball.


I won’t mind building the agent myself, but I was trying to combine this with jaas, which means I don’t have the bootstrap step.
Is there a way to get this working? Just for a lab environment, no production.


Sadly at this time I can’t think of a way to make it work. Juju indexes the agent binaries based on series, which seemed reasonable 7 years ago but in hindsight was overly prescriptive. Really, it’s the same binary for an series on a given OS but Juju needs to be changed to support that. Maybe you could hack
/etc/lsb-release to lie about the series?


Tried that already, and can confirm it tries to search for a xenial agent. But looking to the stream I wonder if there has been a juju2 agent. Would the juju1 agent be compatible? In which case I can try even an earlier version.

Just tested this, and it fails with the same errors.

09:50:26 DEBUG juju.utils.ssh ssh.go:305 using OpenSSH ssh client
09:50:27 INFO juju.environs.manual.sshprovisioner sshprovisioner.go:54 ubuntu user is already initialised
09:50:27 INFO juju.environs.manual.sshprovisioner sshprovisioner.go:167 Checking if orangepizero is already provisioned
09:50:27 DEBUG juju.utils.ssh ssh.go:305 using OpenSSH ssh client
09:50:31 INFO juju.environs.manual.sshprovisioner sshprovisioner.go:102 Detecting series and characteristics on orangepizero
09:50:31 DEBUG juju.utils.ssh ssh.go:305 using OpenSSH ssh client
09:50:32 INFO juju.environs.manual.sshprovisioner sshprovisioner.go:158 series: trusty, characteristics: arch=armhf cores=4 mem=492M
09:50:36 ERROR juju.environs.manual.sshprovisioner provisioner.go:58 cannot obtain provisioning script
09:50:36 DEBUG juju.api monitor.go:35 RPC connection died
09:50:36 DEBUG juju.api monitor.go:35 RPC connection died
ERROR getting instance config: finding agent binaries: no matching agent binaries available (not found)
09:50:36 DEBUG cmd supercommand.go:496 error stack:
getting instance config: finding agent binaries: no matching agent binaries available (not found)


juju 1 agents won’t be compatible.

I am surprised hacking /etc/lsb-release on the machine you are wanting to add didn’t work.
If you were to try again with an extra logging config item, something like

juju bootstrap --config logging-config="juju.environs.simplestreams=TRACE" --debug

that might help see whats going on.

Or just set the logging-config as per the above on a running controller before adding the machine.



Started a new local controller, with the option. And did a copy-n-paste of the controller logging to:

As far as I can tell from this, is that there simply never has been any juju v2 agent for armhf

the first call was with the default bionic lsb-release, the second one with xenial as a reference. This is confirmed by

I traced the directory where the client(s) are downloaded, and could find that the latest juju2 client can be found in, 13-may-2016. So I assume that nothings has been build after this, and I will have todo it myself.


A quick look at the logs shows:

candidate matches for products ["com.ubuntu.juju:16.04:armhf"]

which means it appears to be looking for a xenial tarball, and there are metadata entries listed for that.
But as you point out, even though metadata exists, it looks like no 32 bit arm agents have been built in a long time. We did drop support for 32 bit so unfortunately none of our build tooling is even set up now to produce binaries anymore. You can rectify this with a custom build, but only on your own controller, not a JAAS controller.


Then I think I will put a controller on a central location and start using that. Will let you now how that works out.