When trying to get (pull or run) the docker smtp4dev, I've got the following error message : /usr/bin/docker-current: unknown blob.
I'm trying to run it from :
a CentOS VM,
with Docker version 1.13.1, build cccb291/1.13.1
Please find hereafter my terminal output
sudo docker run --rm -p 3001:80 -p 2525:25 rnwood/smtp4dev:3.1.0-ci2020052101
Unable to find image 'rnwood/smtp4dev:3.1.0-ci2020052101' locally
Trying to pull repository rnwood/smtp4dev ...
3.1.0-ci2020052101: Pulling from rnwood/smtp4dev
68ced04f60ab: Downloading [=======> ] 3.898 MB/27.09 MB
4ddb1a571238: Downloading [===========> ] 3.784 MB/17.06 MB
94b78a0446e2: Download complete
b48f8e1b0b06: Downloading
a41ea3d79519: Waiting
7064c9d40b9c: Waiting
/usr/bin/docker-current: unknown blob.
See '/usr/bin/docker-current run --help'.
Thanks by advance for your support.
Following the new update of SMTP4DEV...it seems now working.. no root cause found...
The best hypothesis : problem with proxy network which leads to fail the build of the docker...
Stay tuned...
Related
Learning docker following a course in udemy. i have all the prerequisites like docker desktop and switched to windows container. While trying to run a container using
docker container run docker4dotnet/nanoserver hostname
getting error like below
Unable to find image 'docker4dotnet/nanoserver:latest' locally
latest: Pulling from docker4dotnet/nanoserver
b5c97e1d373f: Extracting [==================================================>] 103MB/103MB
docker: failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessBaseLayer \?\C:\ProgramData\Docker\windowsfilter\90f22cdfe817e491c24b8e26f35b4ec43c6477ce0c86cdbfb95a59e2606762a5: The semaphore timeout period has expired.
unable to figure it out. can some one help on this
NOTE : tried to switch the container to linux but it says
Unable to find image 'docker4dotnet/nanoserver:latest' locally
latest: Pulling from docker4dotnet/nanoserver
b5c97e1d373f: Downloading
docker: image operating system "windows" cannot be used on this platform.
NOTE 2 : Even tried
docker run -d -p 8090:80 docker/getting-started it says below even though windows container is selected
PS C:\WINDOWS\system32> docker run -d -p 8090:80 docker/getting-started
docker: Error response from daemon: operating system on which parent image was created is not Windows.
use this lines in cmd:
docker pull mcr.microsoft.com/windows/nanoserver:20H2
docker container run mcr.microsoft.com/windows/nanoserver:20H2 hostname
I faced an issue with docker.
The scenario is like this: we use Codebuild+Packer+docker to create AMI, which is used in deploy. During this step we pull image from artifactory and all pass fine except pulling one of the layers which is > 1Gb. After several retries it fails with error: Download failed, retrying: unknown blob and then “unexpected EOF”. Have you ever faced such issue? Any comments or advices are highly appreciated.
This was mainly because of weak network ( as I was using mobile hotspot )
configured the docker daemon to reduce the tcp packets
$ dockerd --max-concurrent-downloads <int>
here <int> suggests the number of docker pull layers you want to download concurrently.
default is 3
in mycase i had set to 2
$ dockerd --max-concurrent-downloads 2 &>/dev/null
downside of doing this is sacrificing your precious time :)
takes time like hell
I had this problem with a very small layer that was corrupted or broken in the registry V2 for some unknown reason. docker pull failed with "unexpected EOF" after retrying the layer (identified as "1f8fd317c5a4" in this case).
Rebuilding the image from source and trying to docker push said "layer already exists", not fixing the issue.
I was able to delete the offending layer using curl like so;
curl -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' -sk "https://registry.local/v2/image-name/manifests/1033-develop-7e414712"
(substitute your registry for "registry.local", your image name for "image-name", and your image tag or "latest" for "1033-develop-7e414712".)
Get the complete sha256 digest for layer 1f8fd317c5a4 from the JSON output, and use it in next command:
curl -k -X DELETE "https://registry.local/v2/image-name/blobs/sha256:1f8fd317c5a406a75130dacddc02bd09a9abf44e068e2730dd8f5238666bb390"
Now you will be able to docker push registry.local/image-name:1033-develop-7e414712 to upload the layer you deleted, and everything works.
With Docker Desktop on Windows, could not find the dockerd command, then added the below entry in the daemon.json file and restarted the docker service.
"max-concurrent-downloads": 1
You will find this file at path- C:\Users\<user-name>\.docker\daemon.json.
This will pull the layers in a sequential manner hence it will take time, but yes, this is an alternative solution to download the large image file over the weak network connection.
Had the same issue due to a bad connection. In the documentation, here is the dockerd command.
For Linux, simply add:
$ dockerd --max-concurrent-downloads 2
$ dockerd --max-download-attempts 10
For windows docker desktop, open settings -> Docker Engine and pop the following in with the numbers best for you. You can see all the options in the docs as above.
Stop docker service: sudo service docker stop
Run docker service with decreasing max-concurrent-downloads to what suits your internet bandwidth (Unfortunately 1 for me) and increasing max-download-attempts: sudo dockerd --max-concurrent-downloads 1 --max-download-attempts 10
PS: I am not a docker expert. But, I believe there is a better way to do it by adding some config whether to the registry or your docker client.
Problem: Unable to pull docker image its giving retrying to pull image and EOF
Solution: Update docker software then try to pull image it resolves the issue.
This does not match the situation described by OP perfectly, but I'll post it here for future reference. Docker Desktop 4.15.0 introduced a bug which caused a similar issue for me. Depending on the Docker Desktop version and command used, one of these errors would pop up:
% docker pull alpine:3.7
Error response from daemon: Get "https://registry-1.docker.io/v2/": read tcp 192.168.65.4:55694->192.168.65.5:3128: read: connection reset by peer
% docker-compose up --build
// Some stuff
=> ERROR [container_name internal] load metadata for docker.io/library/alpine:3.7 0.0s
------
> [container_name internal] load metadata for docker.io/library/alpine:3.7:
------
failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to do request: Head "https://registry-1.docker.io/v2/library/alpine/manifests/3.7": unexpected EOF
% docker pull alpine:3.7
Error response from daemon: Get "https://registry-1.docker.io/v2/": unexpected EOF
The solution was to uninstall Docker Desktop and install an older version. I'm posting this here since a lot of guides and instructions recommend updating Docker Desktop to its newest version, but in my case that is exactly what caused the issue. Of course this bug will most likely be patched in a newer version at some point, I have notified Docker support about it.
Edit: It seems that there is a GitHub topic for my issue.
I am using windows 10 machine, with Docker on windows, and pulled cloudera-quickstart:latest image. while trying to run it, I am getting into below error.
can someone please suggest.
docker: Error response from daemon: oci runtime error: container_linux.go:262: starting container process caused "exec: \"/usr/bin/docker-quickstart\": stat /usr/bin/docker-quickstart: no such file or directory"
my run command:
docker run --hostname=quickstart.cloudera --privileged=true -t -i cloudera/quickstart /usr/bin/docker-quickstart
The issue was that I have download docker separately and created the image with this command, which is not supported in cloudera 5.10 and above.
tar xzf cloudera-quickstart-vm-*-docker.tar.gz
docker import - cloudera/quickstart:latest < cloudera-quickstart-vm--docker/.tar
so I finally removed the docker image and then pulled it properly
docker pull cloudera/quickstart:latest
now docker is properly up and running.
If you had downloaded CDH v5.13 docker image, then the issue might be mostly due to the structure of the image archive; in my case, I found it to be clouder*.tar.gz > cloudera*.tar > cloudera*.tar ! Seems the packaging was done by fault and the official documentation too doesn't capture this :( In which case, just perform one more level of extraction to get to the correct cloudera*.tar archieve. This post from the cloudera forum helped me.
Today I first time installed docker on Fedora 21. Now, I need change location of docker images folder from default /var/lib/docker.
After copying files (devicemapper subfolder skipped, docker service stopped) and changing /etc/sysconfig/docker (adding -g option), I run docker service again, no problems, devicemapper/metadata created.
Next, I'm trying to pull first image:
docker pull centos
But this error occured:
docker pull centos
latest: Pulling from docker.io/centos
6941bfcbbfca: Download complete
6941bfcbbfca: Error downloading dependent layers
41459f052977: Downloading [==========================> ] 41.61 MB/77.28 MB
fd44297e2ddb: Error pulling image (latest) from docker.io/centos, endpoint: https://registry-1.docker.io/v1/, Driver devicemapper failed to create image rootfs 6941bfcbbfca7f4f48becd38f2639157042bfd44297e2ddb: Error pulling image (latest) from docker.io/centos, Driver devicemapper failed to create image rootfs 6941bfcbbfca7f4f48becd38f2639157042b5cf9ab8c080f1d8b6d047380ecfc: Error running DeviceCreate (createSnapDevice) dm_task_run failed
FATA[0013] Error pulling image (latest) from docker.io/centos, Driver devicemapper failed to create image rootfs 6941bfcbbfca7f4f48becd38f2639157042b5cf9ab8c080f1d8b6d047380ecfc: Error running DeviceCreate (createSnapDevice) dm_task_run failed
If I try this without changing location - ok, no problems.
How to fix it?
1) service docker stop
2) thin_check /home/docker/devicemapper/devicemapper/metadata
3) thin_check --clear-needs-check-flag /home/docker/devicemapper/devicemapper/metadata
4) service docker start
As seen in issue 3721, this generally is a disk space issue.
The problem is that docker rmi doesn't always work in that case:
Getting this in v1.2 on CentOS 6.5 if a disk fills up before the image finishes pulling. Unable to rmi the incomplete image.
One "nuclear" option:
removing everything in /var/lib/docker worked out. Thanks
Another reason can be a common layer of fs to be downloaded between two images.
This was worked for me,
mv -f /var/lib/docker/* /data/tmp
systemctl restart docker.service
docker system prune -a
this could be caused when disk usage got full you can check this by doing df -h if so clean up unwanted space or can prune docker by doing docker system prune once after freeing up space , stop docker because thin_check cannot be run on live metadata.
systemctl stop docker
thin_check /var/lib/docker/devicemapper/devicemapper/metadata
check for error if noting clear check flag by
thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata
then start docker
systemctl start docker.service
if thin check not installed
yum install -y device-mapper-persistent-data
for centos
apt-get install -y thin-provisioning-tools
Got this today.
sudo reboot
Problem's out.
I encounter another dm_task_run issue during docker import, for my case, I yum erase docker.x86_64; yum install docker.x86_64; systemctl start docker.service works.
I went through the list of debian packages in bio-ngs (http://blends.debian.org/med/tasks/bio-ngs) and tried to install them in a docker container based on Ubuntu Precise.
I did it manually by doing a sudo docker run [...] /bin/bash and doing apt-get install on each package.
I then tried to docker commit and docker push the container with everything in bio-ngs, and it tried to upload the 1.215 GB of data in one go.
A few seconds after starting the process, it failed with this error:
4160cce5fef0: Pushing [=> ] 24.42 MB/1.215 GB 1h6m34s
2014/02/19 17:07:37 Failed to upload layer: Put https://registry-1.docker.io/v1/images/4160cce5fef01ae777b856c15a42e0a632021d1891c33f29018024e35aed60be/layer: write tcp 54.224.119.89:443: broken pipe
Any ideas?