Docker: audit armv7 image availability and the 3 GiB per-process ceiling #67

New issue

Open

opened 2026-08-30 11:38:48 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-08-30 11:38:48 +00:00

Owner

Split out of the Docker enablement work. The kernel and the daemon can be made to
work; that does not mean an arbitrary workload will run.

Two independent ceilings

1. `linux/arm/v7` images are thinning out

Measured against the Docker Hub registry API, :latest manifests:

image	ships `arm/v7`?
`alpine`	yes
`debian`	yes
`nginx`	yes
`postgres`	yes
`redis`	yes
`traefik`	no - amd64 / arm64 / ppc64le / riscv64 / s390x only
`influxdb`	no - amd64 / arm64 only
`mariadb`	no - amd64 / arm64 / ppc64le / s390x only

The base images are fine. It is the application images that increasingly drop 32-bit
ARM. Check per workload before anything is promised, rather than discovering it at
docker run.

2. Per-process address space is ~3 GiB, not 4

CONFIG_PAGE_OFFSET=0xC0000000 - a 3G/1G split. The board has 4 GiB reachable (#61,
57-4gb-reclaimed.md) but no single process can map more than about 3 GiB,
container or not. Anything with a large single-process heap - a JVM, a big in-memory
cache - hits this regardless of how much RAM is free.

Add 4 usable cores at a fixed clock (#53 keeps the A15 cluster down; there is no
cpufreq).

Action

List the intended workloads and check each for an arm/v7 manifest and a plausible
memory profile. For the ones that fail:

build locally - docker-buildx-plugin is in the armhf repo
pin an older tag that still has arm/v7, and accept the security tail
substitute (mariadb -> postgres, which does still ship arm/v7)
or accept it will not run here

Done when

There is a written list of what this board is expected to host, with the architecture
answer recorded next to each entry.

Split out of the Docker enablement work. The kernel and the daemon can be made to work; that does not mean an arbitrary workload will run. ## Two independent ceilings ### 1. `linux/arm/v7` images are thinning out Measured against the Docker Hub registry API, `:latest` manifests: | image | ships `arm/v7`? | |---|---| | `alpine` | yes | | `debian` | yes | | `nginx` | yes | | `postgres` | yes | | `redis` | yes | | `traefik` | **no** - amd64 / arm64 / ppc64le / riscv64 / s390x only | | `influxdb` | **no** - amd64 / arm64 only | | `mariadb` | **no** - amd64 / arm64 / ppc64le / s390x only | The base images are fine. It is the *application* images that increasingly drop 32-bit ARM. Check per workload before anything is promised, rather than discovering it at `docker run`. ### 2. Per-process address space is ~3 GiB, not 4 `CONFIG_PAGE_OFFSET=0xC0000000` - a 3G/1G split. The board has 4 GiB reachable (#61, `57-4gb-reclaimed.md`) but **no single process can map more than about 3 GiB**, container or not. Anything with a large single-process heap - a JVM, a big in-memory cache - hits this regardless of how much RAM is free. Add 4 usable cores at a fixed clock (#53 keeps the A15 cluster down; there is no cpufreq). ## Action List the intended workloads and check each for an `arm/v7` manifest and a plausible memory profile. For the ones that fail: - build locally - `docker-buildx-plugin` is in the armhf repo - pin an older tag that still has `arm/v7`, and accept the security tail - substitute (`mariadb` -> `postgres`, which does still ship `arm/v7`) - or accept it will not run here ## Done when There is a written list of what this board is expected to host, with the architecture answer recorded next to each entry.

tiagoagueda added the

P3-normal

label

2026-08-30 11:38:48 +00:00