From deee75925b1177ddee1c1ab24322c4969588c55c Mon Sep 17 00:00:00 2001 From: paplo75 Date: Thu, 13 Aug 2026 20:08:06 +0200 Subject: [PATCH] Pin node image to linux/amd64 `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 --- Dockerfile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index a47602c..5515a8f 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,4 +1,7 @@ -FROM ubuntu:24.04 +# hl-visor and hl-node are published as x86-64 binaries only, so the image must +# be amd64 regardless of the host. Without this, building on an arm64 host (e.g. +# Apple Silicon) silently produces an arm64 image that cannot exec hl-visor. +FROM --platform=linux/amd64 ubuntu:24.04 ARG USERNAME=hluser ARG USER_UID=10000