## Background #3665 (merged 2026-05-09) fixed the immediate symptom of #3515 — remote Quarkus builds failing on s390x/ppc64le clusters — but the root cause remained: `DefaultBuilderImages["quarkus"]` is hardcoded to `gcr.io/paketo-buildpacks/builder:base`, which only ships an `amd64` manifest. Without a regression test, an equivalent issue can recur silently the next time a non-amd64 architecture surfaces. ## Analysis (credit @dikshant182004) When a non-amd64 cluster (s390x, ppc64le) selects the current Quarkus default builder, the OS attempts to execute an amd64 binary on a non-amd64 chip and immediately throws `exec format error`. The `DefaultBuilderImages` map in `pkg/buildpacks/` selects the builder image purely by language, with no platform awareness. ## Proposed solution 1. **Swap the Quarkus default builder** to a multi-arch image (`amd64`, `s390x`, `ppc64le`, `arm64`). ```go DefaultBuilderImages = map[string]string{ // ... "quarkus": "paketobuildpacks/builder-ubi8-base", // candidate — multi-arch UBI } ``` **Open question:** `paketobuildpacks/builder-ubi8-base` vs an internal `quay.io/boson/...` image. I'll surface this with the team and follow up before implementation starts. 2. **Architecture-mismatch warning** in `BuilderImage()` — if a user has manually pinned an amd64-only builder in their `func.yaml` and tries to build on s390x/ppc64le, emit a clear actionable error instead of the raw `exec format error`. 3. **Regression test** for builder-image selection on non-amd64 platforms so this can't recur silently. ## Verification Should be verified end-to-end on an actual s390x or ppc64le cluster. Hardware-access question is open with @Itx-Psycho0 / @dikshant182004; if neither has access I'll arrange something on our side. ## Related - #3515 — original report (closed by #3665, partial workaround) - #3665 — the targeted fix that closed #3515