Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manifest unknown for docker pull docker:* #520

Closed
max-sternitzke opened this issue Dec 14, 2024 · 18 comments
Closed

Manifest unknown for docker pull docker:* #520

max-sternitzke opened this issue Dec 14, 2024 · 18 comments

Comments

@max-sternitzke
Copy link

Hey there,

since your recent docker image push today 14th Dec 6:05 UTC i cannot pull any docker image from the official docker registry.
I tried a docker pull:

  • docker:27.4.0-dind
  • docker:27.4.0
  • docker:latest
  • docker:dind

All these result in a manifest for docker:dind not found: manifest unknown: manifest unknown

I have not modified my docker/daemon.json. My local Docker version is Docker version 27.4.0, build bde2b89 on the latest macOS. This problem also occurs on remote Ubuntu VMs.

I'm sorry if its my mistake, but it seems suspicious that the problem occured just after your image push and has not yet been resolved. (We're running a ci pipeline every 5 minutes and it first failed at 6:13am UTC this morning.)
If you need anything, just let me know.

Thanks for any hint or solution. Cheers
Max

@azlkiniue
Copy link

for now i'm downgrading to version 26 temporarily
pulling docker:26-dind or docker:26 is working for me

@oxilor
Copy link

oxilor commented Dec 14, 2024

This error started to occur only 4 hours ago since the version 27.4.0 was released. No need to downgrade to docker:26-dind because the previous version docker:27.3.1-dind is also working.

So just replace docker:dind with docker:27.3.1-dind temporarily.

@nalingovind
Copy link

This worked for me docker:26-dind

@tanc
Copy link

tanc commented Dec 14, 2024

docker:27.3-dind works fine but latest fails

@oleksandrmikhnenko
Copy link

dind and latest tags are also affected

@nfacha
Copy link

nfacha commented Dec 14, 2024

Also experiencing this with the dind tag

@muocod
Copy link

muocod commented Dec 14, 2024

The same shit here

@thaJeztah
Copy link
Contributor

This looks to be a duplicate of #519

👋 I work at docker, but not on the official images; I'm currently trying our internal slack chatting with folks on call to see if someone working on official images is available to look.

It looks like the "manifest-index" for the image exists, but the image that's referenced from it is either missing, or resulting in the "not found".

As a workaround, it looks like the previous versions of the image are functional, so if you pin to the previous version, you can use that as a workaround, e.g.;

docker pull docker:27.3.1-dind / docker pull docker:27.3.1-cli both work

@max-sternitzke
Copy link
Author

This looks to be a duplicate of #519

It sure is @thaJeztah . As i was starting to file the issue the was none, after submitting there were two :)

You better reach someone soon - many pipelines are failing just now because of this.

@arthurlm44
Copy link

The missing tag has completely collapsed our CI system.

@0xCiBeR
Copy link

0xCiBeR commented Dec 14, 2024

Same behavior here, we manged to work arround the issue pointing to this image: docker pull public.ecr.aws/docker/library/docker:dind

EDIT: docker:27.3.1-dind also works perfectly, thanks @oxilor

@marcschroeder
Copy link

marcschroeder commented Dec 14, 2024

I think we should keep in mind that most of us are using Docker and Docker Official Images without paying for it... Keep in mind that the teams around such tools are putting a lot of effort in to make such great OSS software available to us. I understand that is might be frustrating to see some CIs failing - but no need for strong words & demands such as in the comments above IMHO...
PS: Thanks to everyone working on resolving this for the community!!

@thaJeztah
Copy link
Contributor

I can give an intermediate status update from the Slack thread.

Team is still looking. They managed to narrow down the cause of the issue to be related to cross-repo links. The image was pushed successfully (data / blobs are there), but some links were not created after the push, causing it to be producing a 404 for those references. A fix was deployed that should prevent this situation from happening, but won't automatically apply to content that's already there, and those parts are really locked down, so no direct access to (manually) correct, so they're currently checking logs to identify images that are affected (beyond the ones mentioned in this ticket), and to see if there's ways to correct it. Re-pushing the images (same image, but trigger a push again) may work, but may also be locked down (currently being looked into).

@thaJeztah
Copy link
Contributor

OK, team was able to get the list of images affected, and may have found a solution; some manual work is involved, so fixes may roll out over time. I'll post updates once available.

@max-sternitzke
Copy link
Author

max-sternitzke commented Dec 14, 2024

docker:dind is working for me again. Thanks for the work @thaJeztah & team! 🎉

Nevertheless I have to disagree with @marcschroeder on the comments here part quite a bit. After the weekend the Docker team will recap that for sure and draw the necessary conclusions so such a situation will most likely not happen again and/or will be monitored more closely by themselves.

@MrCskncn
Copy link

"the one should not release a version on friday evenings."

@thaJeztah
Copy link
Contributor

x-posting from the other ticket;

I think they managed to go through most of the list by now, but some may still be pending. Currently verifying all tags and all variants of those images (which takes a while to run).

There may be some images in the platform-specific orgs that are used as intermediate image that may not yet be addressed, and (given much lower / corner-case use), e.g. images in the platrform-specific namespace (e.g. https://hub.docker.com/u/arm64v8/, and other similar namespaces listed in; https://github.com/docker-library/official-images#architectures-other-than-amd64. Those namespaces are effectively intermediate stages for the multi-platform images.

OK; colleague confirmed that the list of official images should be all processed. The verification script will still be running for some hours, but we're updating the statuspage to "monitoring"

There may be some images in the platform-specific orgs that are used as intermediate image that may not yet be addressed, and (given much lower / corner-case use), e.g. images in the platrform-specific namespace (e.g. https://hub.docker.com/u/arm64v8/, and other similar namespaces listed in; https://github.com/docker-library/official-images#architectures-other-than-amd64. Those namespaces are effectively intermediate stages for the multi-platform images.

These images will likely be processed later, which may be done after the weekend.

@LaurentGoderre
Copy link
Member

Closing in favor of #519. It should be mostly resolve now though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests