See https://github.com/spring-projects/spring-boot/issues/46665 for background.

On an ARM Mac, building an image with default configuration and then building it again with the image platform set to linux/amd64 results in a failure:

> Task :bootBuildImage
Building image 'docker.io/library/demo:0.0.1-SNAPSHOT'

 > Pulling builder image 'docker.io/paketobuildpacks/builder-noble-java-tiny:latest' for platform 'linux/amd64' ..................................................
 > Pulled builder image 'paketobuildpacks/builder-noble-java-tiny@sha256:ae0cd71a4e28e3c3ba07fc409d197f04d28ed321910a2474eeb496e37d6ecc05'

> Task :bootBuildImage FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':bootBuildImage'.
> Image platform mismatch detected. The configured platform 'linux/amd64' is not supported by the image 'docker.io/paketobuildpacks/builder-noble-java-tiny:latest'. Requested platform 'linux/amd64' but got 'linux/arm64'

Wiping the state of the Docker daemon (docker system prune --all --force) and re-running the build fixes the problem.

This was diagnosed using 3.5.4 so I've assigned the issue to 3.5.x for now. 3.4.x may also be affected.

Comment From: bzsil8989

Is this issue still available for contribution?

Comment From: philwebb

@bzsil8989 It's not assigned to anyone, but it might be a little tricky to fix given the complexity around that area of the codebase.

Comment From: heruan

Would be great to have this fixed in 4.0

Comment From: hojooo

While testing this issue with Docker Desktop’s “Use containerd for pulling and storing images” enabled, I observed that current Docker API usage supports multi-arch during pull/create, but not during inspect/export.

Environment

  • Docker Engine API: v1.51 (I haven't checked it in other versions.)
  • Docker Desktop: M1 processor, Use containerd for pulling and storing images = ON gradle bootBuildImage { builder = "paketobuildpacks/builder-noble-java-tiny:latest" imageName = "demo:v1" imagePlatform = "linux/amd64" buildpacks = ["paketobuildpacks/java","paketobuildpacks/opentelemetry:2"] }

What’s happening

  • With the containerd image store, a tag like builder-noble-java-tiny:latest is kept as a multi-platform index (manifest list) locally.
  • DockerApi still inspects images using API v1.41, where GET /images/{name}/json does not support selecting a platform. In this case the daemon resolves the index using the host default platform (on Apple Silicon -> linux/arm64).
  • Meanwhile bootBuildImage is asking for linux/amd64. Result: inspect sees arm64 but the build requires amd64 → platform mismatch.

Quick confirmation from the socket:

  • Calling /v1.41/images/.../json?platform=linux/amd64 has no effect (param ignored).
  • Calling /v1.51/images/.../json?platform={"os":"linux","architecture":"amd64"} returns the amd64 manifest as expected (starting in API v1.49 the platform query is supported, and it expects an OCI Platform JSON).

Root cause

  • using ?platform= at pull/create (OK on v1.41).
  • But at inspect/export still rely on v1.41 (no platform selection), which only worked in the classic image store because the tag usually pointed at a single manifest. With containerd’s multi-arch index, that assumption breaks.

Workarounds for affected users (temporary)

  • Set DOCKER_DEFAULT_PLATFORM=linux/amd64, or
  • Disable the containerd image store temporarily

I think I need to bump the PLATFORM_API_VERSION(1.41 now) or switch to per-endpoint minimums. I’m looking for feedback on the overall approach. Thanks.