can1357/oh-my-pi · error · RuntimeError

binary mode: unsupported container arch {arch!r}

Error message

binary mode: unsupported container arch {arch!r}

What it means

In binary install mode, omp_local maps the container's detected CPU architecture (aarch64/arm64 or x86_64/amd64) to the matching prebuilt omp binary supplied by the host. If uname reports any other architecture, there is no binary to install and it raises this RuntimeError.

Source

Thrown at packages/metaharness/agent/omp_local.py:408

                'ver=$(bun -e "process.stdout.write(require(\\"./package.json\\").version)"); '
                'echo "pinning native @oh-my-pi/pi-natives-linux-$na@$ver"; '
                'bun add --production "@oh-my-pi/pi-natives-linux-$na@$ver"'
            ),
            timeout_sec=900,
        )
        return f"{app}/dist/cli.js"

    async def _install_binary(self, environment: BaseEnvironment) -> str:
        """Probe container arch, upload only the matching self-contained omp binary."""
        arch = (
            await self.exec_as_agent(environment, command="uname -m")
        ).stdout.strip()
        if arch in ("aarch64", "arm64"):
            hostbin = self._binary_arm64
        elif arch in ("x86_64", "amd64"):
            hostbin = self._binary_x64
        else:
            raise RuntimeError(f"binary mode: unsupported container arch {arch!r}")
        if not hostbin:
            raise RuntimeError(
                f"binary mode: no omp binary provided for container arch {arch}"
            )
        app_dir = f"{self._home}/.omp-bench"
        dst = f"{app_dir}/omp"
        staging = "/tmp/omp-bin"
        await self.exec_as_agent(
            environment, command=f"mkdir -p {shlex.quote(app_dir)}"
        )
        await environment.upload_file(hostbin, staging)
        await self.exec_as_agent(
            environment,
            command=f"cp {shlex.quote(staging)} {shlex.quote(dst)} && chmod +x {shlex.quote(dst)}",
        )
        self._cli = dst
        return dst

View on GitHub (pinned to 9690622007)

Solutions

1. Run the task on an arm64 or x86_64 container/host instead.
2. Use source install mode and build omp natively for the unsupported architecture.
3. If the arch string should be supported, extend the mapping in _install_binary (e.g. handle new uname spellings) and provide the corresponding binary.
4. Verify what uname -m prints in the container; fix --platform or image selection if it's not what you expected.

Example fix

# before
OMP_BENCH_INSTALL=binary ... (on s390x container)  # raises
# after
OMP_BENCH_INSTALL=source ... (build natively) — or run on linux/amd64

import platform
arch = platform.machine()
if arch not in ("aarch64", "arm64", "x86_64", "amd64"):
    raise SystemExit(f"binary mode unsupported here ({arch}); use install=source")

try:
    await harness.install(env)
except RuntimeError as e:
    if "unsupported container arch" in str(e):
        harness = make_harness(install="source")
        await harness.install(env)
    else:
        raise

When it happens

Trigger: Running a binary-mode install inside a container whose uname -m output is neither arm64/aarch64 nor x64/x86_64/amd64 — e.g. riscv64, s390x, ppc64le, or an unexpected arch string.

Common situations: Exotic CI hardware (s390x/ppc64le runners); unusual emulated containers; a base image or runtime reporting a nonstandard machine string that the arch normalization doesn't cover.

Related errors

• source mode: container arch {arch!r} != mounted deps tree ar
• Unsupported architecture: ${arch}
• --binary: cannot infer arch from ${base} (expect arm64/x64 i
• cannot detect docker server arch (got ${a || "nothing"}); is
• No omp binary available for guest architecture ${vm.arch}

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/ce361cdebe86196d. Report an issue: GitHub.