VPS Tidak Bisa Boot Setelah Update Kernel: Cara Pulih

Langkah pertama saat VPS tidak dapat boot setelah pembaruan kernel

VPS yang tidak dapat boot setelah pembaruan kernel biasanya dapat dipulihkan dalam beberapa menit karena pembaruan tersebut tidak menghapus kernel yang masih berfungsi sehari sebelumnya. Ubuntu memasang kernel baru berdampingan dengan kernel lama dan hanya mengubah entri yang dijalankan GRUB secara default. Jadi, tindakan pertama bukan memperbaikinya. Pilih kernel sebelumnya pada menu boot, dapatkan kembali prompt login, lalu lakukan diagnosis dari sistem yang sedang berjalan.

Penanganan masalah ini pada server berbeda dari penanganannya pada laptop karena tidak ada keyboard yang terpasang dan tidak ada monitor yang menampilkan panic. SSH juga tidak akan merespons karena mesin belum mencapai tahap saat sshd dijalankan. Semua langkah di bawah ini dilakukan melalui console dari provider Anda.

Baca console Anda sendiri sebelum mengubah apa pun. Teks pada layar tersebut menentukan kategori kegagalan yang terjadi, dan dua server yang sama-sama “tidak dapat boot” dapat memerlukan perbaikan yang berlawanan.

Bagaimana cara mengakses console saat SSH tidak dapat digunakan?

Buka control panel provider Anda dan cari console. Nama yang umum digunakan adalah VNC console, web console, noVNC, dan serial console. Jika keduanya tersedia, pilih serial console karena console ini menampilkan teks nyata yang dapat Anda gulir dan salin, sedangkan tampilan VNC hanya berupa gambar layar. Temukan kontrol ini sekarang, saat mesin masih berfungsi normal, lalu pastikan console dapat dibuka. Mencarinya saat terjadi outage akan menghabiskan ketenangan yang Anda perlukan. Pemeriksaan ini termasuk dalam sepuluh menit pertama pada VPS baru, bersama aturan firewall dan SSH key.

Sebagian besar panel juga menyediakan rescue mode atau recovery image. Fitur ini mem-boot sistem kecil dari jaringan provider dan memasang disk Anda sebagai perangkat tambahan, sehingga tidak ada sistem pada disk tersebut yang dijalankan. Rescue mode menjadi fallback ketika GRUB sendiri rusak. Mode ini juga digunakan untuk menyalin data dari server yang sudah Anda putuskan untuk tidak diselamatkan.

Biasanya Anda perlu melakukan hard reset dari panel untuk membuka boot menu, karena Anda tidak dapat menjalankan sudo reboot pada mesin yang tidak dapat Anda masuki. Hard reset sama dengan memutus daya. Filesystem akan mengalami shutdown yang tidak bersih, jadi perkirakan adanya filesystem check pada boot berikutnya.

Bagaimana cara memilih kernel yang lebih lama di menu GRUB?

Pantau konsol sejak Anda menekan reset. Tekan Esc berulang kali selama beberapa detik pertama, atau tahan Shift pada mesin yang melakukan boot dalam mode BIOS legacy. Waktunya singkat, dan penampil konsol sering memerlukan satu detik untuk tersambung. Karena itu, mulai menekan lebih awal dan terus tekan.

Saat menu muncul, pilih "Advanced options for Ubuntu". Submenu tersebut menampilkan semua kernel yang terpasang, dimulai dari versi terbaru, dengan entri recovery mode untuk setiap kernel. Pilih entri normal kedua, yaitu kernel di bawah versi terbaru, lalu tekan Enter. Recovery mode berbeda: mode ini melakukan boot ke sistem single-user minimal dan digunakan untuk perbaikan, bukan untuk mengaktifkan kembali service Anda.

Jika kernel yang lebih lama berhasil melakukan boot, server Anda kembali berjalan. Pastikan kernel yang digunakan dan catat nomornya.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Output dpkg adalah daftar kernel yang terpasang. Jika daftar tersebut hanya berisi satu baris, Anda sama sekali tidak memiliki fallback. Hal itu adalah masalah pertama yang harus diperbaiki.

Menu GRUB tidak pernah muncul. Apa yang harus dilakukan?

Cloud image biasanya menyertakan konfigurasi yang menyembunyikan menu. Image Ubuntu umumnya menetapkan timeout ke 0 dalam file di bawah /etc/default/grub.d/, sehingga kernel terbaru langsung dijalankan dan tidak ada tombol yang perlu ditekan.

Ada juga kondisi sebaliknya: menu tampil di layar dan menunggu, sehingga terlihat seperti proses boot macet. GRUB mencatat kegagalan boot, lalu pada proses start berikutnya dapat menahan menu tetap terbuka sampai seseorang menekan tombol. Pada server tanpa keyboard, penantian tersebut tidak pernah berakhir. Jika console Anda menampilkan menu dan tidak ada yang berubah, itulah penyebabnya. Pilih salah satu entri, lalu lanjutkan.

Perbaiki kedua kondisi tersebut saat mesin masih berjalan normal. Edit /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Kemudian terapkan perubahan dan periksa apakah edit tersebut tetap ada, karena file di /etc/default/grub.d/ dibaca setelah /etc/default/grub dan dapat menimpa perubahan Anda.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" mengirimkan menu ke console grafis dan port serial, sehingga menu tersebut muncul pada viewer yang disediakan panel Anda. Argumen kernel console= melakukan hal yang sama untuk pesan boot berikutnya. Penundaan sepuluh detik pada setiap boot merupakan kompromi yang wajar agar menu dapat diakses pada pukul 2 pagi.

Kelas kegagalan apa yang sedang terjadi?

Baca dua puluh baris terakhir sebelum konsol berhenti berubah. Empat pola mencakup sebagian besar kondisi setelah pembaruan kernel.

GRUB tidak dapat menemukan berkasnya sendiri. Anda mendapatkan prompt grub rescue>, atau error tentang partisi atau berkas yang tidak ada, dan tidak ada pesan kernel yang muncul. Kernel belum terlibat. Kondisi ini biasanya terjadi setelah perubahan disk atau partisi, atau setelah bootloader ditulis ke perangkat yang salah, bukan karena paket kernel itu sendiri.

Kernel berjalan, tetapi tidak dapat me-mount root. Pesan kernel muncul di layar, lalu Anda masuk ke shell busybox dengan prompt (initramfs), atau proses boot berakhir dengan panic karena root filesystem tidak dapat di-mount. Kernel berhasil dimuat. initramfs, yaitu root sementara berukuran kecil yang mencari dan me-mount root filesystem sebenarnya, tidak menemukan disk tersebut. Di Ubuntu, shell ini biasanya didahului pesan bahwa sistem berhenti menunggu root device, dan pesan itu mencantumkan UUID yang dicari. Salin UUID tersebut, lalu bandingkan dengan output blkid nanti.

Logical volume tidak pernah muncul. Ini adalah kelas sebelumnya dengan satu penyebab khusus. Pada prompt (initramfs), jalankan ls /dev/mapper. Jika satu-satunya entri adalah control, berarti tidak ada volume LVM (logical volume manager) yang diaktifkan, sehingga root device belum ada. Aktifkan volume group secara manual:

lvm vgchange -ay
ls /dev/mapper
exit

exit mengembalikan kontrol ke skrip initramfs, yang kemudian mencoba me-mount kembali filesystem tersebut. Jika sistem kemudian berhasil boot, initramfs baru tidak memuat komponen LVM, dan perbaikannya adalah membangun ulang image tersebut, bukan mengubah kernel.

Tidak ada keluaran Linux sama sekali. Konsol menampilkan teks firmware, shell UEFI (unified extensible firmware interface), layar kosong tanpa output kernel, atau loop reset. Kegagalan terjadi sebelum Linux berjalan. Setelah sistem kembali aktif, periksa mode boot yang sebenarnya digunakan server, karena banyak instance VPS melakukan boot dalam mode BIOS legacy dan tidak pernah menggunakan jalur EFI:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

/boot/efi yang tidak di-mount selama upgrade merupakan penyebab umum pada mesin UEFI, karena paket yang memelihara EFI system partition kemudian menulis ke direktori kosong biasa. Firmware terus menjalankan boot entry lama sampai entry tersebut tidak lagi sesuai dengan isi disk.

Ada satu pola lain yang sebenarnya bukan kegagalan boot. Jika Anda masuk ke root shell yang menyatakan bahwa sistem berada dalam emergency mode, berarti kernel berhasil boot dan userspace berhenti. Biasanya penyebabnya adalah baris yang salah dalam /etc/fstab atau filesystem yang gagal diperiksa. Jalankan journalctl -xb di shell tersebut, lalu baca nama unit yang gagal.

Apakah paket kernel rusak, atau initramfs?

Keduanya terlihat sama dari konsol dan memerlukan perbaikan yang berbeda. Boot kernel lama, lalu bandingkan file-file tersebut.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Untuk setiap versi yang terpasang, harus ada satu vmlinuz- dan satu initrd.img- yang cocok, masing-masing dengan ukuran yang masuk akal. initrd yang hilang, atau ukurannya jauh lebih kecil daripada versi lain, menunjukkan bahwa pembuatan initramfs gagal. Penyebab yang umum adalah /boot penuh. Buktinya terdapat dalam log paket:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log juga mencantumkan paket yang dipasang oleh proses terakhir beserta waktunya secara tepat. Dengan demikian, perubahan yang terjadi dapat dipastikan.

Kosongkan ruang terlebih dahulu jika /boot penuh, lalu buat ulang image untuk versi yang diperlukan dan perbarui menu. Ambil string versi dari output ls Anda sendiri, karena placeholder di bawah bukan rilis yang sebenarnya:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

ls terakhir adalah pemeriksaannya. File dengan ukuran normal berarti image tersebut sudah tersedia. Namun, jika image kernel itu sendiri rusak, atau dpkg -l menunjukkan status paket selain ii, pasang ulang paket tersebut:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Perbaikan dari rescue mode ketika tidak ada kernel yang dapat melakukan boot

Jika semua entri pada menu gagal, boot image rescue dari provider lalu perbaiki disk dari luar. Disk Anda akan muncul sebagai perangkat yang belum di-mount, sehingga tidak ada proses di dalamnya yang sedang berjalan dan tidak ada yang menghalangi perbaikan.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Menguji kernel baru tanpa mempertaruhkan boot berikutnya

GRUB dapat menjalankan satu entri satu kali, lalu kembali ke default yang Anda pilih. Arahkan default ke kernel yang Anda percayai, lalu jalankan kernel baru hanya untuk satu kali boot. Jika gagal, hard reset dari panel akan mengembalikan Anda ke kernel yang berfungsi tanpa perlu mengatur waktu akses konsol.

Atur GRUB_DEFAULT=saved di /etc/default/grub, jalankan sudo update-grub, lalu tampilkan judul entri agar Anda dapat menentukan salah satunya secara persis:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list harus menampilkan judul yang Anda pilih sebagai saved_entry. Output tersebut membuktikan bahwa mekanisme ini berfungsi, karena penyimpanan memerlukan /boot/grub/grubenv yang dapat ditulis, sedangkan pada beberapa tata letak, berkas tersebut diam-diam tidak dapat ditulis. Entri 0 berada di bagian atas menu, yaitu kernel terbaru. Judul lebih aman daripada nomor dalam kasus ini karena nomor berubah setiap kali kernel dipasang atau dihapus.

Mengapa autoremove berisiko pada server tanpa akses langsung

APT menyimpan daftar paket kernel yang tidak boleh dihapus secara otomatis. Baca daftar tersebut:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

File tersebut dibuat ulang setiap kali paket kernel berubah. File ini melindungi kernel yang sedang berjalan dan kernel terbaru lainnya. Masalahnya terletak pada waktu eksekusi. Jalankan sudo apt autoremove --purge tepat setelah reboot ke kernel baru, dan daftar yang dilindungi sudah diperbarui. Akibatnya, kernel lama yang Anda andalkan tidak lagi dilindungi. Pada mesin dengan keyboard, hal ini hanya merepotkan. Pada server tanpa akses langsung, perbedaannya adalah antara memilih entri menu dan me-mount disk dari rescue image.

Pertahankan minimal dua kernel. Pertahankan tiga kernel jika /boot memiliki ruang yang cukup. Hapus kernel lama berdasarkan namanya setelah memeriksa uname -r. Dengan demikian, Anda tidak akan menghapus kernel yang sedang berjalan:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

Jalankan kembali perintah terakhir setelah itu. Jika jumlahnya berkurang dari tiga menjadi dua, itu adalah pembersihan rutin. Jika jumlahnya berkurang menjadi satu, outage hanya menunggu reboot berikutnya.

Ambil snapshot sebelum upgrade

Snapshot yang diambil sebelum apt upgrade adalah satu-satunya jalur pemulihan yang tidak bergantung pada proses boot apa pun. Memulihkannya akan mengembalikan disk ke kondisi saat kernel lama masih menjadi default, sehingga Anda dapat mencoba kembali upgrade dengan console yang sudah terbuka. Snapshot mesin yang sedang berjalan bersifat crash-consistent. Artinya, snapshot menangkap kondisi disk seolah-olah daya listrik baru saja diputus. Karena itu, matikan server terlebih dahulu jika provider Anda mendukung snapshot offline. Snapshot juga bukan backup, karena biasanya disimpan pada infrastruktur yang sama dengan volume sumbernya. Memahami perbedaan antara snapshot VPS dan backup yang sebenarnya menentukan opsi yang dapat menyelamatkan Anda ketika kegagalan lebih besar daripada masalah kernel.

Hal ini paling penting pada release upgrade, karena kernel, alat initramfs, bootloader, dan konfigurasi GRUB semuanya berubah dalam satu proses. Ambil snapshot tepat sebelum Anda memulai upgrade Ubuntu 24.04 ke 26.04, bukan pada malam sebelumnya, agar titik pemulihan sesuai dengan mesin yang akan Anda ubah. Jika upgrade tersebut belum ditawarkan pada server Anda, penyebabnya adalah penjadwalan, bukan konfigurasi yang rusak, karena lompatan dari satu versi LTS ke versi LTS berikutnya baru dibuka pada point release pertama, 26.04.1.

Cara unattended-upgrades menangani paket kernel

Ubuntu's unattended-upgrades menginstal pembaruan keamanan tanpa meminta konfirmasi, dan paket kernel masuk melalui security pocket seperti paket lainnya. Ada dua konsekuensi.

Pertama, kernel baru sudah terinstal, tetapi belum berjalan. Kernel baru hanya berlaku setelah boot. File /var/run/reboot-required muncul, dan /var/run/reboot-required.pkgs mencatat apa yang meminta reboot, tetapi tidak ada yang melakukan restart kecuali Anda mengaktifkan Unattended-Upgrade::Automatic-Reboot di /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

Kedua, jeda tersebut menyamarkan penyebabnya. Server dapat menginstal kernel pada Maret dan melakukan reboot pada Juni karena alasan yang sama sekali tidak terkait, lalu gagal melakukan boot. Perubahan yang menyebabkan kegagalan boot sudah berusia tiga bulan, sehingga tidak ada tindakan yang Anda lakukan pada hari itu yang menjelaskannya. /var/log/apt/history.log adalah tempat untuk menemukan proses yang menginstal kernel yang sekarang menyebabkan kegagalan.

Lakukan reboot secara sengaja, pada hari yang telah Anda pilih, dengan jendela konsol sudah terbuka. Kebiasaan sederhana ini mengubah outage yang misterius menjadi pemilihan menu selama dua menit. Jika Anda ingin otomatisasi tanpa kejutan, pertahankan instalasi otomatis tetap aktif dan reboot otomatis tetap nonaktif, lalu lihat cara mengonfigurasi unattended-upgrades di Ubuntu untuk pengaturan yang tepat. Menahan paket kernel dengan sudo apt-mark hold linux-image-generic akan menghentikan pembaruan tersebut sepenuhnya, termasuk perbaikan keamanan kernel, jadi anggap ini sebagai trade-off yang memang Anda pilih, bukan sebagai langkah pengamanan.

FAQ

Bagaimana cara mem-boot kernel lama pada VPS tanpa keyboard?

Buka console provider (VNC atau serial), lalu picu hard reset dari control panel karena Anda tidak dapat login untuk melakukan reboot secara normal. Saat mesin melakukan restart, tekan Esc berulang kali, atau tahan Shift saat melakukan boot dengan legacy BIOS, agar menu GRUB tetap terbuka. Pilih "Advanced options for Ubuntu", lalu pilih entri di bawah kernel terbaru. Setelah prompt login muncul, jalankan uname -r untuk mengonfirmasi kernel yang sedang digunakan dan dpkg -l 'linux-image-*' untuk melihat kernel lain yang terpasang. Lakukan diagnosis hanya setelah sistem berjalan kembali.

Mengapa VPS saya sama sekali tidak menampilkan menu GRUB?

Cloud image biasanya menetapkan timeout GRUB ke 0 dalam file di bawah /etc/default/grub.d/, sehingga kernel terbaru langsung dijalankan tanpa menunggu input. Tetapkan GRUB_TIMEOUT=10 dan GRUB_TIMEOUT_STYLE=menu dalam /etc/default/grub, tambahkan GRUB_TERMINAL="console serial" agar menu juga tersedia pada serial console, lalu jalankan sudo update-grub. Verifikasi dengan grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ karena file dalam direktori tersebut dibaca setelah file utama dan dapat menimpa perubahan Anda.

Apakah kernel lama sebaiknya dihapus untuk mengosongkan ruang di /boot?

Hapus kernel yang paling lama dan pertahankan setidaknya dua kernel. /boot yang penuh merupakan mode kegagalan tersendiri karena pembuatan initramfs kemudian gagal dan Anda akan memiliki kernel tanpa image yang dapat digunakan. Hapus kernel berdasarkan nama paket yang tepat setelah memeriksa uname -r agar kernel yang sedang berjalan tidak pernah menjadi kandidat. Hindari menjalankan sudo apt autoremove --purge secara menyeluruh pada mesin headless karena daftar kernel yang dilindungi dibuat ulang setiap kali kernel berubah, dan eksekusi pada waktu yang tidak tepat dapat menyisakan satu kernel tanpa entri fallback dalam menu.

Apakah unattended-upgrades dapat menyebabkan boot gagal?

unattended-upgrades dapat memasang kernel yang kemudian gagal melakukan boot, tetapi tidak me-restart mesin kecuali Unattended-Upgrade::Automatic-Reboot ditetapkan ke true dalam /etc/apt/apt.conf.d/50unattended-upgrades. Pola yang umum adalah kegagalan yang tertunda: kernel terpasang saat proses otomatis berjalan, /var/run/reboot-required muncul, dan masalah baru terlihat saat Anda melakukan reboot beberapa minggu kemudian. Lakukan reboot secara sengaja dengan console yang sudah terbuka, lalu baca /var/log/apt/history.log untuk mengetahui proses mana yang memasang kernel yang sedang Anda gunakan untuk boot.