Why Docker Manifest Inspection Fails for Multi‑Arch Images and How to Fix It

When pulling the image knatnetwork/github-runner-amd64:focal-2.301.1 everything works, but trying to inspect its manifest returns no such manifest.

$ docker pull knatnetwork/github-runner-amd64:focal-2.301.1
... (output omitted) ...
Status: Downloaded newer image for knatnetwork/github-runner-amd64:focal-2.301.1

Running

docker manifest inspect knatnetwork/github-runner-amd64:focal-2.301.1

yields the same error.

$ docker manifest inspect knatnetwork/github-runner-amd64:focal-2.301.1
no such manifest: docker.io/knatnetwork/github-runner-amd64:focal-2.301.1

In April 2022 the author open‑sourced a GitHub Actions self‑hosted runner. The build process creates two images in parallel – one for amd64 and one for arm64 – and then merges them into a multi‑arch image knatnetwork/github-runner:focal-2.301.1 using docker manifest. This worked for a long time until a recent merge step failed with:

failed to put manifest docker.io/knatnetwork/github-runner:focal-2.301.1: errors:
manifest blob unknown: blob unknown to registry

The author considered three possible causes: a Docker version change in the runner environment, changes in docker/login-action or docker/build-push-action (or their underlying components like buildx), or an outage of DockerHub/GHCR. The registry outage was ruled out.

Inspecting the Docker client and server versions showed only patch‑level updates, but the Buildx version had been upgraded from 0.9.1+azure-2 to 0.10.0+azure-1. Buildx 0.10 introduces a default SLSA provenance attestation, which adds an additional manifest of type application/vnd.oci.image.index.v1+json and causes the merged image to be reported as a manifest list.

To fetch the correct manifest the author wrote a shell script that sends both Docker and OCI Accept headers. The script revealed that the problematic image returned an OCI index with an attestation manifest entry:

{
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "schemaVersion": 2,
  "manifests": [
    {"mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:...", "platform": {"architecture": "amd64", "os": "linux"}},
    {"mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:...", "annotations": {"vnd.docker.reference.type": "attestation-manifest"}, "platform": {"architecture": "unknown", "os": "unknown"}}
  ]
}

The attestation originates from BuildKit’s support for SBOM and SLSA provenance. While it does not affect single‑arch images, it breaks the later docker manifest merge when multiple architectures are involved.

Solution: disable the default provenance and SBOM generation in docker/build-push-action by adding the following lines to the workflow:

provenance: false
sbom: false

After this change the manifest inspection returns a normal Docker manifest and the merge succeeds.

Additional observations: the initial "manifest blob unknown" error was caused by trying to merge two images that were not in the same repository/tag namespace. The final recommendation is to either disable the new attestation feature or build the multi‑arch image in a single Buildx run.