Repository navigation
Makefile/ko build targets hardcode linux/amd64, breaking arm64 clusters #358
Description
Problem
make deploy and make push only ever produce linux/amd64 images, regardless of the target cluster's architecture:
deploy-controller/deploy-serverinvokeko applywith no--platformflag, andko's default build platform islinux/amd64regardless of host OS/arch.build-task-runnerhardcodesGOOS=linux GOARCH=amd64for the cross-compile and--platform linux/amd64for the container build.Dockerfile.task-runnerhardcodesCOPY bin/linux_amd64/ax-task-runner ....
Deploying to an arm64 cluster (e.g. a k3s/Raspberry Pi cluster) with make deploy AX_IMAGE_REPO=... silently builds and pushes amd64 images. Pods then fail with exec format error once they actually pull and try to run.
Fix
I have a fix ready on a branch, but google/ax's pull_request_creation_policy is set to collaborators_only, so I can't open a PR from a fork (github.com/loafoe/ax) — hence this issue instead.
Branch: https://github.com/loafoe/ax/tree/arm64-platform-support
Commit: loafoe@c1d58ba
Summary of the fix:
- Adds
KO_PLATFORM(defaultlinux/amd64, unchanged behavior) used asko apply --platform=$(KO_PLATFORM)indeploy-controller/deploy-server. - Adds
TASK_RUNNER_PLATFORM(defaultlinux/amd64) drivingGOARCH,--platform, and a newTASK_RUNNER_GOARCHbuild-arg passed toDockerfile.task-runner, which now doesCOPY bin/linux_${TASK_RUNNER_GOARCH}/ax-task-runner ...instead of a hardcoded amd64 path. - Verified:
make build-task-runner TASK_RUNNER_PLATFORM=linux/arm64produces a realELF ... ARM aarch64binary, andmake deploy AX_IMAGE_REPO=... KO_PLATFORM=linux/arm64was used to successfully deployax-controller/ax-serverto a live arm64 k3s cluster.
Happy to open a proper PR if I'm added as a collaborator, or if the PR creation policy is relaxed to allow contributions from forks.
Activity
loafoe commentedon Sep 21, 2026
One more data point: CONTRIBUTING.md documents a standard fork → branch → PR workflow ("Fork or Clone the Repository" ... "Open a pull request on GitHub") and says "All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose." That's inconsistent with the repo currently being configured with
pull_request_creation_policy: collaborators_only(confirmed viagh api repos/google/ax), which rejects PR creation from non-collaborators outright, including from forks like this one. This looks like it may be an unintentional repo setting rather than deliberate policy — flagging in case that's the case, since it'd block all external contributions as currently configured, not just this one.arbazkhan971 commentedon Sep 22, 2026
Two things. One: the arm64 fix itself is ready on my fork (branch
fix/358-arm64-build, build verified, test included) — happy to PR it.Two, the bigger ask: I now have fixes ready for 14 issues (#345, #346, #347, #348, #349, #350, #351, #352, #353, #354, #355, #358, #360, #362), each with a regression test and green suite, all sitting on my fork because
collaborators_onlyPR creation rejects external PRs. Other contributors (Ashfaqbs on #349 and more) are blocked the same way. As you note, this contradicts CONTRIBUTING.md's documented fork-to-PR workflow, so it looks unintentional.Request for maintainers: please open PR creation to contributors (or point us at a path to collaborator status / a sponsor). The moment it flips I will open all 14 PRs, and external contribution can flow generally — not just for me.
sharadregoti commentedon Sep 22, 2026
Hit this too on a kind cluster under Docker Desktop on an Apple Silicon Mac. One thing that cost me time debugging: the controller only surfaces
runsc start: exit status 128, nothing about architecture. The realexec format erroronly shows up if you dig into the ateom-gvisor worker pod's own logs.Remove experimental testagent and clean up controller (google#358)