Pin node image to linux/amd64 - #164
Open
pucedoteth wants to merge 1 commit into
Open
Conversation
`hl-visor` and the `hl-node` binaries it downloads are published as x86-64
ELF executables only. `FROM ubuntu:24.04` resolves to the host's
architecture, so on an arm64 host (Apple Silicon, Graviton, arm64 CI)
`docker compose build` produces an arm64 image containing an amd64-only
binary.
Nothing fails at build time -- the download and `gpg --verify` both
succeed, since the fetched binary is fine. The image only breaks when it
is started, with an error that does not point at the cause:
ERROR: Dynamic loader not found: /lib64/ld-linux-x86-64.so.2
Confirmed on an arm64 host: the built image reports `arm64/linux`, while
the `hl-visor` it contains has ELF `e_machine = 0x3e` (x86-64), and the
container exits 255 on start.
Pinning the platform makes the image match its payload. On amd64 hosts
this is a no-op; on arm64 the image now runs under emulation instead of
failing. Verified by rebuilding with the pin on the same arm64 host: the
image reports `amd64/linux` and the node starts normally --
hl-visor @@ starting visor
hl-visor @@ child status @@ [start_time: ...] @ [n_restarts: 0]
hl-visor @@ downloading new hl-node binary @@ [chain: Testnet] @ [index: 1186]
The pruner image is left alone: it only runs shell tooling, so it is
genuinely architecture independent and should keep building natively.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
hl-visor(and thehl-nodebinaries it downloads) are published as x86-64 ELF executables only. The rootDockerfileuses:FROM ubuntu:24.04which resolves to the host's architecture.
ubuntu:24.04publishes an arm64 manifest, so on an arm64 host — Apple Silicon, Graviton, arm64 CI runners —docker compose buildproduces an arm64 image containing an amd64-only binary.Nothing fails at build time. The download succeeds and
gpg --verifypasses, because the fetched binary is perfectly valid — it's just for the wrong architecture:The image only breaks when started, with an error that doesn't point at the cause:
and the container exits 255.
Confirmed on an arm64 host
So the image architecture and its payload architecture disagree.
Fix
Pin the base image to
linux/amd64so the image matches the only architecture the binaries are published for.Verification
Rebuilt with the pin on the same arm64 host:
The node starts and proceeds normally, where before it exited immediately.
Scope
pruner/Dockerfileis deliberately left unpinned — it only runscron,bash, and coreutils, so it is genuinely architecture independent and should keep building natively on arm64 rather than paying for emulation.🤖 Generated with Claude Code