[Solved][Help][Generic Armhf]All Add-ons show as not available on my system. Cannot install add-on

Hi, I recently migrated from HA to HASS.IO because I wanted and container-based solution and wanted to benefit from HASS.IO add-on system.

I installed it on a Cubox-i4pro SBC using the install script and supplying the “armhf” architecture during install.

HA is working great, I can see the HASS.IO tabs but in the add-on store, I cannot install any add-on!
They all show the error: “This addon is not available on your system.”

I have not seen anything relevant in the log that would explain this situation. I see that there are add-on containers for armhf arch on DockerHub so some of them should be able to install I figure.

I’m not an expert with docker(yet) but I have the AppArmor and Supervisor containers running. Is there something I’m missing?

Thanks!

EDIT: Found the solution to my problem: [Solved][Help][Generic Armhf]All Add-ons show as not available on my system. Cannot install add-on

Hi, I’m running the same issue.
Any suggestion ?

Some forum posts says it might be related to disk space availability. It’s not my case here. I have 26GB left out of 32 on my volume.

Might be a permission issue? Where are the add-on container stored?

Personally, I’m not in love with these docker app, they seems to exists only for those people that where not able to configure a system, order to provide them a ready configured service, but at the same time, you’re without your familiar tools.
Anyway, by looking with

sudo docker logs hassio_supervisor

some log lines keeps my attention …

18-12-08 18:17:36 ERROR (MainThread) [hassio.addons.addon] Add-on core_cec_scan not supported on None with armhf architecture

I think that this “None” means something not specified during installation, something that sould be a type or something else that is not matched and result in our “not available for your system”
I’ll keep trying …

Yeah I’ve checked and I have the same error in the log file.

Looks like arch is not properly parsed. Cubox-i is armv7l which shouldn’t be an issue.

Thing is probably an env variable isn’t correctly set. that “None” should probably be set to “armv7l” or something.

EDIT: Looks like it requires the label “io.hass.machine” to be set in the supervisor container. I don’t know how to manually add that label in the container settings. I will try to reinstall using either “raspberrypi2” or “raspberrypi3” as the specified machine type in the hassio_install script.
Most likely “raspberrypi2” as it’s true armv7l and rpi3 installation might move to support full armv8l, which the cubox-i isn’t. I’m just worry about rpi2 support being not as good as rpi3 stuff for HASS.io.

So I’ve fixed the issue. Turns out you need to specify a machine type when installing in order to pull a Hassio container that is specific for a Single Board Computer.

In my case, I elected raspberrypi2 as my machine type as my Cubox-i’s ARM Arch matches best that board.
Instead of reinstalling, I just deleted the generic “armhf” images and container and pulled the “raspberrypi2” ones. “io.hass.machine” label is now properly populated when inspecting Hassio docker container. I wanted to use raspberrypi3 as my machine type but I’m worried this subset of container might get updated to run on 64-bit native targets down the line, which the Cubox-i isn’t…

So to wrap it up, in order to have support for installing Add-Ons in Hass.io, you need to make sure that the Label “io.hass.machine” is present and has a value that is supported when inspecting the hassio-supervisor container. If there’s something wrong with that label, delete all containers and images related to hassio and pull some of a Single Board Computer that best match your current target. Adjust systemd units, hassio config in /etc and maybe stuff in your hassio config folder (/usr/share/hassio).