Github Container Registry Packages lists the architecture unknown/unknown when manifest attestations are present
#45969
Replies: 7 comments 7 replies
|
appears to be a UI bug in GitHub Packages |
|
Take a look at docker/build-push-action#755. I was seeing the same issue. Pinning the build kit sorted it |
|
For images with an attestation, ghcr also does not display metadata – to me, this is actually more annoying than the additional |
|
If it's UI bug then I still have it in Jan-2024. And which give mes PS. Source Setting BTW, I used |
|
Any updates (solutions or workarounds) on this matter? I'm generating linux/amd64 and linux/arm64 using matrix but only one shows up in ghcr packages and there is the additional "unknown/unknown" as well. |
|
This truly is kinda annoying. Has there been any progress made? |
|
Hi all. This comment helps me. I've also encountered the unknown/unknown architecture appearing in ghcr.io when pushing multi-arch container images. I found that setting provenance: false and sbom: false within the docker/build-push-action@v6.18.0 effectively resolves this UI issue for me. See the build-push-action README for input details. - name: Build and push Docker image
uses: docker/build-push-action@v6.18.0
with:
# ... other parameters ...
provenance: false # Disable provenance to avoid unknown/unknown
sbom: false # Disable sbom to avoid unknown/unknownIt seems that by disabling the generation of these default build attestations, the non-platform-specific entries that ghcr.io's UI interprets as unknown/unknown are no longer included in the manifest list.
This results in a cleaner display showing only the architectures I explicitly built for (e.g., linux/amd64, linux/arm64). While attestations are valuable, this can be a practical workaround if the unknown/unknown display is problematic. actions workflow snippet to exclude the jobs:
# ... omitted for brevity ...
build-container:
steps:
# ... omitted for brevity ...
- name: Extract metadata
id: meta
uses: docker/metadata-action@v5
with:
images: ghcr.io/${{ env.IMAGE_NAME }}
tags: |
type=raw,value=${{ env.VERSION }}
# OCI Image Spec:
# https://github.com/opencontainers/image-spec/blob/main/annotations.md
labels: |
maintainer=${{ github.actor }}
org.opencontainers.image.description=${{ env.IMAGE_DESCRIPTION }}
env:
DOCKER_METADATA_ANNOTATIONS_LEVELS: manifest,index
- name: Build and push Docker image
uses: docker/build-push-action@v6.18.0
with:
context: box/kubernetes/eip-rotation-handler
platforms: linux/amd64,linux/arm64
push: true
tags: ${{ steps.meta.outputs.tags }}
annotations: ${{ steps.meta.outputs.annotations }}
build-args: |
VERSION=${{ env.VERSION }}
COMMIT=${{ github.sha }}
provenance: false # Disable provenance to avoid unknown/unknown
sbom: false # Disable sbom to avoid unknown/unknown
outputs: type=image,name=target |







Uh oh!
There was an error while loading. Please reload this page.
Select Topic Area
Bug
Body
I recently noticed that packages that have been pushed to the container registry using
docker buildx buildnow have a new architecture listed,unknown/unknown. After some further investigation, I discovered that what is happening is that the Docker Buildx CLI is including image attestations for these images, which seems harmless, but causes GitHub Packages to list theunknown/unknownarch used for these attestations under the "OS / Arch" tab. This is similar to another topic recently posted, but this is more of a UI bug rather than an issue inspecting or pulling the manifests.The current behavior means that if you push an image for
linux/arm64andlinux/amd64, you'll get three architectures listed,linux/arm64,linux/amd64, andunknown/unknown. Theunknown/unknownarch has a hash listed, but that is not shown in the version list anywhere unless you dig deep to find it. This appears to inconsistent with what the Docker Hub shows, which, in this case, would be only two architectureslinux/arm64andlinux/amd64.The behavior that I expect is to see only the number of architectures I built, potentially with the additional metadata included under those hashes, but the
unknown/unknownarch should not be listed anywhere since it is not a real architecture.All reactions