Jika Anda memiliki QNAP ARM 32-bit (TS-431P3, TS-231P3, TS-x31X, TS-431KX, TS-1635…) dan sebagian besar image Docker di Container Station langsung mati—exit code 139, log benar-benar kosong—berikut penjelasan lengkap dan solusinya yang sudah terbukti.
Mengapa ini terjadi (dua penyebab terpisah):
- CPU ini (Annapurna AL314, Cortex-A15) adalah ARMv7 32-bit. Image yang dibangun untuk arm64 atau amd64 tidak akan pernah bisa dijalankan; hanya image
linux/arm/v7yang bisa dipakai. - QNAP membangun kernel untuk model-model tersebut dengan ukuran halaman memori 32 KB alih-alih standar 4 KB (terdokumentasi di KB resmi QNAP: “How to debug and fix common container issues in Container Station”). Setiap binary yang diatur untuk halaman 4 K akan segfault saat dijalankan. Ini merusak userland Alpine >= 3.18, Debian bookworm, dan Ubuntu 24.04—yang mencakup hampir semua image modern, termasuk Pi-hole v6, Home Assistant, dan Nextcloud. QTS 5.2.x saat ini masih menggunakan kernel ini (4.2.8).
Base yang sudah teruji bekerja: Ubuntu 22.04, Debian bullseye, Alpine <= 3.17, static Go binary.
Solusinya: dalam banyak kasus, binary inti aplikasi bersifat statis dan aman terhadap ukuran halaman—hanya userland Alpinelah yang crash. Bungkus ulang binary resmi (tanpa modifikasi) ke dalam ubuntu:22.04 dan akan berjalan normal. Saya telah mempublikasikan image arm/v7 siap pakai untuk Pi-hole v6 dan Syncthing (dibangun otomatis mingguan mengikuti upstream), file Dockerfile-nya, contoh compose Container Station, panduan migrasi Pi-hole v5 → v6, dan langkah demi langkah cara memperbaiki image lain sendiri:
Semuanya telah diverifikasi langsung di TS-431P3 dengan QTS 5.2.9. Berlisensi MIT. (Untuk Home Assistant khususnya, lihat albertogeniola/homeassistant-qnap-32k, yang menerapkan ide yang sama.)