Errors when buliding a new addon

Tags: #<Tag:0x00007f73916790d8> #<Tag:0x00007f7391679010>

Hi all,
I am not really use to this place, so forgive me if I posted the wrong place or added tags I shouldn’t.
I am building a new addon for hassio here

I have used the example-addon created by @frenck

I can do docker build outside of HA, but when I try to install it via HA I see the following error in the logs

20-05-24 10:59:15 ERROR (SyncWorker_13) [supervisor.docker.addon] Can’t build 0ca413a9/amd64-addon-radicale:3.0.1: The command ‘/bin/bash -o pipefail -c apk update’ returned a non-zero code: 5

I have tried with another repo with the same problem

20-05-24 11:00:15 ERROR (SyncWorker_3) [supervisor.docker.addon] Can’t build 13861ffc/amd64-addon-ozwcp:1.1.2: The command ‘/bin/ash -o pipefail -c apk update’ returned a non-zero code: 5

I have tried the python base but then the pip command fails in much the same way.

this leads me to think its some setting somewhere I am not aware of that is causing the problem…

I hope someone can help me :slight_smile:

I still have no clue how to solve this.
I did however create a dockerhub acount, build the image locally and upload it and then have home assistant download it. This all works, but I would like to know why apk does not work when run inside homeassistant…

I am having the same issue no matter what apk command I run. I can build the same dockerfile outside with “docker build” just fine on my dev box, but not inside through the add-ons loader.

I’ve even taken one of the Dockerfiles straight from one of @frenck’s repositories from hassio-addons (the grocy one to be specific) and tried it and it fails the same way.

My working theory is that the network isn’t resolving for some reason from Inside the supervisor build environment (based on general complaints online about non-zero error from apk add/update) but I haven’t been able to prove it yet.

Still trying to figure it out…

ran some other commands like ``echo “test” > file``` which worked fine. I think you network hunch might be correct. Next time I test I will do a curl on some host to see if that fails too.

I tried a bit more stuff.

I forked into I fixed it so it will build on the supervisor instead of looking for a hub image and repaired the architectures warning.

That one works. And it has a RUN apk add --no-cache jq command in the Dockerfile for the coffee_maker one. So it obviously can access the network and do apk add just fine.

The one thing that struck me was that it shows as a ‘5’ security level in the UI where as the other one I was trying to build myself showed up as a ‘6’. Perhaps something in the config.json is making it “so secure” that it locks out the supervisor build process from touching the network?

My next steps are to slowly push the coffee_maker project closer and closer to my fork of stuff from until I see what config.json directive (or other settting) is causing it to no longer be able to access apk.

That is interesting. Have you checked if the image you are starting from already has jq installed. I think most of the base images have. This could be why it is not failing?

I justed tried adding
RUN curl -h
RUN curl
and I get the error:
… [supervisor.docker.addon] Can’t build local/amd64-addon-radicale:3.0.1: The command ‘/bin/ash -o pipefail -c curl’ returned a non-zero code: 6

I just added a RUN apk add --no-cache jq before my curl commands and they still failed at the curl against I think it is because jq is already installed.

The problem I’m having is that everything works differently INSIDE the build than it does on a real docker build. And I can’t figure out how to extract the docker build logs from inside the supervisor…

It could be that jq is already installed. I’m not having luck with things as basic as “apk add php7”. I just don’t understand why all of the official add-ons act completely differently. Perhaps it’s because they’re all prebuilt and building on the supervisor is just broken?

Tried forcing it to use the community repository thinking that jq is a part of the main one and all the other stuff is community. Still didn’t work.

apk add php7 --update-cache --repository --allow-untrusted

I tried to do a curl that failed. So I am thinking that your first hunch was correct and there is simply no network where the images are built. I found a issue on github where @frenck mentions a docker image for building images under different architectures. So my thinking is as yours, that they are building the images outside of hassio. I think I will create an issue on github and link to this thread

Hi @miniksa
So with some debugging help we are a little closer to finding out what might be wrong
Can you try to add a RUN curl
if that RUN line works, try adding
RUN nslookup
Might you by any change be using AdGuard Home?

Hey @arendal.

Sorry, I figured this out yesterday afternoon but then I got the phone call that my 12-year old roof needs to be completely replaced again and in my fury and subsequent sadness + a strong drink, I completely forgot that I was going to come back here and tell you.

I went to the Discord channel to ask where Frenck and paul_sinclair led me around to understand that I failed the first rule of addon-adguard-home… RTFM. The readme ( on line 1 warns " Ensure your Home Assistant device has a static IP and static external DNS servers! This is important! You WILL end up having issues if you skip this step. Also, please note, setting a fixed IP in your router is NOT static."

I, of course, had Adguard Home and had set my router to give out a static DHCP lease to the HA machine figuring that was good enough. I also had the router giving out the DNS server as the HA machine itself since it was running the Adguard Home server.

So I tried what you suggest there. I was able to do apk add --no-cache php7=7.3.18-r0 --repository= --repository= and it worked just fine. IP addresses fine. All signs pointing to DNS.

Then after a bunch more messing around and failboating in the Discord channel with Frenck and paul-sinclair watching, they guided me a bit as I used the root login on the HA device itself, used the login command to drop into the base os, then used nmcli to set the IP address directly into the device and gave it as a DNS server instead of using itself with the Adguard Home container. (This is the directions I found on how to do nmcli:

And then because I messed up the box flailing with some combination of systemctl and service to get it to take… I rebooted the thing and everything worked.

I changed the add-on to take out the IP address repositories and I was able to apk add to my heart’s content and curl on any domain name.

So yeah. That’s the moral of the story: Your HA device needs a real IP and DNS set statically into it, no DHCP reservation, and can’t use itself as a DNS server via Adguard Home. If you make that mistake, you will have an impossible time building add-ons.

@miniksa how did you manage to actually set the ipv4 address? In my installation it complains that it’s a readonly filesystem and can’t do anything.

edit: nvm - hadn’t properly entered the editing mode

@miniksa, Sorry to hear about your roof. I too got help from @frenck and @sinclairpaul on github :slight_smile:

I ended up following this guide to set my static IP

Ah, yeah, I saw that guide too. But I’m running HA in a VM temporarily for dev purposes and attaching a USB device to it is a pain in the butt, so I wanted a way to do it from the root login prompt. But glad you got yours settled too.

My addon worked fine until I tried to update it with HA 0.112 … then I had the same error:

ERROR (SyncWorker_15) [supervisor.docker.addon] Can't build 54210f65/armv7-addon-ruuvitag-discovery:0.1.12: The command '/bin/ash -o pipefail -c apk add --no-cache npm libusb-dev bluez-dev linux-headers eudev-dev build-base python git' returned a non-zero code: 1

Nothing has changed between my 2 builds (just a little line of code, but nothing in the docker build).
Very weird …

I solved this problem with my addon! I added a build.json file and some labels to my Dockerfile. Here is my commit
I hope it helps :slightly_smiling_face: