Kenapa uname -r Masih Menampilkan Kernel Lama Setelah Patch Keamanan

Paket kernel sudah di-update dan apt atau dnf bilang semuanya beres, tapi scanner keamanan masih menandai server rentan. Begitu dicek, uname -r memang masih menampilkan versi lama. Ini bukan salah scanner. uname -r melaporkan kernel yang sedang berjalan di memori, bukan paket yang tersimpan di disk. Selama keduanya berbeda, server memang masih menjalankan kode kernel lama. Pertanyaan ini sering muncul setelah update rutin di VPS: "Sudah update, kok masih dibilang rentan?" Penyebabnya biasanya satu dari empat hal: server belum reboot, GRUB memilih entry lain, partisi /boot penuh sehingga kernel baru tidak terpasang sempurna, atau ada live patch yang dikira aktif padahal belum. Kita telusuri berurutan, mulai dari yang paling gampang dicek.

Bedakan kernel yang terpasang dengan kernel yang berjalan

Saat kamu meng-update paket kernel, package manager hanya menaruh file baru di /boot, yaitu image kernel (vmlinuz-...) dan initramfs (initrd.img-... atau initramfs-...img). Initramfs adalah filesystem kecil yang dimuat lebih dulu untuk menyiapkan driver sebelum root filesystem di-mount. Kernel yang sudah jalan tidak tersentuh. Kernel baru baru dipakai setelah boot berikutnya. Jadi langkah pertama adalah membandingkan tiga hal: versi yang berjalan, versi yang terpasang, dan kapan server terakhir boot.

BASH

# Kernel yang sedang berjalan
uname -r

# Kernel yang terpasang (Debian/Ubuntu)
dpkg -l 'linux-image*' | grep '^ii'

# Kernel yang terpasang (RHEL, AlmaLinux, Rocky)
rpm -q kernel

# Waktu boot terakhir
uptime -s

# File kernel dan initramfs yang ada di /boot
ls -lh /boot

Kalau versi terbaru di daftar paket lebih baru dari uname -r, dan waktu boot lebih awal dari tanggal file kernel baru di /boot, jawabannya sederhana: server belum reboot. Di Ubuntu dan Debian, biasanya ada file penanda /var/run/reboot-required setelah update kernel. Di keluarga RHEL, needs-restarting -r dari paket dnf-utils atau yum-utils bisa memberi tahu apakah reboot diperlukan. Ada satu pengecualian yang perlu disingkirkan dulu. Kalau VPS kamu berbasis container seperti OpenVZ atau LXC, kernel itu milik host, bukan milik VPS-mu. Cek dengan systemd-detect-virt. Kalau hasilnya lxc atau openvz, meng-update paket kernel di dalam VPS tidak berpengaruh apa pun, dan reboot pun tidak mengganti kernel. Yang bisa menambal hanya pengelola host. Pola yang sama berlaku untuk Docker, seperti dibahas di Mengira Celah Kernel Linux Tidak Berdampak ke Aplikasi di Docker.

Sudah reboot, tapi GRUB masih memilih kernel lama

Kalau uptime -s menunjukkan server baru saja boot dan uname -r tetap lama, masalahnya ada di bootloader. GRUB memilih entry berdasarkan pengaturan default. Beberapa hal yang sering membuatnya meleset:

GRUB_DEFAULT di /etc/default/grub diisi angka indeks atau nama entry tertentu, sehingga terkunci ke kernel lama.
GRUB_DEFAULT=saved dipakai, dan saved_entry di file grubenv masih menunjuk ke versi sebelumnya.
grub.cfg tidak di-generate ulang karena proses post-install paket kernel gagal.
Config di-generate ke lokasi yang tidak dibaca saat boot, misalnya path BIOS padahal server boot lewat UEFI.

Cek pengaturan default tanpa mengubah apa pun:

BASH

# Debian/Ubuntu
grep '^GRUB_DEFAULT' /etc/default/grub
grub-editenv list

# RHEL, AlmaLinux, Rocky
grubby --default-kernel
grubby --info=ALL | grep -E '^(index|kernel)'

Di keluarga RHEL, grubby --default-kernel langsung menunjukkan kernel yang akan dipakai saat boot. Kalau masih kernel lama, grubby --set-default dengan path vmlinuz versi baru akan mengubahnya. Di Debian/Ubuntu, sesuaikan GRUB_DEFAULT lalu jalankan update-grub. Perintah dan lokasi grub.cfg untuk regenerate config berbeda per distro dan mode boot, jadi cocokkan dengan dokumentasi distro kamu. Kemungkinan lain: kernel baru sebenarnya terpilih tapi gagal boot, lalu seseorang memilih entry lama lewat console, atau GRUB jatuh ke fallback. Log boot sebelumnya bisa membantu kalau journal disimpan permanen (journalctl --list-boots). Sebelum mengubah default boot, pastikan kamu punya akses console dari panel VPS. Kalau kernel baru panic dan tidak ada console, server tidak bisa diakses sampai ada yang memilih kernel lama secara manual. Satu catatan lagi untuk VPS. Di beberapa platform virtualisasi, kernel bisa dimuat dari sisi hypervisor atau dipilih lewat panel, bukan dari GRUB di dalam disk. Kalau semua pengecekan di atas terlihat benar tapi kernel tetap tidak berubah, cek dokumentasi penyedia VPS-mu soal pengaturan kernel.

Partisi /boot penuh bikin kernel baru setengah terpasang

Ini penyebab yang paling sering terlewat, karena update terlihat jalan padahal ada error di tengah output yang panjang. Banyak instalasi lama punya partisi /boot terpisah yang kecil. Setiap update kernel menambah satu set file baru. Kalau kernel lama tidak pernah dibersihkan, suatu saat ruangnya habis. Akibatnya, image kernel mungkin sudah tersalin tapi initramfs gagal dibuat, atau grub.cfg tidak diperbarui. Paketnya tercatat terpasang, tapi kernelnya tidak bisa atau tidak akan dipakai untuk boot.

BASH

# Sisa ruang di /boot
df -h /boot

# Debian/Ubuntu: cek paket yang setengah terpasang
dpkg --audit

# Pastikan setiap vmlinuz punya pasangan initrd/initramfs
ls /boot | grep -E 'vmlinuz|initrd|initramfs'

Kalau df menunjukkan /boot hampir penuh, atau ada versi vmlinuz tanpa initramfs pasangannya, berarti update tadi belum selesai. Cara membereskannya:

Catat output uname -r. Kernel ini jangan sampai dihapus.
Bersihkan kernel lama lewat package manager, jangan dengan menghapus file di /boot secara manual. Di Debian/Ubuntu, apt autoremove --purge biasanya menghapus kernel lama yang tidak dipakai. Baca daftar paket yang akan dihapus sebelum menjawab y. Di keluarga RHEL, jumlah kernel yang disimpan diatur lewat installonly_limit di konfigurasi dnf, dan dnf remove --oldinstallonly bisa membuang yang berlebih.
Selesaikan instalasi yang tertunda. Di Debian/Ubuntu pakai dpkg --configure -a.
Kalau initramfs versi baru masih belum ada, buat ulang dengan update-initramfs -u -k <versi> (Debian/Ubuntu) atau dracut -f --kver <versi> (keluarga RHEL).
Cek lagi default GRUB seperti di bagian sebelumnya, baru reboot.

Menghapus paket kernel tidak bisa di-undo dengan mudah. Kalau kernel yang sedang berjalan dan kernel baru sama-sama rusak atau hilang, server tidak akan bisa boot. Jangan lewatkan langkah pertama.

Live patch: versinya lama, tapi apakah sudah ditambal?

Kernel live patching menambal fungsi kernel yang sedang berjalan langsung di memori, tanpa reboot. Contohnya kpatch di keluarga RHEL, Livepatch dari Canonical di Ubuntu, atau layanan pihak ketiga. Karena kernelnya tidak diganti, uname -r memang tidak berubah. Itu perilaku normal. Dari sini ada dua kemungkinan yang arahnya berlawanan. Pertama, live patch sudah aktif, tapi scanner hanya membandingkan string uname -r dengan daftar versi rentan. Hasilnya false positive. Untuk membuktikannya, cek status patch di server. Kernel dengan framework livepatch menampilkan patch yang dimuat di /sys/kernel/livepatch/, dan tiap patch punya file enabled. Tool seperti kpatch list atau canonical-livepatch status menampilkan patch apa saja yang aktif. Cocokkan dengan CVE yang dilaporkan scanner. Cara scanner membaca status live patch berbeda per produk, jadi cek dokumentasinya. Kedua, agen live patch terpasang tapi patch untuk celah ini belum diterapkan. Bisa jadi layanannya mati, langganannya tidak aktif, atau patch untuk celah tersebut memang tidak tersedia. Kalau /sys/kernel/livepatch/ kosong atau tool-nya tidak menyebut CVE yang dimaksud, anggap server masih rentan. Perlu diingat juga, live patch biasanya ditujukan untuk menunda reboot, bukan menghapus kebutuhan reboot sama sekali. Tidak semua perubahan kernel bisa diterapkan lewat live patch. Pada akhirnya kamu tetap perlu menjadwalkan reboot ke kernel baru.

Urutan cek yang paling cepat

Kalau ada laporan "sudah update tapi masih rentan", urutan ini biasanya paling cepat:

Jalankan systemd-detect-virt. Kalau hasilnya container, urusannya ada di host.
Bandingkan uname -r, daftar paket kernel, dan uptime -s. Kalau server belum boot sejak update, jadwalkan reboot.
Kalau sudah reboot, cek df -h /boot dan pastikan file kernel serta initramfs versi baru lengkap.
Cek default boot dengan grubby --default-kernel atau grub-editenv list plus GRUB_DEFAULT.
Kalau memakai live patch, verifikasi status patch di server, jangan hanya melihat angka versi.

Pegangan praktisnya: angka di uname -r adalah fakta tentang apa yang sedang berjalan, sedangkan daftar paket hanya menunjukkan apa yang siap dipakai nanti. Setelah setiap patch kernel, cek ulang uname -r dan status live patch sebelum menutup tiket. Biasakan juga memantau sisa ruang /boot dan memastikan akses console tersedia sebelum reboot, supaya patch berikutnya tidak tertahan oleh masalah yang sama.