32ビットARM QNAP（TS-431P3、TS-231P3、TS-x31X、TS-431KX、TS-1635 など）をお持ちで、Container Station 内のほとんどのDockerイメージが即座に終了（exit code 139、ログが全く空）してしまう場合——その詳しい理由と実際に動く対策を解説します。
原因（2つの独立した理由）：
- これらのCPU（Annapurna AL314, Cortex-A15）は32ビットARMv7です。arm64やamd64向けのイメージは動作せず、
linux/arm/v7用に作成されたイメージのみが候補になります。 - QNAPはこれらのモデルのカーネルを32KBメモリページサイズ（標準は4KB）でビルドしています（QNAP公式ナレッジベース「Container Stationでよくあるコンテナ問題のデバッグ方法・修正方法」に記載あり）。4KBページ向けにアライメントされたバイナリはロード時にセグフォールトします。これによりAlpine 3.18以降、Debian bookworm、Ubuntu 24.04のユーザーランドが壊れ、Pi-hole v6、Home Assistant、Nextcloudなど多くの最新イメージが動かなくなります。現在のQTS 5.2.xでもこのカーネル（4.2.8）が搭載されています。
動作確認済みのベース： Ubuntu 22.04、Debian bullseye、Alpine 3.17以前、静的Goバイナリ。
対策： たいていの場合、アプリのコアバイナリは静的リンクされページサイズにも依存しませんが、Alpineのユーザーランドだけがクラッシュします。公式バイナリを ubuntu:22.04 ベースにそのまま再パッケージすれば正常に動作します。Pi-hole v6 と Syncthing の動作するarm/v7イメージ（アップストリーム自動週次リビルド）、Dockerfile、Container Station向けcompose例、v5→v6 Pi-hole移行ガイド、自分で他のイメージを修正する手順を用意しました：
すべてTS-431P3 + QTS 5.2.9の実機で検証済み、MITライセンス。（Home Assistant専用は、同じアプローチのalbertogeniola/homeassistant-qnap-32kをご覧ください。）