Wenn du ein 32-Bit-ARM-QNAP (TS-431P3, TS-231P3, TS-x31X, TS-431KX, TS-1635 …) besitzt und die meisten Docker-Images im Container Station sofort abstürzen – Exit-Code 139, komplett leere Logs – findest du hier die vollständige Erklärung und eine funktionierende Lösung.
Woran es liegt (zwei voneinander unabhängige Ursachen):
- Diese CPUs (Annapurna AL314, Cortex-A15) sind 32-Bit-ARMv7. Images, die für arm64 oder amd64 gebaut wurden, können niemals laufen – nur
linux/arm/v7-Images kommen infrage. - QNAP baut den Kernel für diese Modelle mit einer 32 KB großen Speicherseite statt dem Standardwert von 4 KB (wie in QNAPs eigenem KB beschrieben: „How to debug and fix common container issues in Container Station“). Jede Binärdatei, die auf 4-KB-Seiten ausgerichtet ist, erhält beim Laden einen Segfault. Das zerschießt das Userland von Alpine ≥ 3.18, Debian bookworm und Ubuntu 24.04 – also fast alle modernen Images, inklusive Pi-hole v6, Home Assistant und Nextcloud. Auch in der aktuellen QTS 5.2.x kommt dieser Kernel (4.2.8) noch zum Einsatz.
Verifizierte funktionierende Basen: Ubuntu 22.04, Debian bullseye, Alpine ≤ 3.17, statisch gelinkte Go-Binaries.
Die Lösung: In den meisten Fällen ist die zentrale Binary der Anwendung statisch gelinkt und seiten-unabhängig – nur das Alpine-Userland stürzt ab. Verpackt man die unveränderten offiziellen Binaries neu auf Basis von ubuntu:22.04, läuft alles wie es soll. Ich habe fertig gebaute arm/v7-Images für Pi-hole v6 und Syncthing veröffentlicht (werden wöchentlich automatisch gegen upstream neu gebaut), dazu die Dockerfiles, ein Container-Station-compose-Beispiel, einen Leitfaden zur Migration von Pi-hole v5 → v6 und eine Schritt-für-Schritt-Anleitung, wie man andere Images selbst anpasst:
Alles live getestet auf einem TS-431P3 unter QTS 5.2.9. MIT-lizenziert. (Für Home Assistant siehe speziell albertogeniola/homeassistant-qnap-32k, das denselben Ansatz verwendet.)