RUN command returns in exit code 1 in buildx

General
1

Can’t figure why this happens. I’m trying to create a docker image with base pihole and include unbound in it. I have it working for ages with the pihole 5.x-version but the development-v6 running on alpine is giving the following through buildx:

Dockerfile_v6:21
--------------------
  19 |     RUN apk add openrc
  20 |     RUN rc-update add unbound default
  21 | >>> RUN /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key
  22 |     # RUN touch /run/openrc/softlevel
  23 |     
--------------------
ERROR: failed to solve: process "/bin/sh -c /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key" did not complete successfully: exit code: 1
Error: buildx failed with: ERROR: failed to solve: process "/bin/sh -c /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key" did not complete successfully: exit code: 1

folder /var/lib/unbound is created before and chowned with unbound.
Added /usr/sbin before the executable as without it was also causing trouble.

If I use a base pihole-image and run the container I can run the commands. Even got pihole and unbound running with pihole v6 at the moment.

Contents from the Dockerfile_v6:

# development-v6-image

ARG PIHOLE_VERSION
FROM pihole/pihole:development-v6

# COPY debian_testing.list /etc/apt/sources.list.d/

# RUN apt update && apt install -y -f openssl net-tools unbound openssh-server

RUN apk add unbound

# directories made later as chown won't work before apk add unbound

RUN mkdir -p /var/log/unbound && mkdir -p /var/lib/unbound
RUN chown -R unbound:unbound /var/log/unbound && chown -R unbound:unbound /var/lib/unbound

# rc-stuff

RUN apk add openrc
RUN rc-update add unbound default
RUN /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key
# RUN touch /run/openrc/softlevel
2

Isn’t openrc an init system? Have you checked if it even works in a container?
Just because the package exists and can be installed, doesn’t mean its suited for alpine containers…

Running multiple processes in a single container is a bad practice. Instead of adding unbound to the image, you should consider using a separate container for unbound and configure pihole to interact with the unbound container,

3

That could be indeed. It works when I run it manually within the bare pihole-container.
I prefer having one container. But I’m thinking maybe all the executable stuff should be put in a file which is set in the entrypoint. I’m going to give that a try soon.

On second thoughts: unbound-anchor is the one failing and that’s not an init-thing.

4

I strongly suggest taking a look at the Dockerfile and see what they use as entypoint.

Without understanding how the image is designed and needs to be extended, chances are high that you break something while enforcing what you think is the solution, while not knowing that there actually is a more elegant solution.