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 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 Hass.io with “docker build” just fine on my dev box, but not inside Hass.io 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.
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.
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 https://github.com/hassio-addons/addon-grocy/ 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 https://google.com/
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 https://google.com/’ 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 google.com. I think it is because jq is already installed.
The problem I’m having is that everything works differently INSIDE the hass.io 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?
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 https://8.8.8.8/
if that RUN line works, try adding
RUN nslookup google.com
Might you by any change be using AdGuard Home?
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, 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=http://208.74.142.61/alpine/edge/main --repository=http://208.74.142.61/alpine/edge/community 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 1.1.1.1 as a DNS server instead of using itself with the Adguard Home container. (This is the directions I found on how to do nmcli: https://github.com/home-assistant/operating-system/commit/ad9f21fdfbc32bfa7ee16fc5c266c458708c3dc2).
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.
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.
