I'm trying to build an image from CentOS 6.9. Using this Dockerfile:
FROM centos:6.9
RUN ls
But it keeps failing with exit code 139 with the following output:
$ docker build -t centos-6.9 .
[+] Building 1.1s (7/7) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 72B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/centos:6.9 0.6s
=> [internal] load build context 0.1s
=> => transferring context: 72B 0.0s
=> CACHED [1/3] FROM docker.io/library/centos:6.9#sha256:6fff0a9edc920968351eb357c5b84016000fec6956e6d745f695e5a34f18ecd2 0.0s
=> [2/3] COPY . . 0.0s
=> ERROR [3/3] RUN ls 0.3s
------
> [3/3] RUN ls:
------
executor failed running [/bin/sh -c ls]: exit code: 139
I'm running:
Windows 10 Enterprise Version 2004
Docker Desktop 3.0.0
This appears to be an issue with WSL 2 with older base images, not docker or the image itself.
Create %userprofile%\.wslconfig file.
Add the following:
[wsl2]
kernelCommandLine = vsyscall=emulate
Restart WSL. wsl --shutdown
Restart Docker Desktop.
References:
https://github.com/microsoft/WSL/issues/4694#issuecomment-556095344
https://github.com/docker/for-win/issues/7284#issuecomment-646910923
https://github.com/microsoft/WSL/issues/4694#issuecomment-558335829
Related
I'm trying to run a docker elasticsearch:2.3.4 container on a Mac M1. But the container fails because that image supports only linux/amd64. In contrast to the latest image, ElasticSearch:8.5.1, supports linux/amd64 and linux/arm64/v8.
For legacy reasons I still require the 2.3.4 version of ES. With this in mind I tried to build a ES 2.3.4 image with support for arm64 following these instructions. However I believe my inexperience with this is showing. The approach I took was to create a Dockerfile with
FROM elasticsearch:2.3.4
as the only instruction. My hope being that this would magically work. Instead when I run
docker buildx build --push --platform linux/amd64,linux/arm64 --tag myrepo/elasticsearch:2.3.4 .
It produces the following error
[+] Building 4.0s (6/6) FINISHED
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 61B 0.0s
=> [linux/amd64 internal] load metadata for docker.io/library/elasticsearch:2.3.4 3.9s
=> [linux/arm64 internal] load metadata for docker.io/library/elasticsearch:2.3.4 3.9s
=> ERROR [linux/arm64 1/1] FROM docker.io/library/elasticsearch:2.3.4#sha256:7a09f0b9204b0e331eb7031bf30e12c8138c53c61938d59bb07b9a1c6de93483 0.0s
=> => resolve docker.io/library/elasticsearch:2.3.4#sha256:7a09f0b9204b0e331eb7031bf30e12c8138c53c61938d59bb07b9a1c6de93483 0.0s
=> ERROR [linux/amd64 1/1] FROM docker.io/library/elasticsearch:2.3.4#sha256:7a09f0b9204b0e331eb7031bf30e12c8138c53c61938d59bb07b9a1c6de93483 0.0s
=> => resolve docker.io/library/elasticsearch:2.3.4#sha256:7a09f0b9204b0e331eb7031bf30e12c8138c53c61938d59bb07b9a1c6de93483 0.0s
------
> [linux/arm64 1/1] FROM docker.io/library/elasticsearch:2.3.4#sha256:7a09f0b9204b0e331eb7031bf30e12c8138c53c61938d59bb07b9a1c6de93483:
------
------
> [linux/amd64 1/1] FROM docker.io/library/elasticsearch:2.3.4#sha256:7a09f0b9204b0e331eb7031bf30e12c8138c53c61938d59bb07b9a1c6de93483:
------
Dockerfile:1
--------------------
1 | >>> FROM elasticsearch:2.3.4
--------------------
error: failed to solve: failed to load cache key: content digest : not found
For which I've found little to no information.
Any thoughts on what's the best approach here? Do I instead need to rebuild the elasticsearch:2.3.4 image from scratch? What's the approach taken to migrating an existing image to arm64?
I am trying to build a common base image, that many of my other images will use. But Nerdctl/Containerd doesn't seem to check for the image locally first.
Reproduced with the simple example
# Dockerfile.base
FROM python:3
# Dockerfile.child
From mybase:local
OUTPUT:
PS C:\<REDACTED>\local_build_issue> nerdctl build -t mybase:local -f Dockerfile.base .
[+] Building 10.1s (5/5) FINISHED
=> [internal] load build definition from Dockerfile.base 0.1s
=> => transferring dockerfile: 55B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/python:3 0.9s
=> CACHED [1/1] FROM docker.io/library/python:3#sha256:555f5affd32250ca74758b297f262fa8f421eb0102877596b48c0b8b464606ea 0.0s
=> => resolve docker.io/library/python:3#sha256:555f5affd32250ca74758b297f262fa8f421eb0102877596b48c0b8b464606ea 0.0s
=> exporting to oci image format 9.0s
=> => exporting layers 0.0s
=> => exporting manifest sha256:6bfdb5e41f7a1f0faf28f922e48cdd33e95b75cff958709cb7945291d34dffda 0.0s
=> => exporting config sha256:d449529a9f8347e81301101d04645624c6a52d71b0c6b85abfd8da6c65b19e31 0.0s
=> => sending tarball 9.0s
unpacking docker.io/library/mybase:local (sha256:6bfdb5e41f7a1f0faf28f922e48cdd33e95b75cff958709cb7945291d34dffda)...done
PS C:\<REDACTED>\local_build_issue> nerdctl images
REPOSITORY TAG IMAGE ID CREATED PLATFORM SIZE BLOB SIZE
mybase local 6bfdb5e41f7a About a minute ago linux/amd64 945.8 MiB 334.7 MiB
PS C:\<REDACTED>\local_build_issue> nerdctl build -t mychild:local -f Dockerfile.child .
[+] Building 0.5s (3/3) FINISHED
=> [internal] load build definition from Dockerfile.child 0.1s
=> => transferring dockerfile: 62B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> ERROR [internal] load metadata for docker.io/library/mybase:local 0.4s
------
> [internal] load metadata for docker.io/library/mybase:local:
------
Dockerfile.child:1
--------------------
1 | >>> FROM mybase:local
2 |
--------------------
error: failed to solve: mybase:local: pull access denied, repository does not exist or may require authorization: authorization status: 401: authorization failed
FATA[0000] unrecognized image format
I can't figure out how to get it to NOT look for the image on docker.io. All the recommendations for the docker cli do not seem apply or work.
it actually can't pull image locally first .
the nerdctl build image use the buildkitd tools.it has two types of backends.
you can find the answer from https://github.com/containerd/nerdctl/blob/master/docs/build.md
I'm having trouble building docker containers on an Apple M1
The project uses sdk 2.2 which is incompatible with arm64 architecture. So I changed the sdk and aspnet cores to 2.2-alpine3.8 and they seem to build ok but the process fails when it needs to publish
The docker file:
FROM mcr.microsoft.com/dotnet/core/sdk:2.2-alpine3.8 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY . .
RUN dotnet publish src/admin/MyContainer.Admin.csproj -c Release -o ./publish
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2-alpine3.8
WORKDIR /app
COPY --from=build-env /app/src/admin/publish .
# Copy script that allows waiting for the database on docker-compose
# As referenced here https://docs.docker.com/compose/startup-order/
# This was done because admin starts up very quickly on e2e env
# and the sqlserver container wasn't getting ready fast enough
COPY --from=build-env /app/docker-wait-for-it.sh .
EXPOSE 80
CMD ["dotnet", "MyContainer.Admin.dll"]
the build command I'm using is:
docker buildx build --platform linux/arm64/v8 -t MyContainer.azurecr.io/admin-api-web:development ./backend -f ./backend/Admin.Api.Web.Dockerfile
and the log output is:
[+] Building 0.5s (11/13)
=> [internal] load build definition from Admin.Api.Web.Dockerfile 0.0s
=> => transferring dockerfile: 46B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 34B 0.0s
=> [internal] load metadata for mcr.microsoft.com/dotnet/core/aspnet:2.2-alpine3.8 0.1s
=> [internal] load metadata for mcr.microsoft.com/dotnet/core/sdk:2.2-alpine3.8 0.1s
=> [build-env 1/4] FROM mcr.microsoft.com/dotnet/core/sdk:2.2-alpine3.8#sha256:1299ac0379146c1de7b588196727dbd56eace3abfbdd4321c547c9ff4a18a2f7 0.0s
=> => resolve mcr.microsoft.com/dotnet/core/sdk:2.2-alpine3.8#sha256:1299ac0379146c1de7b588196727dbd56eace3abfbdd4321c547c9ff4a18a2f7 0.0s
=> [stage-1 1/4] FROM mcr.microsoft.com/dotnet/core/aspnet:2.2-alpine3.8#sha256:4d6e528f4c09c55804b6032ecc5d60565a3ee16f68bb08d2cf337dff99cdb8c3 0.0s
=> => resolve mcr.microsoft.com/dotnet/core/aspnet:2.2-alpine3.8#sha256:4d6e528f4c09c55804b6032ecc5d60565a3ee16f68bb08d2cf337dff99cdb8c3 0.0s
=> [internal] load build context 0.2s
=> => transferring context: 473.91kB 0.1s
=> CACHED [stage-1 2/4] WORKDIR /app 0.0s
=> CACHED [build-env 2/4] WORKDIR /app 0.0s
=> CACHED [build-env 3/4] COPY . . 0.0s
=> ERROR [build-env 4/4] RUN dotnet publish src/admin/MyContainer.Admin.csproj -c Release -o ./publish 0.1s
------
> [build-env 4/4] RUN dotnet publish src/admin/MyContainer.Admin.csproj -c Release -o ./publish:
#11 0.127 Failed to resolve full path of the current executable [/proc/self/exe]
I've tried with different platforms on the --platform flag and without any specified as well... If I try to build with core 2.2 I get this output:
[+] Building 0.5s (4/4) FINISHED
=> [internal] load build definition from Admin.Api.Web.Dockerfile 0.0s
=> => transferring dockerfile: 745B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 34B 0.0s
=> ERROR [internal] load metadata for mcr.microsoft.com/dotnet/core/aspnet:2.2 0.4s
=> CANCELED [internal] load metadata for mcr.microsoft.com/dotnet/core/sdk:2.2 0.4s
------
> [internal] load metadata for mcr.microsoft.com/dotnet/core/aspnet:2.2:
------
error: failed to solve: failed to solve with frontend dockerfile.v0: failed to create LLB definition: no match for platform in manifest sha256:08xxx: not found
Which I've found out to be because core 2.2 has no support form arm64. But this file builds without any errors on an Intel MacBook but with M1 I can't get past the build error. Any ideas?
This is not an answer but a followup to the problem,
which might shed some more light on the issue.
I'm using aspnet:6 and it passes the build.
The problem later on is that the runnable .dll throws
cannot execute binary file: Exec format error
which seems to be a platform issue, using Mac with an M1 Silicon chipset.
I have no issue with other docker images that are made for linux/amd64
The Docker daemon seems to deal with this fine (having installed Rosetta2 and the Latest Docker Desktop for M1)
https://docs.docker.com/desktop/mac/apple-silicon/
Have you managed to resolve the issue and execute the dll?
I have followed these steps and when I run PS C:\dockeragent> docker build -t dockeragent:latest .
I get
[+] Building 0.8s (3/3) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 31B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> ERROR [internal] load metadata for mcr.microsoft.com/windows/servercore:ltsc2019 0.7s
------
> [internal] load metadata for mcr.microsoft.com/windows/servercore:ltsc2019:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: no match for platform in manifest sha256:etcetc: not found
I am using VSC with Docker extention on my local computer. How can I build this image?
From the log, the image is build from a windows image(windows/servercore:ltsc2019).
You need to check if the docker desktop on your local machine is running on Windows containers.
If no, you need to switch it to Windows containers.
Relatively new to Docker and Compose, but I have read every letter of the Docker Compose documentation, and unsuccessfully bounced around SO for hours, with no resolution to the above question.
I have an (example) directory with the following files:
./Dockerfile:
# syntax=docker/dockerfile:1
ARG CUSTOM_NODE_VERSION
FROM node:$CUSTOM_NODE_VERSION
ARG CUSTOM_NODE_VERSION
ARG HELLO
RUN echo "HELLO: -> $HELLO"
RUN echo "NODE_VERSION -> $NODE_VERSION"
RUN echo "CUSTOM_NODE_VERSION -> $CUSTOM_NODE_VERSION"
./docker-compose.yml:
version: "3.8"
services:
test:
build:
context: .
dockerfile: Dockerfile
args:
CUSTOM_NODE_VERSION: alpine
HELLO: 5
What I want is for docker compose build to use the args specified in the docker-compose.yml file, but it doesn't:
> docker compose build test
[+] Building 0.8s (4/4) FINISHED
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 32B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:1 0.5s
=> CACHED docker-image://docker.io/docker/dockerfile:1#sha256:e2a8561e419ab1ba6b2fe6cbdf49fd92b95912df1cf7d313c3e2 0.0s
failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = failed to create LLB definition: failed to parse stage name "node:": invalid reference format
But run works fine:
docker compose run test
[+] Running 1/1
⠿ Network compose-args_default Created 4.3s
[+] Building 3.1s (10/10) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 32B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:1 0.5s
=> CACHED docker-image://docker.io/docker/dockerfile:1#sha256:e2a8561e419ab1ba6b2fe6cbdf49fd92b95912df1cf7d313c3e2 0.0s
=> [internal] load metadata for docker.io/library/node:alpine 1.0s
=> CACHED [1/4] FROM docker.io/library/node:alpine#sha256:f372a9ffcec27159dc9623bad29997a1b61eafbb145dbf4f7a64568b 0.0s
=> [2/4] RUN echo "HELLO: -> 5" 0.5s
=> [3/4] RUN echo "NODE_VERSION -> 16.3.0" 0.3s
=> [4/4] RUN echo "CUSTOM_NODE_VERSION -> alpine" 0.5s
=> exporting to image 0.1s
=> => exporting layers 0.0s
=> => writing image sha256:e61653277599e3555b67c1a50699dd83d5c1ed1a93fe8a1a16529c6ec20e3e31 0.0s
=> => naming to docker.io/library/compose-args_test
This is all the more baffling to me because, per the Compose docs:
args
Add build arguments, which are environment variables accessible only during the build process.
Any help is much appreciated 🙏🏻
Build args were only recently added to compose-cli. Most likely that change hasn't reached the version of docker compose you're running. You can use docker-compose build (with a -) until this feature reaches your install.