When doing a buildah pull
or buildah bud
command and a "common" image can not be pulled,
it is likely that the /etc/containers/registries.conf
file is either not installed or possibly
misconfigured.
$ sudo buildah bud -f Dockerfile .
STEP 1: FROM alpine
error creating build container: 2 errors occurred:
* Error determining manifest MIME type for docker://localhost/alpine:latest: pinging docker registry returned: Get https://localhost/v2/: dial tcp [::1]:443: connect: connection refused
* Error determining manifest MIME type for docker://registry.access.redhat.com/alpine:latest: Error reading manifest latest in registry.access.redhat.com/alpine: unknown: Not Found
error building: error creating build container: no such image "alpine" in registry: image not known
- Verify that the
/etc/containers/registries.conf
file exists. If not, verify that the containers-common package is installed. - Verify that the entries in the
[registries.search]
section of the /etc/containers/registries file are valid and reachable. - Verify that the image you requested is either fully qualified, or that it exists on one of your search registries.
- Verify that the image is public or that you have logged in to at least one search registry which contains the private image.
When doing a Buildah command such as bud
, commit
, from
, or push
to a registry,
tls verification is turned on by default. If authentication is not used with
those commands, this error can occur.
# buildah push alpine docker://localhost:5000/myalpine:latest
Getting image source signatures
Get https://localhost:5000/v2/: http: server gave HTTP response to HTTPS client
By default tls verification is turned on when communicating to registries from
Buildah. If the registry does not require authentication the Buildah commands
such as bud
, commit
, from
and pull
will fail unless tls verification is turned
off using the --tls-verify
option. NOTE: It is not at all recommended to
communicate with a registry and not use tls verification.
- Turn off tls verification by passing false to the tls-verification option.
- I.e.
buildah push --tls-verify=false alpine docker://localhost:5000/myalpine:latest
When doing a buildah run
command while using a pipe ('|') or output redirection ('>>'),
the command will fail, often times with a command not found
type of error.
When executing a buildah run
command with a pipe or output redirection such as the
following commands:
# buildah run $whalecontainer /usr/games/fortune -a | cowsay
# buildah run $newcontainer echo "daemon off;" >> /etc/nginx/nginx.conf
# buildah run $newcontainer echo "nginx on Fedora" > /usr/share/nginx/html/index.html
the buildah run
command will not complete and an error will be raised.
There are two solutions to this problem. The
podman run
command can be used in place of buildah run
. To still use buildah run
, surround
the command with single quotes and use bash -c
. The previous examples would be
changed to:
# buildah run bash -c '$whalecontainer /usr/games/fortune -a | cowsay'
# buildah run bash -c '$newcontainer echo "daemon off;" >> /etc/nginx/nginx.conf'
# buildah run bash -c '$newcontainer echo "nginx on Fedora" > /usr/share/nginx/html/index.html'
When doing a buildah push
command and the target image has a tilde (~
) character
in it, an lstat error will be raised stating there is no such file or directory.
This is expected behavior for shell expansion of the tilde character as it is only
expanded at the start of a word. This behavior is documented
here.
$ sudo pull alpine
$ sudo buildah push alpine oci:~/myalpine:latest
lstat /home/myusername/~: no such file or directory
- Replace
~
with$HOME
or the fully specified directory/home/myusername
.$ sudo buildah push alpine oci:${HOME}/myalpine:latest