track: exotic-arch builds (ppc64le, s390x, riscv64) — Apple QEMU support or mocker workaround

[kaovilai]

Problem

mocker build --platform linux/ppc64le (and s390x, riscv64) works for layer-only Dockerfiles (FROM/COPY/CMD) but fails with Exec format error on any RUN instruction. This is because container build delegates to Apple's BuildKit builder VM, which is an ARM64 Linux VM with no QEMU binfmt handlers registered for exotic architectures.

linux/amd64 works because Apple Silicon has Rosetta 2 hardware x86 translation — a unique accelerator that does not exist for Power or Z architectures.

macOS container tooling landscape

This is not unique to mocker — it affects all macOS-native container runtimes:

Tool	linux/arm64	linux/amd64	linux/ppc64le / linux/s390x
mocker (via container build)	✅ native	✅ Rosetta	❌ Exec format error on RUN
container build directly	✅ native	✅ Rosetta	❌ same
podman build via Podman machine	✅ native	✅ QEMU	✅ QEMU (qemu-user-static in Fedora CoreOS VM)
Docker Desktop	✅ native	✅ Rosetta	✅ QEMU

Podman machine ships a persistent Fedora CoreOS QEMU VM with qemu-user-static binfmt handlers pre-registered — this is why podman build --platform linux/ppc64le with RUN steps works today on macOS. The tradeoff is a shared, persistent VM (which has its own reliability issues: machine state corruption, memory overhead). The goal is to match or exceed Podman machine's architecture coverage without those tradeoffs.

Upstream tracking

Apple upstream issue filed: apple/container#1496 — [Request]: Support building for exotic architectures (ppc64le, s390x, riscv64) via QEMU emulation in the build VM

If Apple adds a build.qemu system property (analogous to build.rosetta), this issue resolves automatically. Monitor that issue.

Mocker workaround options (if Apple doesn't act)

Option A — Delegate to a running Podman machine VM

If the user already has a Podman machine running, its Fedora CoreOS VM has QEMU binfmt registered for all architectures. Mocker could detect this and proxy exotic-arch builds through it as a remote BuildKit node:

# Detect running Podman machine and register as a buildx remote
podman machine inspect --format '{{.SSHConfig.HostIP}}:{{.SSHConfig.Port}}'

docker buildx create \
  --name podman-qemu \
  --driver docker-container \
  --platform linux/ppc64le,linux/s390x,linux/riscv64 \
  "ssh://user@<podman-machine-ip>:<port>"

mocker build --platform linux/ppc64le -t myimage:ppc64le .  # routes through podman VM

Mocker could detect podman machine list for a running machine and wire this up transparently — reusing the QEMU capability already present rather than spinning up anything new.

Option B — Integrate with Skopeo / Buildah

skopeo (available at /Users/tkaovila/go/bin/skopeo) and buildah both understand multi-arch OCI operations. Investigate:

• buildah build --platform linux/ppc64le — does it delegate to a remote or fail the same way on macOS?
• skopeo copy --multi-arch all — can it assemble manifest lists from separately-built per-arch images?

Option C — container run --virtualization + QEMU inside

Spin up a Linux VM via container run --virtualization -it ubuntu:24.04 bash, install qemu-user-static + Docker inside, then build. Mocker could wrap this as mocker build --platform linux/ppc64le --via-qemu-vm that starts the VM, builds, extracts the image, and tears down automatically.

Option D — Remote builder integration (mocker builder)

Add a mocker builder create --platform linux/ppc64le ssh://user@host command that registers a remote BuildKit node. Exotic-arch builds route to the remote automatically when the local builder can't handle the platform. Works with any Linux host (Podman machine, GitHub Actions runner, IBM Cloud VSI, etc.).

Acceptance criteria

• Monitor [Request]: Support building for exotic architectures (ppc64le, s390x, riscv64) via QEMU emulation in the build VM apple/container#1496 — close this issue if Apple ships QEMU support in the build VM
• Evaluate Option A (Podman machine detection) — lowest friction if user already has Podman machine; no new VMs needed
• Evaluate Option B (buildah/skopeo integration) — pure-macOS path
• Document the remote builder workaround in README under "Building for exotic architectures"

Related

• [Request]: Support building for exotic architectures (ppc64le, s390x, riscv64) via QEMU emulation in the build VM apple/container#1496 — upstream QEMU build VM request
• feat: mocker manifest command for multi-arch OCI image index assembly #9 — mocker manifest command (needed to assemble per-arch images into a manifest list after exotic-arch builds)
• [Request]: Consistent and useful multi-platform semantics for pull, push, save, load, build. apple/container#913 — multi-platform semantics umbrella

Note

Responses generated with Claude

[us]

Status update: this stays open, blocked on apple/container#1496.

What we did in v0.3.0:

• Documented the limitation honestly in README under "Building for exotic architectures", with two workarounds (Podman machine, container run --virtualization + qemu-user-static)
• Verified the layer-only path: mocker build --platform linux/ppc64le -t test-ppc:v1 . with a Dockerfile containing only FROM/COPY/CMD works fine; only RUN instructions break with Exec format error

What we did NOT do:

• Option A (Podman machine remote builder integration) — deferred; user still has to run podman build manually for now
• Option C (container run --virtualization automation) — deferred; documented as a manual workaround

Recommendation: leave this open as the upstream tracking issue. If apple/container#1496 ships QEMU support, this resolves automatically. If we want a mocker-side workaround, Option A is the clearest follow-up (auto-detect running Podman machine, route exotic-arch builds through it).