Troubleshooting Packages

Tidak ada sistem yang selamanya bebas error: koneksi terputus di tengah unduhan, daya padam saat dpkg sedang membongkar file, kunci penanda tangan repository kedaluwarsa, disk habis tepat ketika arsip dibuka. Kabar baiknya, pesan error apt dan dpkg termasuk yang paling informatif di dunia Linux — pesan tersebut menyebut file yang bermasalah, alasannya, dan sering kali solusinya. Chapter ini merangkai kebiasaan membaca pesan menjadi pola kerja: diagnosis dulu dengan perintah aman, lalu perbaikan dengan alat yang tepat. Karena perintah perbaikan hampir seluruhnya butuh root, kita jalankan diagnosisnya secara nyata dan tampilkan perbaikannya sebagai panduan.

Tiga Pemeriksaan Awal yang Aman #

Sebelum menyentuh perbaikan apa pun, tiga perintah baca-saja memberi gambaran menyeluruh. Yang pertama mengaudit database dpkg:

dpkg --audit
echo "exit code: $?"

Output yang Dihasilkan:

exit code: 0

Cara membacanya:

1. Baris 1 (dpkg --audit): mendaftar package dalam kondisi terganggu — terpasang setengah (half-installed), terkonfigurasi setengah (half-configured), atau menunggu trigger — tanpa mengubah apa pun.
2. Baris 2 (echo ...): memastikan perintah sebelumnya sukses. Output kosong ditambah exit code 0 berarti tidak ada package yang terganggu; inilah wajah sistem sehat yang kita jadikan pembanding.

Pemeriksaan kedua menyapu seluruh database lewat kode statusnya:

dpkg -l | awk 'NR>5 && $1 != "ii" {print $1}'
echo "output kosong: tidak ada package berstatus selain ii"

Output yang Dihasilkan:

output kosong: tidak ada package berstatus selain ii

dpkg -l mencetak lima baris legenda lebih dulu, karena itu awk hanya memroses baris NR>5. Kolom pertama adalah kode status dua huruf yang kita kenal dari Chapter apt dan dpkg : ii sehat, rc sisa file konfigurasi, iU dan iF kondisi setengah jalan. Sapuan di atas hanya mencetak baris yang tidak ii, sehingga hasilnya wajib kosong pada sistem sehat. Pemeriksaan ketiga datang dari pihak apt — simulasi perbaikan dependensi:

apt-get -s -f install 2>/dev/null | tail -1

Output yang Dihasilkan:

0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.

Opsi -f (fix-broken) meminta resolver memperbaiki dependensi yang rusak, dan -s membuatnya sekadar simulasi — versi sungguhannya adalah sudo apt --fix-broken install. Angka nol di depan berarti resolver tidak menemukan pekerjaan; angka di ujung menghitung package yang tertinggal pembaruan, bukan kerusakan. Bila ketiganya bersih tetapi masalah tetap ada, giliran skenario berikut yang diperiksa.

Lock Sibuk: apt Sedang Dipakai Proses Lain #

Dua pesan lock terlihat mirip tetapi beda makna. Pesan Could not open lock file ... Permission denied berarti kita lupa sudo — sudah kita bedah di Chapter Installing dan Removing Packages . Adapun Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 3821 (apt) berarti proses lain sedang memegang kunci — biasanya unattended-upgrades yang bekerja di latar belakang, atau sesi apt yang kita lupakan di terminal lain. File lock memang menjaga agar dua transaksi tidak menulis database bersamaan; keberadaannya bukan error, melainkan pengaman yang sedang bekerja. Periksa pemegangnya dengan ps aux | grep apt (atau fuser dan lsof bila tersedia), lalu tunggu proses tersebut selesai.

dpkg Interrupted: Transaksi Terputus di Tengah #

Skenario klasiknya: listrik padam, atau terminal ditutup paksa, tepat ketika dpkg sedang membongkar dan mengonfigurasi package. Sesi apt berikutnya menolak berjalan dan langsung menyebut obatnya — sebagai contoh tampilan:

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

Perbaikannya satu baris: sudo dpkg --configure -a, yang menuntaskan seluruh script konfigurasi tertunda tanpa memasang ulang file yang sudah masuk. Pada sistem sehat, perintah yang sama tidak menghasilkan output apa pun. Bila setelahnya masih ada dependensi yang tidak konsisten — misalnya package menuntut pustaka yang belum terpasang — giliran sudo apt --fix-broken install yang melengkapinya, persis simulasi -s -f di atas tetapi sungguhan. Jejak setengah jalan terlihat di field Status: nilai seperti install ok half-configured akan muncul pada pemeriksaan dpkg -s, lalu kembali menjadi install ok installed setelah perbaikan selesai.

Kunci GPG: NO_PUBKEY dan EXPKEYSIG #

Sebelum memakai indeks repository, apt memverifikasi tanda tangan digitalnya lewat kunci GPG. Dua kode paling sering muncul ketika verifikasi gagal — sebagai contoh tampilan:

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.debian.org/debian trixie InRelease: The following signatures were invalid: EXPKEYSIG 6D33866EDD8FFA41
E: The repository 'http://deb.debian.org/debian trixie InRelease' is not signed.

Kode NO_PUBKEY berarti kunci publik penandatangan belum dikenal sistem — tipikal pada repository yang baru ditambahkan tanpa memasang kuncinya. Kode EXPKEYSIG berarti kunci sudah kedaluwarsa: pemelihara repository merotasi kuncinya, sementara sistem kita masih memegang yang lama. Keduanya disembuhkan dengan cara yang sama di masa kini — pasang kunci publik yang benar sebagai keyring khusus, lalu rujuk lewat signed-by pada definisi repository; langkah demi langkahnya sudah kita praktikkan di Chapter Repository Management . Mekanisme verifikasinya dijelaskan di SecureAPT dan apt-secure(8) .

Repository Mati dan Disk Penuh #

Dua gangguan lain kerap datang tanpa kesalahan kita. Pertama, repository yang hilang: pemilik repository pihak ketiga menutup layanannya, atau rilis Debian yang kita pakai sudah ditarik dari mirror utama — apt update menjawab dengan galat 404 atau does not have a Release file. Solusinya menyesuaikan suite pada konfigurasi sumber (prosedur lompatan rilisnya ada di Chapter Updating dan Upgrading System ) atau menonaktifkan sumber yang sudah mati. Kedua, disk penuh: apt membutuhkan ruang untuk arsip unduhan di /var/cache/apt/archives, ruang pembongkaran, dan ruang database — gejalanya pesan No space left on device di tengah proses. Penanganannya berlapis: periksa posisi dengan df -h /var /, bersihkan arsip dengan sudo apt clean, lepas package yang tidak dibutuhkan dengan sudo apt autoremove --purge, dan pangkas log jurnal dengan sudo journalctl --vacuum-size=200M sebelum mencoba lagi.

Tabel Cepat: Gejala, Diagnosis, Solusi #

Seluruh skenario di atas dirangkum dalam satu tabel rujukan:

Baris terakhir adalah pesan gcc, bukan apt — tetapi pola membacanya sama, dan asal-usulnya kita bahas di Chapter Compiling from Source . Satu prinsip merangkum seluruh tabel: pesan error bukan gangguan yang harus dihilangkan cepat-cepat, melainkan data diagnostik paling kaya yang diberikan sistem secara cuma-cuma. Package manager mengelola software sebagai file di disk; yang membuat software benar-benar bekerja adalah proses di memori. Pergeseran pandangan dari file ke proses itulah pintu masuk Section berikutnya — dimulai dari Chapter Process Concepts .