VPS Tidak Bisa Boot Setelah Update Kernel: Cara Pulih

Hal pertama yang harus dilakukan ketika 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 kemarin. Ubuntu memasang kernel baru berdampingan dengan kernel lama dan hanya mengubah entri yang dijalankan GRUB secara default. Jadi, langkah 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 tidak pernah mencapai tahap saat sshd dimulai. Semua langkah di bawah dilakukan melalui console milik provider Anda.

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

Bagaimana cara mengakses konsol saat SSH tidak berfungsi?

Buka panel kontrol provider Anda dan cari konsol. Nama yang umum digunakan adalah VNC console, web console, noVNC, dan serial console. Jika keduanya tersedia, pilih serial console karena konsol ini menampilkan teks nyata yang dapat digulir dan disalin, sedangkan tampilan VNC hanya berupa gambar layar. Cari fitur ini sekarang, saat mesin masih sehat, dan pastikan fitur tersebut dapat dibuka. Mencarinya saat terjadi gangguan akan menghabiskan ketenangan yang Anda perlukan. Pemeriksaan ini termasuk dalam sepuluh menit pertama pada VPS baru, bersama aturan firewall dan kunci SSH.

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 Anda yang berjalan. Rescue mode digunakan saat GRUB itu sendiri rusak. Fitur ini juga digunakan untuk menyalin data dari server yang sudah Anda putuskan untuk tidak diselamatkan.

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

Bagaimana cara memilih kernel versi lama di menu GRUB?

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

Saat menu muncul, pilih "Advanced options for Ubuntu". Submenu tersebut mencantumkan setiap kernel yang terpasang, dengan kernel terbaru di urutan pertama, serta entri recovery mode untuk setiap kernel. Pilih entri normal kedua, yaitu kernel di bawah kernel terbaru, lalu tekan Enter. Recovery mode adalah hal yang berbeda. Mode ini melakukan boot ke sistem pengguna tunggal minimal dan digunakan untuk perbaikan, bukan untuk membuat service Anda kembali online.

Jika kernel versi lama berhasil melakukan boot, server Anda sudah kembali berjalan. Konfirmasikan kernel yang sedang digunakan dan catat nomornya.

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

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

Menu GRUB tidak pernah muncul. Apa yang harus dilakukan?

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

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

Perbaiki kedua kondisi tersebut saat mesin masih berfungsi 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 pastikan hasil edit 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" mengirim menu ke konsol grafis dan port serial, sehingga menu muncul pada viewer yang disediakan panel Anda. Argumen kernel console= melakukan hal yang sama untuk pesan boot berikutnya. Penundaan sepuluh detik pada setiap boot adalah harga yang wajar agar menu dapat diakses pada pukul 2 pagi.

Kelas kegagalan apa yang sedang saya hadapi?

Baca dua puluh baris terakhir sebelum keluaran pada konsol berhenti berubah. Empat pola mencakup sebagian besar hal yang terjadi setelah pembaruan kernel.

GRUB tidak dapat menemukan berkasnya sendiri. Anda mendapatkan prompt grub rescue>, atau pesan 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 device yang salah, bukan karena paket kernel itu sendiri.

Kernel berjalan, tetapi tidak dapat me-mount root. Pesan kernel bergulir, lalu Anda masuk ke shell busybox dengan prompt (initramfs), atau proses boot berakhir dengan panic karena root filesystem tidak dapat di-mount. Kernel sudah dimuat. initramfs, yaitu root sementara berukuran kecil yang mencari dan me-mount root filesystem sebenarnya, tidak menemukan disk tersebut. Pada Ubuntu, shell ini biasanya didahului pesan tentang berhenti menunggu root device, dan pesan itu menyebutkan 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 kendali ke skrip initramfs, yang kemudian mencoba me-mount ulang filesystem. Jika sistem kemudian berhasil boot, initramfs yang baru tidak memiliki komponen LVM. 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 server kembali aktif, periksa mode 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 sudah melakukan boot dan proses userspace berhenti. Biasanya penyebabnya adalah baris yang salah dalam /etc/fstab atau filesystem yang gagal diperiksa. Jalankan journalctl -xb dalam shell tersebut, lalu baca nama unit yang gagal.

Apakah paket kernel rusak, atau initramfs?

Keduanya tampak 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

Anda harus memiliki satu vmlinuz- dan satu initrd.img- yang cocok untuk setiap versi yang terpasang, masing-masing dengan ukuran yang wajar. initrd yang hilang, atau ukurannya jauh lebih kecil daripada versi lain, berarti 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 secara tepat, termasuk waktunya. 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 ini bukan rilis nyata:

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

ls terakhir itu adalah pemeriksaannya. File dengan ukuran normal berarti image tersebut sudah tersedia. 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

Memperbaiki sistem dari rescue mode saat tidak ada kernel yang dapat melakukan boot

Jika semua entri pada menu gagal, boot rescue image dari provider lalu perbaiki disk dari luar sistem. Disk Anda akan muncul sebagai device yang belum di-mount. Dengan demikian, tidak ada proses di dalamnya yang berjalan dan mengganggu proses 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

Uji kernel baru tanpa mempertaruhkan boot berikutnya

GRUB dapat menjalankan satu entri sekali, lalu kembali ke default yang Anda pilih. Arahkan default ke kernel yang Anda percaya, 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 dalam /etc/default/grub, jalankan sudo update-grub, lalu tampilkan judul entri agar Anda dapat menuliskan salah satunya secara tepat:

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 seharusnya menampilkan judul yang Anda pilih sebagai saved_entry. Output tersebut membuktikan bahwa mekanisme ini berfungsi, karena penyimpanan memerlukan /boot/grub/grubenv yang dapat ditulisi, dan pada beberapa tata letak, kondisi ini tidak terpenuhi tanpa menampilkan pesan. Entri 0 berada di bagian teratas menu, yaitu kernel terbaru. Judul lebih aman daripada angka dalam kasus ini karena angka berubah setiap kali kernel diinstal atau dihapus.

Mengapa autoremove berisiko pada server tanpa antarmuka lokal

APT menyimpan daftar paket kernel yang tidak boleh dihapus secara otomatis. Tampilkan 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 antarmuka lokal, hal ini menentukan apakah Anda dapat memilih entri menu atau harus memasang disk dari image pemulihan.

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

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

Jalankan kembali perintah terakhir tersebut setelah selesai. Jika jumlah kernel berkurang dari tiga menjadi dua, itu adalah pembersihan biasa. Jika jumlahnya menjadi satu, pemadaman layanan hanya menunggu reboot berikutnya.

Buat snapshot sebelum upgrade

Snapshot yang dibuat sebelum apt upgrade adalah satu-satunya jalur pemulihan yang tidak bergantung pada proses boot apa pun. Memulihkannya 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 tersebut menangkap kondisi disk seolah-olah daya terputus. 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 yang disalinnya. Memahami perbedaan antara snapshot VPS dan backup yang sebenarnya menentukan opsi yang dapat menyelamatkan Anda ketika kegagalannya lebih besar daripada masalah kernel.

Hal ini paling penting saat melakukan release upgrade, karena kernel, tool initramfs, bootloader, dan konfigurasi GRUB semuanya berubah dalam satu proses. Buat snapshot segera sebelum Anda memulai upgrade Ubuntu 24.04 ke 26.04, bukan pada malam sebelumnya, agar titik pemulihan sesuai dengan kondisi mesin yang akan Anda ubah.

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 terinstal, tetapi belum berjalan. Kernel hanya mulai berlaku saat boot. File /var/run/reboot-required muncul, dan /var/run/reboot-required.pkgs menunjukkan 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 ini menyamarkan penyebabnya. Server dapat menginstal kernel pada Maret dan melakukan reboot pada Juni karena alasan yang sama sekali tidak terkait, lalu gagal menyala. Perubahan yang menyebabkan boot gagal terjadi tiga bulan sebelumnya, sehingga tidak ada tindakan yang Anda lakukan hari itu yang menjelaskan kegagalan tersebut. /var/log/apt/history.log adalah tempat Anda menemukan proses yang menginstal kernel yang sekarang menyebabkan kegagalan.

Lakukan reboot secara sengaja pada hari yang Anda tentukan, dengan jendela konsol sudah terbuka. Kebiasaan sederhana ini mengubah outage misterius menjadi pemilihan menu selama dua menit. Jika Anda menginginkan otomatisasi tanpa kejutan, tetap aktifkan instalasi otomatis dan nonaktifkan reboot otomatis. Lihat cara mengonfigurasi unattended-upgrades di Ubuntu untuk pengaturan yang tepat. Menahan paket kernel dengan sudo apt-mark hold linux-image-generic menghentikannya sepenuhnya, dan pada saat yang sama menghentikan perbaikan keamanan kernel. Karena itu, anggap tindakan tersebut sebagai kompromi yang memang Anda pilih, bukan sebagai langkah keamanan.

FAQ

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

Buka console milik provider (VNC atau serial), lalu lakukan 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 jika menggunakan boot legacy BIOS, agar menu GRUB tetap terbuka. Pilih "Advanced options for Ubuntu", lalu pilih entri di bawah kernel terbaru. Setelah prompt login tersedia, jalankan uname -r untuk memastikan kernel yang sedang digunakan dan dpkg -l 'linux-image-*' untuk melihat kernel lain yang terpasang. Lakukan diagnosis hanya setelah sistem kembali berjalan.

Mengapa VPS saya sama sekali tidak menampilkan menu GRUB?

Cloud image biasanya mengatur timeout GRUB menjadi 0 dalam file di bawah /etc/default/grub.d/, sehingga kernel terbaru langsung dijalankan tanpa memberi waktu untuk menekan tombol. Atur GRUB_TIMEOUT=10 dan GRUB_TIMEOUT_STYLE=menu dalam /etc/default/grub, tambahkan GRUB_TERMINAL="console serial" agar menu juga tersedia melalui 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 akan 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 tanpa akses keyboard, 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 di menu.

Apakah unattended-upgrades dapat menyebabkan boot gagal?

unattended-upgrades dapat memasang kernel yang kemudian gagal melakukan boot, tetapi tidak akan me-restart mesin kecuali Unattended-Upgrade::Automatic-Reboot diatur ke true dalam /etc/apt/apt.conf.d/50unattended-upgrades. Pola yang umum adalah kegagalan yang tertunda: kernel dipasang 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 yang memasang kernel yang sedang Anda gunakan untuk boot.