Expected Behavior
balena build --deviceType raspberrypi3 --arch armv7hf should produce an image containing ARM binaries when the FROM is a multi-arch official Docker image (e.g. alpine:3.23).
Actual Behavior
The build completes successfully, but the resulting image contains x86_64 binaries. The amd64 manifest of the base image is selected regardless of --arch.
Steps to Reproduce
Dockerfile:
ARG ALPINE_VERSION=3.23
FROM alpine:${ALPINE_VERSION}
RUN echo "uname -m: $(uname -m)" && \
apk add --no-cache file >/dev/null && \
file /bin/busybox
Build command:
balena build --deviceType raspberrypi3 --arch armv7hf --noparent-check
Build log (relevant lines):
[Info] Building for armv7hf/raspberrypi3
[Info] Docker Desktop detected (daemon architecture: "x86_64")
[Build] main Step 2/X : FROM alpine:${ALPINE_VERSION}
[Build] main ---> 5b10f432ef3d
[Build] main uname -m: x86_64
[Build] main /bin/busybox: ELF 64-bit LSB pie executable, x86-64, ...
Image ID 5b10f432ef3d is the amd64 variant of alpine:3.23.
Verification that the host environment is correct
Direct Docker test on the same machine, same daemon, returns the correct architecture:
$ docker run --rm --platform=linux/arm/v7 alpine:3.23 uname -m
armv7l
This rules out binfmt, QEMU (trying with --emulated parameter), and Docker Desktop's emulation setup as the cause.
Specifications
-
balena CLI version: 24.1.1 (also tried v24.1.4, v25.0.0, and v25.1.3)
-
Docker Client Version:
Version: 29.4.2
API version: 1.54
Go version: go1.26.2
Git commit: 055a478
Built: Fri May 1 01:27:10 2026
OS/Arch: windows/amd64
Context: desktop-linux
-
Docker Server Version:
Server: Docker Desktop 4.72.0 (225998)
Engine:
Version: 29.4.2
API version: 1.54 (minimum version 1.40)
Go version: go1.26.2
Git commit: d329809
Built: Fri May 1 01:24:36 2026
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.3
GitCommit: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
runc:
Version: 1.3.5
GitCommit: v1.3.5-0-g488fc13e
docker-init:
Version: 0.19.0
GitCommit: de40ad0
-
OS: Windows 11 + WSL2
-
Install method: standalone installer
-
Reproducible after: full Docker Desktop factory reset
Related
Workarounds confirmed
- Pinning the FROM line to an arm/v7 digest (
FROM alpine@sha256:...) produces a correct ARM build.
balena push <fleet> on cloud builders is unaffected.
Expected Behavior
balena build --deviceType raspberrypi3 --arch armv7hfshould produce an image containing ARM binaries when theFROMis a multi-arch official Docker image (e.g.alpine:3.23).Actual Behavior
The build completes successfully, but the resulting image contains x86_64 binaries. The amd64 manifest of the base image is selected regardless of
--arch.Steps to Reproduce
Dockerfile:
Build command:
Build log (relevant lines):
Image ID
5b10f432ef3dis the amd64 variant ofalpine:3.23.Verification that the host environment is correct
Direct Docker test on the same machine, same daemon, returns the correct architecture:
This rules out binfmt, QEMU (trying with --emulated parameter), and Docker Desktop's emulation setup as the cause.
Specifications
balena CLI version: 24.1.1 (also tried v24.1.4, v25.0.0, and v25.1.3)
Docker Client Version:
Version: 29.4.2
API version: 1.54
Go version: go1.26.2
Git commit: 055a478
Built: Fri May 1 01:27:10 2026
OS/Arch: windows/amd64
Context: desktop-linux
Docker Server Version:
Server: Docker Desktop 4.72.0 (225998)
Engine:
Version: 29.4.2
API version: 1.54 (minimum version 1.40)
Go version: go1.26.2
Git commit: d329809
Built: Fri May 1 01:24:36 2026
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.3
GitCommit: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
runc:
Version: 1.3.5
GitCommit: v1.3.5-0-g488fc13e
docker-init:
Version: 0.19.0
GitCommit: de40ad0
OS: Windows 11 + WSL2
Install method: standalone installer
Reproducible after: full Docker Desktop factory reset
Related
Workarounds confirmed
FROM alpine@sha256:...) produces a correct ARM build.balena push <fleet>on cloud builders is unaffected.