I’ve run across issue with building image for ARMv7 on the x86_64 platform. I was able to build the exact image on previous machine (in december), now I set up new one, and the build fails while loading metadata. I tried it back on the previous one and I am getting same issue.
I am not using proxy, and working with the Docker version 19.03.8, build afacb8b7f0
on Debian 10.
debian@master-vm:~/zulu/source/docker-image-modbus-server$ sudo docker buildx build --progress=plain .
WARN[0000] No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
#2 [internal] load build definition from Dockerfile
#2 transferring dockerfile: 32B done
#2 DONE 0.1s
#1 [internal] load .dockerignore
#1 transferring context: 2B done
#1 DONE 0.2s
#3 [internal] load metadata for docker.io/arm32v7/python:3-alpine
#3 ERROR: failed to do request: Head https://registry-1.docker.io/v2/arm32v7/python/manifests/3-alpine: net/http: TLS handshake timeout
#7 [internal] load build context
#7 transferring context: 135B done
#7 DONE 0.1s
#4 [1/8] FROM docker.io/arm32v7/python:3-alpine
#4 resolve docker.io/arm32v7/python:3-alpine
#4 resolve docker.io/arm32v7/python:3-alpine 10.1s done
#4 ERROR: failed to do request: Head https://registry-1.docker.io/v2/arm32v7/python/manifests/3-alpine: net/http: TLS handshake timeout
------
> [internal] load metadata for docker.io/arm32v7/python:3-alpine:
------
------
> [1/8] FROM docker.io/arm32v7/python:3-alpine:
------
failed to solve: rpc error: code = Unknown desc = failed to load cache key: failed to do request: Head https://registry-1.docker.io/v2/arm32v7/python/manifests/3-alpine: net/http: TLS handshake timeout
However, I am able to pull the image via docker pull arm32v7/python:3-alpine
.
I noticed via docker buildx imagetools inspect
, that there are no platform spcified. Could it be the issue?
debian@master-vm:~/zulu/source/docker-image-modbus-server$ sudo docker buildx imagetools inspect docker.io/arm32v7/python:3-alpine
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 7105,
"digest": "sha256:2d2bef1887db61335227492d453a017bc91c087a29351d4ac17e592b316403f4"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 2422063,
"digest": "sha256:3cfb62949d9d8613854db4d5fe502a9219c2b55a153043500078a64e880ae234"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 300597,
"digest": "sha256:d9cc56725e953ef92747f06871023f5d55c6bf429621ac1619ed1314f8fbbffb"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 26451152,
"digest": "sha256:bed2ca1fb270fe52f59092abec52bfa9e7419f99a56d0bc8f61efd95d6cb3aa0"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 231,
"digest": "sha256:70012a3ca4616e4d9a1ffa32f13aac782ee8e150670628fb507942c6106b2808"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 1931243,
"digest": "sha256:b7069b1f7adf8dbcef637a87139fa99688b200393fe39488174a3ea48b023179"
}
]
}
I would be glad for any help with this issue.
To make things easier, there is docker info
debian@master-vm:~/zulu/source/docker-image-modbus-server$ sudo docker info
Client:
Debug Mode: false
Plugins:
app: Docker Application (Docker Inc., v0.8.0)
buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
Server:
Containers: 3
Running: 2
Paused: 0
Stopped: 1
Images: 4
Server Version: 19.03.8
Storage Driver: overlay2
Backing Filesystem: <unknown>
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
init version: fec3683
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.19.0-5-cloud-amd64
Operating System: Debian GNU/Linux 10 (buster)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.857GiB
Name: master-vm
ID: I5UI:7D77:2WEM:2KDZ:BPTC:EHWD:VROK:LA63:ZAZQ:QC7T:LY2Z:WMLW
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
My Dockerfile:
FROM arm32v7/python:3-alpine
WORKDIR = /usr/src/app
RUN apk add --no-cache --virtual .build-deps gcc musl-dev
COPY requirements.txt ./
RUN pip3 install --no-cache-dir -r requirements.txt
RUN apk del .build-deps gcc musl-dev
#Choose S103 or M103 devices
COPY ./S103/device.json .
COPY ./server-callback.py .
CMD ["python3", "./server-callback.py"]
I posted it as an issue on Docker buildx GitHub, but asking here too if maybe I am missing something in my configuration. https://github.com/docker/buildx/issues/275
2
Answers
Ok, after few hours of debugging I found the solution (or workaround) to lower MTU in
/etc/docker/daemon.json
config to 1300.After few tests it seems working ok. I guess there is some inconsistency in MTU size in the network infrastructure - I was using Openstack. Hope this saves somebody some time.
What worked for me is that I simply restarted my docker. And it worked after that, didn’t need to do anything else.