From unknown error cannot read manifest

Solving ‘manifest not found’ Error While Pulling Docker Images

We self-host Ghost using Docker for our website Linux Handbook.

I was following his documents to update the Ghost version but I was greeted with an error that read this:

Pulling ghost (ghost:4.39.0).
ERROR: manifest for ghost:4.39.0 not found: manifest unknown: manifest unknown

If you are trying to pull a Docker image and it shows the manifest not found error, here’s what you need to know about solving it.

Manifest unknown because there is no such Docker image

That’s the root cause in almost all of cases involving this error. The particular docker image you are trying to pull does not exist.

How is that possible? There could be several reasons for that.

• You made a typo while using a specific tag or version of the Docker image. For example, if it is version 20.04 and you typed 20.4, it will not find the image.
• You tried to download a version which is not available in Docker image yet. For example, in my case, Ghost version 4.39 was released but the latest Docker image was still tagged at version 4.38.1.
• If you are trying to download from a private repository, you may have to log in first: docker login repository_details

Basically, you should double check the name and tag of the Docker image you are trying to pull from the repository. For example, it is common to use the latest tag while getting the Docker image but some images might not even have the latest tag (which is rare but possible).

If you are pulling the image from the Docker Hub (like most people), you can go to its web interface and see the name and available tags.

Double check the name and available tags of a Docker image

I hope this helps you troubleshoot the unknown manifest error with Docker. If you still have any questions, please feel free to leave a comment below.

Источник

docker registry keep showing manifest unknown error for image pull after somedays of push image #17031

I am facing a very strange behaviour of docker registry. When I pushed a image it works fine for some days and after somedays it start giving manifest unknown error while pulling image to any node, which is due to self sign certificate. when I pushed the image again to docker registry then it start working. This issue is not to a particular image, I am facing this issue to multiple images which I am using.

Version

Steps To Reproduce

1. Pushed to multiple images to docker registry
2. Use the image to deploy pods
3. After someday try to use the image again.

Current Result

image pulling to node start giving manifest unknown error which is due to self sign certificate of register. please find below some of lines of docker registry logs while pulling the image.
time=»2017-10-25T11:40:29.560401847Z» level=debug msg=»(*blobDescriptorService).Stat: could not stat layer link sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3 in repository default/nginx-admin-proxy: unknown blob» go.version=go1.7.5 http.request.host=»172.30.16.81:5000″ http.request.id=f1ac7e85-30cb-48bb-a189-fcbbba582694 http.request.method=GET http.request.remoteaddr=»10.131.0.1:41488″ http.request.uri=»/v2/default/nginx-admin-proxy/manifests/sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ http.request.useragent=»docker/1.12.6 go/go1.7.4 kernel/3.10.0-514.26.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(Go-http-client/1.1)» instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.auth.user=»system:serviceaccount:bayboon-common-data:default» openshift.logger=registry vars.name=»default/nginx-admin-proxy» vars.reference=»sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ time=»2017-10-25T11:40:29.560500027Z» level=debug msg=»filesystem.Stat(»/docker/registry/v2/blobs/sha256/3d/3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3/data»)» go.version=go1.7.5 http.request.host=»172.30.16.81:5000″ http.request.id=f1ac7e85-30cb-48bb-a189-fcbbba582694 http.request.method=GET http.request.remoteaddr=»10.131.0.1:41488″ http.request.uri=»/v2/default/nginx-admin-proxy/manifests/sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ http.request.useragent=»docker/1.12.6 go/go1.7.4 kernel/3.10.0-514.26.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(Go-http-client/1.1)» instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.auth.user=»system:serviceaccount:bayboon-common-data:default» openshift.logger=registry trace.duration=21.749µs trace.file=»/go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/vendor/github.com/docker/distribution/registry/storage/driver/base/base.go» trace.func=»github.com/openshift/origin/vendor/github.com/docker/distribution/registry/storage/driver/base.(*Base).Stat» trace.id=6b21ce62-0ec9-4b07-a1a0-dbb987c8a964 trace.line=137 vars.name=»default/nginx-admin-proxy» vars.reference=»sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ time=»2017-10-25T11:40:29.560563132Z» level=debug msg=»(*pullthroughManifestService).remoteGet: starting with dgst=sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ go.version=go1.7.5 http.request.host=»172.30.16.81:5000″ http.request.id=f1ac7e85-30cb-48bb-a189-fcbbba582694 http.request.method=GET http.request.remoteaddr=»10.131.0.1:41488″ http.request.uri=»/v2/default/nginx-admin-proxy/manifests/sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ http.request.useragent=»docker/1.12.6 go/go1.7.4 kernel/3.10.0-514.26.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(Go-http-client/1.1)» instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.auth.user=»system:serviceaccount:bayboon-common-data:default» openshift.logger=registry vars.name=»default/nginx-admin-proxy» vars.reference=»sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ time=»2017-10-25T11:40:29.560596714Z» level=debug msg=»(*cachedImageStreamGetter).getImageStream: returning cached copy» go.version=go1.7.5 instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.logger=registry time=»2017-10-25T11:40:29.560655693Z» level=info msg=»(*repository).getImage: returning cached copy of sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ go.version=go1.7.5 instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.logger=registry time=»2017-10-25T11:40:29.582463099Z» level=debug msg=»(*cachedImageStreamGetter).getImageStream: returning cached copy» go.version=go1.7.5 instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.logger=registry time=»2017-10-25T11:40:29.582541602Z» level=debug msg=»(*cachedImageStreamGetter).getImageStream: returning cached copy» go.version=go1.7.5 instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.logger=registry I1025 11:40:29.589047 1 logs.go:41] http: TLS handshake error from 10.128.2.1:34170: EOF time=»2017-10-25T11:40:29.58904177Z» level=error msg=»error getting remote repository for image »172.30.16.81:5000/default/nginx-admin-proxy:latest»: Get https://172.30.16.81:5000/v2/: x509: certificate signed by unknown authority» go.version=go1.7.5 http.request.host=»172.30.16.81:5000″ http.request.id=f1ac7e85-30cb-48bb-a189-fcbbba582694 http.request.method=GET http.request.remoteaddr=»10.131.0.1:41488″ http.request.uri=»/v2/default/nginx-admin-proxy/manifests/sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ http.request.useragent=»docker/1.12.6 go/go1.7.4 kernel/3.10.0-514.26.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(Go-http-client/1.1)» instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.auth.user=»system:serviceaccount:bayboon-common-data:default» openshift.logger=registry vars.name=»default/nginx-admin-proxy» vars.reference=»sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ time=»2017-10-25T11:40:29.589157868Z» level=error msg=»response completed with error» err.code=»manifest unknown» err.detail=»Get https://172.30.16.81:5000/v2/: x509: certificate signed by unknown authority» err.message=»manifest unknown» go.version=go1.7.5 http.request.host=»172.30.16.81:5000″ http.request.id=f1ac7e85-30cb-48bb-a189-fcbbba582694 http.request.method=GET http.request.remoteaddr=»10.131.0.1:41488″ http.request.uri=»/v2/default/nginx-admin-proxy/manifests/sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ http.request.useragent=»docker/1.12.6 go/go1.7.4 kernel/3.10.0-514.26.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(Go-http-client/1.1)» http.response.contenttype=»application/json; charset=utf-8″ http.response.duration=89.215108ms http.response.status=404 http.response.written=139 instance.id=b6257207-4462-4d16-8ed4-e28c2d8a14a3 openshift.auth.user=»system:serviceaccount:bayboon-common-data:default» openshift.logger=registry vars.name=»default/nginx-admin-proxy» vars.reference=»sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3″ 10.131.0.1 — — [25/Oct/2017:11:40:29 +0000] «GET /v2/default/nginx-admin-proxy/manifests/sha256:3d682e445326bd456d83f080b3a5844965899b5cfb31fae57f130ffeb1510bd3 HTTP/1.1» 404 139 «» «docker/1.12.6 go/go1.7.4 kernel/3.10.0-514.26.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(Go-http-client/1.1)»

Expected Result

It should be able to pull image.

The text was updated successfully, but these errors were encountered:

Источник

How to Solve Error Message manifest unknown: manifest unknown when executing podman to pull image

Introduction

This is an article where the main focus is how to solve an error message appear. The error appear is exist as in the title of this article. It is the short form of the error message. The error message appear upon executing a certain command in a Linux operating system. It is a command for pulling image using ‘podman’ tool or ‘podman’ command. So, the following is the full form of the error message appear upon executing the command execution as part of the output :

Actually, the above command execution is triggering a specific output of listing the image repository server. The list actually available in the container configuration file. The container configuration file itself exist in ‘/etc/containers/registries.conf’. The configuration line which is becoming the base for the image repository server exist as part of the original configuration as follows :

The above configuration line is a v2 configuration syntax pattern. As it appears in the above configuration line, it is a definition or a declaration of image repository server list separated by a comma. There are four of them as it also appear in the list of the image repository server as part of the output command above. So, after selecting one the image repository server, the following output after the command execution appear :

Basically, the main error message in the following part :

Solution

The solution for solving the above problem is quite simple. Before pulling the image, just check it first. Search it in the image repository server to make sure that the image is actually exist. Run the following command :

So, basically pulling the image with the name of ‘localhost’ is the same as pulling a non-exist image. That is why the error message above is showing ‘manifest unknown: manifest unknown’. Because the image does not exist in the first place and podman generate an error message informing that. Just compare with another image with the name of ‘mysql’ as follows :

Источник