Modul WireGuard tidak termuat setelah pembaruan kernel? Periksa ini

Terowongan Anda bekerja kemarin, mesin melakukan reboot setelah pembaruan, dan sekarang antarmuka tidak naik. Pada sistem tempat WireGuard dibangun sebagai modul eksternal, penyebab umumnya adalah modul di disk milik rilis kernel yang berbeda dari yang sedang berjalan sekarang. Header dengan nama serupa pada mesin yang sama tidak membuktikan apa pun tentang kecocokan itu. Hanya string rilis yang menentukan itu.

Kernel yang berjalan atau yang terpasang

Pembaruan memasang paket kernel baru dan membiarkan yang lama di disk sampai mesin dinyalakan ulang. Setelah reboot rilis yang berjalan berubah, dan modul apa pun yang dibangun terhadap rilis sebelumnya menjadi tidak dapat dipakai meskipun berkasnya masih ada. Selisih itu menjelaskan laporan yang lazim tentang mesin yang baik sebelum reboot dan rusak sesudahnya, tanpa perubahan konfigurasi di antaranya. Ini juga menjelaskan mengapa memasang ulang header kadang tampak memperbaiki masalah dan kadang tidak.

Paket header yang Anda pasang mungkin cocok dengan paket kernel terbaru, bukan dengan kernel yang benar-benar boot, dan tidak ada apa pun dalam nama paket yang membedakan kasus itu; hanya string rilis yang melakukannya. Periksa apa yang berjalan sebelum memeriksa apa yang terpasang.

Tiga pemeriksaan sebelum membangun ulang

Pemeriksaan pertama adalah kernel mana yang berjalan. Yang kedua adalah apakah modul untuk rilis itu ada dan dapat ditemukan. Yang ketiga adalah apakah kernel sudah memuatnya. Pertanyaan keempat, apakah antarmuka dapat dibuat, menguji hak istimewa bukan modulnya, jadi tempatnya setelah pembangunan ulang, bukan dalam daftar ini.

Perintah di bawah menjawab tiga yang pertama tanpa mengubah apa pun. Baca setiap hasil sebelum melanjutkan, karena setiap jawaban menyingkirkan perbaikan yang berbeda.

uname -r
ls -l /lib/modules/$(uname -r)/build
modinfo wireguard
lsmod | grep wireguard

Jika baris kedua melaporkan bahwa jalur itu tidak ada, lingkungan build untuk kernel yang berjalan hilang dan apa pun yang Anda kompilasi tidak akan cocok dengannya. Jika modinfo gagal sementara jalurnya ada, modulnya mungkin sama sekali belum terpasang, yang normal pada kernel yang menyertakan implementasinya di dalam pohon. Jika modinfo berhasil dan lsmod tidak menampilkan apa pun, modulnya ada tetapi belum dimuat, yang merupakan masalah waktu pemuatan dan bukan masalah build. Setiap hasil mengirim Anda ke tempat berbeda, karena itu membaca lebih penting daripada perintahnya.

Bangun terhadap rilis yang berjalan

Modul eksternal dikompilasi terhadap pohon kernel yang sudah disiapkan, dan panduan modul eksternal kernel menjelaskan penggunaan direktori build milik kernel yang berjalan, bukan direktori mana pun yang membawa nomor versi tertinggi. Direktori build itu adalah tautan simbolik yang dipelihara paket kernel, jadi ia menunjuk ke pohon untuk rilis yang sedang boot. Ketidaklangsungan itulah intinya: ia menghapus pilihan yang kalau tidak akan Anda ambil dengan salah. Menyebutnya secara eksplisit membuat sasarannya tidak ambigu.

Satu detail penting ketika pohon hanya disiapkan dan belum dibangun sepenuhnya. Target penyiapan tidak menghasilkan berkas versi simbol yang dibutuhkan sebagian build eksternal, jadi pohon yang penuh header tidak otomatis merupakan lingkungan build yang lengkap. Jika build gagal karena simbol yang hilang, berkas itu adalah tempat pertama yang harus dilihat.

sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install
sudo depmod -a

Ketika header terpaket tertinggal

Pada distribusi dan komputer papan tunggal yang mengemas kernel sendiri, header bisa tertinggal berhari-hari atau berminggu-minggu dari rilis. Paket header bisa benar namanya tetapi lebih tua isinya, yang menghasilkan build yang terkompilasi lalu gagal saat dimuat, bukan saat kompilasi. Mencampur sumber memperburuknya: kernel distribusi dengan header dari repositori pihak ketiga, atau kernel vendor dengan header generik, bisa terkompilasi bersih dan tetap ditolak kernel yang berjalan karena konfigurasinya berbeda. Nomor versi saja tidak menyelesaikan itu.

Jika mesin mengikuti kanal kernel eksperimental, putuskan dengan sadar apakah akan bertahan di sana dengan artefak build yang cocok atau kembali ke kumpulan paket yang didukung. Mengulangi pembaruan dan berharap bagian-bagiannya sejajar bukan rencana, karena ketidakcocokan yang sama terulang setiap kali.

Verifikasi antarmuka setelah pembangunan ulang

Setelah pemasangan berhasil, membuat antarmuka adalah uji yang penting, diikuti membaca apa yang sebenarnya dimuat kernel dan apa kata log jika ia menolak. Modul yang termuat dan antarmuka yang tidak dapat dibuat adalah kegagalan berbeda dengan penyebab berbeda. Tiga perintah di bawah memisahkannya.

sudo ip link add wg9 type wireguard
lsmod | grep wireguard
sudo dmesg | tail -5

Jika modul menolak dimuat, log kernel menyebutkan alasannya, dan ketidakcocokan versi hanyalah salah satu kemungkinan. Baca baris itu sebelum membangun ulang, karena build identik kedua menghabiskan sepuluh menit yang sama dan menghasilkan penolakan yang sama. Setelah itu hapus antarmuka sementara agar uji berikutnya dimulai dari kondisi bersih.