In this article
No matching manifest during pulling and exec format error after launch can indicate different platform problems. Inspect the image index, CPU architecture and actual executable. A suitable GPU does not automatically make an amd64 binary compatible with arm64.
No matching manifest during pulling and exec format error after launch can indicate different platform problems. Inspect the image index, CPU architecture and actual executable. A suitable GPU does not automatically make an amd64 binary compatible with arm64.
Identify the failure stage
Preserve image reference, node architecture, OS and complete event text. If no platform manifest is found, the application has not started. If an executable was selected but cannot run, inspect image contents next. Scripts can also produce exec-format failures through an invalid interpreter declaration. Do not assign an architecture diagnosis from two error words alone; compare the actual file and launch method.
Inspect the published index
A Docker multi-platform image contains an index or manifest list with OS/architecture variants. The engine selects an appropriate one. Buildx imagetools inspect exposes published platforms and digests. Preserve the index digest and selected platform-specific manifest where relevant. These identify different layers useful for reproducible deployment. A tag called multiarch does not establish that the required variant exists; inspect actual metadata.
Compare two examples
First, a registry contains only linux/amd64 while the node uses linux/arm64. Without a suitable variant, pulling cannot simply select the intended image. Second, metadata declares arm64 but a layer accidentally contains an amd64 executable. Pulling may succeed before execution fails. Compare build provenance, platform metadata and actual binary. These examples concern publication diagnostics, not universal CUDA support across architectures and devices.
| Layer | Verification |
|---|---|
| Node | OS and CPU architecture |
| Image index | Required platform variant exists |
| Manifest | Selected digest and configuration |
| Executable | Actual architecture and interpreter |
Correct publication or placement
Publish a verified variant or place the workload on an explicitly supported platform. —platform is not a promise of native compatibility: forcing a variant can require emulation and does not solve GPU access. For multi-stage builds, inspect where binaries were copied from and which target platform was used. Preserve base-image and dependency versions. Correct CPU platform still requires independent checks of driver libraries and compute support.
Verify image contents
Inspect the newly published reference, then run a minimal executable on the intended node type. Preserve index and manifest digests, with compute verification recorded separately. Successful pulling establishes availability of the selected variant, not the full application. The artifact distinguishes a publication regression from runtime incompatibility after another build. If only a script fails, investigate its interpreter, line endings and permissions using observed evidence instead of repeatedly changing CPU architecture without justification. This preserves the distinction between selecting a declared platform and proving the files actually match it.
Related operational reading: arm vs x86 inference; software stack reproducibility.