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

Issue pulling redis:alpine - no matching manifest #115

Closed
rk23 opened this issue Dec 1, 2017 · 16 comments
Closed

Issue pulling redis:alpine - no matching manifest #115

rk23 opened this issue Dec 1, 2017 · 16 comments

Comments

@rk23
Copy link

rk23 commented Dec 1, 2017

alpine: Pulling from library/redis
no matching manifest for linux/amd64 in the manifest list entries

@austinpray
Copy link

same here for docker pull redis:latest

╭─austin@arch-tower  ~  
╰─$ docker pull redis:latest
latest: Pulling from library/redis
no matching manifest for linux/amd64 in the manifest list entries
╭─austin@arch-tower  ~  
╰─$ uname -r                                                                                                                                                  1 ↵
4.13.12-1-ARCH

@tominkozhimala
Copy link

tominkozhimala commented Dec 1, 2017

Looks like redis 4.0.5 images were pushed in the last 30 minutes: #114 (comment)

using redis:4.0.4-alpine is my workaround at the moment. Have not tested with the non-alpine redis:4.0.4 yet

@kevin-brown
Copy link

As far as I can tell, this issue specifically affects the amd64 variants of the Redis image. While all of the other architectures were updated 30 minutes ago, the amd64 variant still shows 19 hours ago.

https://hub.docker.com/r/amd64/redis/

@yosifkit
Copy link
Contributor

yosifkit commented Dec 1, 2017

Yup, the amd64 builder is a bit backed up at the moment. The alpine image causes a rebuild of all images dependent on it. It doesn't have to rebuild the Debian variants, but still has quite a few to run through.

@hairyhenderson
Copy link

@yosifkit can the manifest be re-pointed to point to an available amd64 image?

@yosifkit
Copy link
Contributor

yosifkit commented Dec 1, 2017

@hairyhenderson, not really; the manifest lists that point to the architectures are controlled with the content of the official-images repo via jenkins jobs.

@Armour
Copy link

Armour commented Dec 1, 2017

lol same problem here

@stevvooe
Copy link

stevvooe commented Dec 1, 2017

Confirmed:

$ sudo ctr content fetch-object docker.io/library/redis:4.0.5-alpine
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1775,
         "digest": "sha256:f23d254c27af80cfde43600baa117cecb20cbaafe30a1ea33fe955a81890e333",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }
      }
   ]
}

@stevvooe
Copy link

stevvooe commented Dec 1, 2017

Btw, above, alpine is shown, but this is the same for latest, as well. It seems the manifest list was not assembled correctly and only the arm64 arch was pushed.

@yosifkit
Copy link
Contributor

yosifkit commented Dec 1, 2017

The manifest is correct; it was built with images from all arches that match redis:4.0.5-alpine and are built. It cannot manifest push something that does not yet exist. As I stated earlier, the amd64 builder is still working through its queue.

@stevvooe
Copy link

stevvooe commented Dec 1, 2017

@yosifkit The problem is that this was pushed to redis:latest before being ready, as well. We have the same partial there:

~/g/s/g/c/containerd ❯❯❯ sudo ctr content fetch-object docker.io/library/redis:latest                                                                                                                                                                              tags/v1.0.0-rc.0^0 ✭ ◼
INFO[0000] resolving                                     ref="docker.io/library/redis:latest"
INFO[0000] fetching                                      ref="docker.io/library/redis:latest"
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1571,
         "digest": "sha256:420ae0e3bb344f8a8d2059f6286dfcb9328e65b9e1e0f7f359f1ac5d8ae6f9c6",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }
      }
   ]
}

@kevin-brown
Copy link

image
Huzzah!

I suspect this issue is now solved or will be solved very shortly.

@yosifkit
Copy link
Contributor

yosifkit commented Dec 1, 2017

Correct, the amd64 build server got to the redis images so they are up in am64/redis and should be up in the manifest lists in library/redis in the next few minutes.

Similar issues: docker-library/hello-world#39, docker-library/official-images#3622 (comment), docker-library/wordpress#239, docker-library/ruby#159, docker-library/rabbitmq#188, docker-library/ghost#106.

@jfreidin
Copy link

jfreidin commented Dec 1, 2017

Seems to be working now.

@yosifkit
Copy link
Contributor

yosifkit commented Dec 1, 2017

Yup, arm64v8 and amd64 are in the manifest now:

$ manifest-tool inspect redis
Name:   redis (Type: application/vnd.docker.distribution.manifest.list.v2+json)
Digest: sha256:d72c77f82798d202b041deb2144944b6c5c6c9d188cfb98f54814cfe57e0afa0
 * Contains 2 manifest references:
1    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
1       Digest: sha256:78175fc7ec4622809837400af449ed2c7c05a9bbdf773d86cac2817dbbc29547
1  Mfst Length: 1571
1     Platform:
1           -      OS: linux
1           - OS Vers: 
1           - OS Feat: []
1           -    Arch: amd64
1           - Variant: 
1           - Feature: 
1     # Layers: 6
         layer 1: digest = sha256:d13d02fa248db2b423d6dbc8ec435675d23122f3939b5278b2156b75258e2259
         layer 2: digest = sha256:039f8341839ed6c0ca916876566d7193c33a80ae461cba558d85832436f59650
         layer 3: digest = sha256:21b9cdda7eb9fa2604e34311ddfbf9bb9e3b8a67d6c1668a9dc802f27855dcdd
         layer 4: digest = sha256:3c82f73f66c7f3f18e90e6dca2322976d55da72ddc19ccd9c9a07a75bedc49b7
         layer 5: digest = sha256:d3632c5436ac3d35cd519bc9da1751606a6bd465e9e9c6ae950a571178c2d641
         layer 6: digest = sha256:5c3e9840aa4b79fe3929fc6f83c84511828b573fb78669d5506cef9a8a87edd8

2    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
2       Digest: sha256:420ae0e3bb344f8a8d2059f6286dfcb9328e65b9e1e0f7f359f1ac5d8ae6f9c6
2  Mfst Length: 1571
2     Platform:
2           -      OS: linux
2           - OS Vers: 
2           - OS Feat: []
2           -    Arch: arm64
2           - Variant: v8
2           - Feature: 
2     # Layers: 6
         layer 1: digest = sha256:f2da27d97c13e9e531eda9577a28eb81b0d9034d7fd7e6575bd92744eed500f6
         layer 2: digest = sha256:a05e1313d9bb5766ff6bdeb2dde2e7f01045ac9c7df071253d3dc226d7cbe691
         layer 3: digest = sha256:9d8c747456b46f024d9fda80792b271a2396f5d11f0adb7def45ec25548f8ab7
         layer 4: digest = sha256:ae1c8d095ad5784c909a93462870783d0e438138239c50cc50859d94f9e8b9b6
         layer 5: digest = sha256:8821085efd9701c7901c95d2f49be4bc196b25b133b3d1fad4ccdeae02dc57fe
         layer 6: digest = sha256:81ace674017b514e90e48317cc41e990125e7e53d5808e2e4c26e064def374db

@tianon
Copy link
Contributor

tianon commented Dec 21, 2017

I've filed docker-library/official-images#3835 in order to have a central place to track this problem globally more directly. 👍 ❤️

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

10 participants