Open pbo-linaro opened 2 days ago
Yes, this happened with https://github.com/docker-library/meta-scripts/pull/93. We finally have switched all our builds over to buildkit
, so they now include attached provenance (the item with unknown
os and architecture in the image index). (Similar issue in https://github.com/docker-library/python/issues/933)
$ docker run -i --rm gcr.io/go-containerregistry/crane manifest arm64v8/debian | jq .
{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.index.v1+json",
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:e2554fa0cd89eec5865aef4bf094c8d646059d37c42b44a6655839ea46ef3f90",
"size": 1041,
"platform": {
"os": "linux",
"architecture": "arm64",
"variant": "v8"
},
"annotations": {
"com.docker.official-images.bashbrew.arch": "arm64v8",
"org.opencontainers.image.base.name": "scratch",
"org.opencontainers.image.created": "2024-11-12T00:55:54Z",
"org.opencontainers.image.revision": "dde41269a09feb7d5b046133bdd54c918ecbf1ca",
"org.opencontainers.image.source": "https://github.com/debuerreotype/docker-debian-artifacts.git#dde41269a09feb7d5b046133bdd54c918ecbf1ca:bookworm",
"org.opencontainers.image.url": "https://hub.docker.com/_/debian",
"org.opencontainers.image.version": "bookworm"
}
},
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:75a53f5cf6b17ed7544a6de47a5a405a0fb20abb4fb0795e4ad13fe6dd5d6536",
"size": 840,
"platform": {
"os": "unknown",
"architecture": "unknown"
},
"annotations": {
"com.docker.official-images.bashbrew.arch": "arm64v8",
"vnd.docker.reference.digest": "sha256:e2554fa0cd89eec5865aef4bf094c8d646059d37c42b44a6655839ea46ef3f90",
"vnd.docker.reference.type": "attestation-manifest"
}
}
]
}
Thanks for the confirmation!
What's the goal to restrict the platform this way? It's already obvious for which platform arm64v8/image or amd64/image is made. And beyond doing cross architecture images, I don't see the point of those images (vs normal debian image, already published for various platforms).
Im curious as to why you are using the architecture namespace instead of docker run -it --rm --pull always debian
or docker run -it --rm --pull always docker.io/debian
This is a multi-stage build involving arm64 and amd64 images to provide a container combining wine (arm64) and qemu-aarch64, to run this on amd64 hosts. see this change.
But now we have to explicitely add platform parameter, probably it's better to switch to official debian image. It was just convenient to have those images per architecture with different names.
My main use case personally for the per-architecture images is to avoid the "vector matching" behavior and get an exact match -- for example, if I do docker pull --platform linux/arm/v6 debian:bookworm
, it will succeed, but I will transparently receive the linux/arm/v5
image because Debian does not explicitly support v6 and most (all?) v6 hardware can successfully run v5 binaries/images. If I were to instead do docker pull --platform linux/arm/v6 arm32v6/debian:bookworm
, I will get the 404 I might've expected (and I want both behaviors in different contexts -- ideally this would be part of the --platform
flag itself, but so far that's not implemented yet).
From an x64 machine,
Same when trying to run an amd64 image from an arm64 host. This used to work until very recently (~ weeks), and I suspect the image is now built with an explicit
--platform
parameter on your side.Even though it's possible to explicitly add a --platform on our side, it used to be very convenient to not have to do it for cross compilation scenarios and multi stage builds involving multiple architectures. It's definitely a niche usage though.
Was this changed recently? What was the rationale?