Cara Menetapkan Kernel Boot Berikutnya di VPS Ubuntu

Yang menentukan kernel yang digunakan VPS saat boot

Kernel yang akan digunakan VPS pada boot berikutnya ditentukan oleh satu file yang dibuat secara otomatis, /boot/grub/grub.cfg. Anda tidak boleh mengedit file tersebut. Edit file input-nya, lalu buat ulang file itu. Pada cloud image Ubuntu, salah satu input tersebut berasal dari vendor image. Input ini dapat membuat pemilihan menu tidak berpengaruh. Karena itu, GRUB_DEFAULT=1 yang diikuti update-grub tidak mengubah apa pun pada server sewaan, sedangkan dua langkah yang sama dapat berfungsi pada instalasi laptop.

Lakukan pemeriksaan dalam urutan berikut. Pastikan kernel tersebut memang dapat Anda pilih. Baca setiap file input, termasuk file yang ditambahkan vendor. Baca output yang dibuat secara otomatis dan hitung entri yang benar-benar ada di dalamnya. Setelah itu, pilih metode pinning. Jika Anda salah melakukan langkah ini pada mesin yang hanya dapat diakses melalui SSH, Anda mungkin memerlukan rescue console. Karena itu, jawaban yang paling aman terdapat di bagian akhir halaman ini dan sering kali merupakan pilihan yang tepat.

Pastikan terlebih dahulu bahwa kernel tersebut dapat Anda tetapkan

uname -r
systemd-detect-virt
ls -1 /boot/vmlinuz-*

systemd-detect-virt yang menampilkan kvm, qemu, atau xen berarti Anda menggunakan kernel sendiri dan semua langkah berikutnya berlaku. Jika yang ditampilkan adalah lxc atau openvz, server Anda menggunakan kernel milik host. Artinya, Anda tidak memiliki bootloader sendiri dan tidak ada kernel yang dapat Anda tetapkan. Dalam kondisi tersebut, uname -r melaporkan versi yang sama sekali tidak muncul di /boot/vmlinuz-*, karena kernel yang sedang berjalan adalah milik host dan tidak ada pengaturan pada disk Anda yang dapat mengubahnya.

ls -1 /boot/vmlinuz-* adalah daftar kernel sebenarnya yang dapat Anda pilih. Jika hanya berisi satu baris, kernel sebelumnya sudah dihapus dan tidak ada pengaturan bootloader yang dapat mengembalikannya. Hal ini biasanya terjadi saat autoremove. Pahami proses tersebut terlebih dahulu sebelum Anda membersihkan kernel lama di Ubuntu pada server yang penting.

Berkas yang Anda edit bukan berkas yang dibaca GRUB

/etc/default/grub berisi penetapan variabel shell biasa. Berkas ini merupakan input. /boot/grub/grub.cfg adalah output. Berkas ini diawali dengan # DO NOT EDIT THIS FILE beserta alasannya. Apa pun yang Anda tulis ke dalam output akan hilang saat paket kernel diinstal atau dihapus, karena skrip paket tersebut membuat ulang berkas itu.

cat /usr/sbin/update-grub

update-grub adalah wrapper. Perintah ini menjalankan grub-mkconfig -o /boot/grub/grub.cfg, yang membaca variabel, menjalankan setiap skrip di /etc/grub.d/, lalu menulis hasilnya. Dua perintah, satu arah: input masuk, grub.cfg dihasilkan.

Yang mengesampingkan pengaturan Anda: /etc/default/grub.d

grep -rn '^[^#]' /etc/default/grub /etc/default/grub.d/

Path kedua adalah bagian yang sering terlewat. grub-mkconfig terlebih dahulu memuat /etc/default/grub, lalu setiap file *.cfg di /etc/default/grub.d/ dalam urutan glob. Baca kode yang melakukannya:

grep -n 'default/grub' /usr/sbin/grub-mkconfig

Proses pemuatan ini menggunakan shell biasa, sehingga assignment terakhir yang berlaku. Ubuntu cloud images menyertakan file di direktori tersebut dan menetapkan hal-hal seperti timeout serta command line kernel setelah file Anda selesai dibaca. GRUB_TIMEOUT=10 di /etc/default/grub akan ditimpa sesaat kemudian oleh file vendor yang menetapkannya ke 0. Perintah grep di atas menampilkan assignment yang tepat pada image Anda. Karena itu, baca hasil tersebut dan jangan hanya mengandalkan kalimat ini.

Aturan praktisnya adalah menempatkan pengaturan Anda sendiri dalam file yang diurutkan paling akhir, seperti /etc/default/grub.d/99-local.cfg, bukan mengedit /etc/default/grub. Dengan demikian, tidak ada file yang disertakan oleh image yang dapat dimuat setelah file Anda.

Mengapa GRUB_FORCE_PARTUUID membuat pemilihan menu tidak relevan

grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/
grep -n GRUB_FORCE_PARTUUID /etc/grub.d/10_linux
sudo grep -n 'root=PARTUUID' /boot/grub/grub.cfg

GRUB_FORCE_PARTUUID memberi tahu generator untuk menemukan filesystem root berdasarkan UUID partisi. Nilai ini ditulis langsung ke command line kernel sebagai root=PARTUUID=..., bukan mencari UUID filesystem saat boot. Vendor image menetapkannya agar satu disk image dapat boot secara andal pada hardware yang bukan tempat image tersebut dibuat. Perintah grep kedua menampilkan kode yang memproses variabel tersebut, di /etc/grub.d/10_linux. Script itu berada di disk Anda sendiri dan menjadi acuan untuk mengetahui perilaku image Anda.

Konsekuensi inilah yang penting: pada jalur tersebut, generator menulis entri boot langsung, bukan daftar lengkap kernel yang terpasang. Hitung hasil akhirnya.

sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg
sudo grep -nE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg

Jika hasilnya 1, tidak ada entri kedua yang dapat dipilih. Jadi, GRUB_DEFAULT=1 menunjuk ke entri yang tidak ada. GRUB tidak dapat menyelesaikannya, sehingga melakukan boot pada entri pertama, yaitu kernel baru yang ingin Anda hindari. grub-set-default juga tidak membantu karena bagian yang bermasalah bukan nilai default. Menu yang ingin Anda pilih memang tidak pernah dibuat.

Untuk mengembalikan menu lengkap, pindahkan file vendor tersebut ke lokasi lain dan pratinjau hasilnya sebelum menerapkannya. grub-mkconfig tanpa -o menulis ke output standar dan tidak mengubah apa pun di disk.

sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '
sudo mkdir -p /root/grub-backup
sudo mv /etc/default/grub.d/<the file your grep named> /root/grub-backup/
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '

Jika jumlah entri berubah dari 1 menjadi beberapa entri, berarti entri tersebut muncul setelah pemaksaan dihapus. Belum ada perubahan yang ditulis. Kembalikan file tersebut jika jumlah kedua tidak sesuai, karena PARTUUID yang dipaksakan itulah yang digunakan image provider Anda untuk menemukan filesystem root. Menghapusnya akan mengalihkan mesin ke jalur pencarian. Buat snapshot sebelum benar-benar menjalankan update-grub.

Jika satu-satunya tujuan Anda adalah melewati satu kernel yang bermasalah, berhenti di sini dan gunakan opsi yang lebih aman di bagian selanjutnya. Membangun ulang menu boot pada server remote untuk mengatasi satu upgrade memiliki risiko yang lebih besar daripada manfaatnya.

Mengapa nomor entri bukan pilihan yang tepat untuk dikunci

GRUB_DEFAULT menerima nomor, judul, atau identifier. Nomor menghitung entri tingkat teratas mulai dari 0. Entri bertingkat menggunakan > sebagai pemisah, sehingga GRUB_DEFAULT="1>2" berarti entri pada indeks 2 di dalam submenu pada indeks 1.

Indeks dapat berubah. 10_linux menampilkan kernel terbaru lebih dahulu, sehingga pemasangan kernel akan menggeser setiap entri yang lebih lama satu posisi ke bawah, sedangkan penghapusan kernel akan menggesernya ke atas. 1>2 yang Anda buat dengan cermat tetap valid setelah perubahan tersebut. Namun, sekarang 1>2 merujuk ke kernel yang berbeda. Tidak ada error atau peringatan, dan Anda baru mengetahuinya setelah reboot.

Identifier tidak berubah karena masing-masing memuat versi kernel. Tampilkan identifier Anda:

sudo awk -F"'" '/menuentry_id_option/ {print $2, "==>", $4}' /boot/grub/grub.cfg

Abaikan beberapa baris pertama output. Baris tersebut berisi variabel yang didefinisikan pada header. Setelah itu, sisi kiri adalah judul yang dilihat pembaca, sedangkan sisi kanan adalah identifier yang diberikan ke tools. Untuk entri di dalam submenu, gabungkan identifier submenu dan identifier entri dengan >, dalam urutan tersebut, sama persis seperti pada bentuk numerik.

Boot kernel sebelumnya satu kali dengan grub-reboot

Pemilihan satu kali adalah langkah yang tepat pada server jarak jauh karena pilihan tersebut akan dibatalkan secara otomatis. grub-reboot menulis next_entry ke dalam /boot/grub/grubenv. GRUB membaca variabel tersebut, menghapusnya, lalu menyimpan nilai yang sudah dihapus sebelum melakukan boot apa pun. Dengan demikian, kernel yang mengalami panic tidak akan dicoba lagi pada boot berikutnya. Anda mendapatkan satu kali percobaan, lalu mesin kembali ke default normal secara otomatis.

Pastikan terlebih dahulu bahwa konfigurasi yang dihasilkan memang membaca variabel tersebut:

sudo grep -n -B2 -A5 'next_entry' /boot/grub/grub.cfg

Anda harus melihat baris load_env dan blok yang menetapkan default dari next_entry. Jika grep tidak menghasilkan apa pun, image Anda tidak pernah membaca grubenv saat boot. Akibatnya, grub-reboot akan diterima oleh shell, tetapi diabaikan oleh bootloader. Ini adalah jalur boot langsung yang dipaksakan dari bagian sebelumnya, tetapi muncul di tempat kedua.

sudo grub-reboot '<the identifier you copied>'
sudo grub-editenv list

grub-editenv list sekarang seharusnya menampilkan baris next_entry= yang berisi tepat nilai yang Anda berikan. Buka console provider Anda di tab browser, lalu lakukan reboot dan periksa hasilnya.

sudo reboot

uname -r

Jika uname -r melaporkan versi yang lebih lama, berarti pin berhasil. Jika yang dilaporkan adalah versi baru, berarti identifier tidak dapat ditemukan atau grubenv tidak sedang dibaca. Apa pun hasilnya, mesin tetap aktif. Inilah alasan menggunakan bentuk satu kali.

Jadikan pilihan tetap dengan GRUB_DEFAULT=saved

GRUB_DEFAULT=saved mengambil nilai default dari saved_entry di grubenv, dan Anda menetapkan nilai tersebut dengan grub-set-default. Nilai ini tetap berlaku setelah instalasi kernel karena update-grub menulis ulang grub.cfg dan tidak pernah mengubah grubenv.

echo 'GRUB_DEFAULT=saved' | sudo tee /etc/default/grub.d/99-local.cfg
sudo update-grub
sudo grub-set-default '<the identifier you copied>'
sudo grub-editenv list
sudo grep -n 'set default' /boot/grub/grub.cfg

Perintah terakhir harus menampilkan set default="${saved_entry}". Jika menampilkan set default="0", berarti sesuatu yang dimuat setelah file Anda mengubah GRUB_DEFAULT kembali menjadi nilai literal. Karena itu, tampilkan kembali /etc/default/grub.d/ dan pastikan 99-local.cfg benar-benar diurutkan terakhir.

GRUB_SAVEDEFAULT=true adalah pengaturan yang berbeda dan mudah tertukar dengan pengaturan ini. Pengaturan tersebut menyimpan kernel yang baru saja Anda boot sebagai default baru, sehingga default mengikuti boot terakhir yang berhasil. Pada server, reboot tanpa pengawasan dapat mengubah pin secara diam-diam. Biarkan pengaturan ini nonaktif kecuali memang itu yang Anda inginkan.

Pin berdasarkan identifier masih dapat gagal dalam satu kondisi. Jika kernel yang dirujuk dihapus, identifier tersebut tidak lagi dapat di-resolve dan sistem kembali ke entri pertama. Karena itu, tahan paket tersebut atau cegah kernel itu dari autoremove.

Menampilkan menu pada konsol provider

Pemilihan secara interaktif memerlukan menu yang tampil di layar, sedangkan image cloud menyembunyikannya. Tambahkan baris berikut ke file yang diurutkan paling akhir, lalu jalankan sudo update-grub.

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

GRUB_TIMEOUT_STYLE=hidden bersama GRUB_TIMEOUT=0 tidak menampilkan apa pun. Akibatnya, orang yang memantau konsol akan langsung melihat pesan kernel dan menyimpulkan bahwa bootloader dilewati. GRUB_RECORDFAIL_TIMEOUT adalah timeout terpisah yang digunakan setelah proses boot tidak selesai. Image cloud juga menetapkannya ke 0. Karena itu, server yang baru saja gagal melakukan boot tetap tidak berhenti untuk menunggu Anda.

Jika provider Anda menyediakan konsol serial, bukan konsol grafis, dan Anda tetap tidak melihat apa pun, GRUB menulis ke terminal yang tidak dapat Anda lihat. Tambahkan kedua baris tersebut bersama-sama. Baris pertama memilih output, sedangkan baris kedua mengonfigurasi port:

GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Sepuluh detik akan ditambahkan ke setiap proses boot mulai sekarang. Setelah selesai, kembalikan timeout ke 0.

Opsi yang lebih aman daripada mengedit bootloader

Mengubah input bootloader pada mesin yang hanya Anda akses melalui SSH adalah opsi dengan risiko tertinggi di halaman ini. Ada cara yang lebih sederhana, dan biasanya cara tersebut menyelesaikan masalah yang sebenarnya.

Tahan paket kernel. Jika tujuannya adalah "jangan berikan kernel yang lebih baru", sampaikan hal itu kepada package manager, bukan kepada bootloader.

apt list --installed 2>/dev/null | grep -E '^linux-(image|headers|generic|virtual|kvm|aws|azure|gcp|oracle)'
sudo apt-mark hold linux-image-virtual linux-headers-virtual
apt-mark showhold

Gunakan nama apa pun yang dicetak oleh perintah pertama, karena image cloud biasanya memasang varian virtual atau kvm, bukan generic. Jika kernel yang lebih baru muncul saat refresh image dan Anda menduga rilisnya sendiri berubah tanpa Anda sadari, itu tidak terjadi, karena point release adalah pembaruan yang sudah Anda miliki dan digabungkan ke media instalasi baru dan tidak memberikan apa pun kepada server yang sudah ditambal yang belum ditawarkan beberapa minggu sebelumnya. Paket yang ditahan akan dilewati oleh apt upgrade, yang mengumumkannya dengan The following packages have been kept back:, dan juga dilewati oleh unattended upgrades di Ubuntu. Biayanya nyata: kernel yang ditahan tidak lagi menerima perbaikan keamanan. Perlakukan tindakan ini sebagai jeda yang memiliki tanggal berakhir, lalu lepaskan penahan tersebut dengan sudo apt-mark unhold. Jika Anda menghindari pembaruan kernel karena reboot menyebabkan downtime, bukan karena kernel tertentu bermasalah, live kernel patching pada VPS adalah solusi yang tepat.

Buat snapshot sebelum upgrade. Snapshot dapat dipulihkan dalam hitungan menit, tanpa mengetik melalui console dan tanpa risiko perubahan bootloader yang hanya diterapkan sebagian. Buat snapshot, lakukan upgrade, reboot, lalu verifikasi. Jika kernel baru bermasalah, lakukan rollback dan jalur boot akan kembali persis seperti sebelumnya.

Gunakan console atau rescue image untuk mesin yang sudah tidak dapat berjalan. Setelah server tidak dapat boot, konfigurasi bootloader bukan tempat untuk memperbaikinya. Jalur pemulihan tersebut merupakan prosedur tersendiri: yang harus dilakukan saat VPS tidak dapat boot setelah pembaruan kernel.

Hal yang rusak dan pesan yang akan Anda lihat

Edit Anda pada /boot/grub/grub.cfg menghilang. Paket kernel diinstal atau dihapus, skrip pemeliharanya dijalankan melalui update-grub, lalu file dibuat ulang dari input tersebut. Header # DO NOT EDIT THIS FILE mencantumkan dua lokasi input. Edit lokasi tersebut.

grub-editenv: error: environment block too small. /boot/grub/grubenv hilang atau terpotong. Buat ulang dengan sudo grub-editenv /boot/grub/grubenv create, lalu tetapkan kembali nilai Anda dan konfirmasikan dengan sudo grub-editenv list.

Kernel yang ditetapkan mengalami panic dengan VFS: Unable to mount root fs on unknown-block(0,0). Entri yang Anda tetapkan menunjuk ke kernel atau initrd yang sudah tidak ada di disk. Biasanya hal ini terjadi karena paket dihapus, tetapi pengenalnya masih tercantum dalam grubenv. Pemulihan dilakukan dengan mem-boot entri yang berfungsi melalui konsol, lalu menghapus nilai yang sudah tidak berlaku.

uname -r tidak berubah setelah reboot yang seharusnya mengubahnya. Periksa tiga hal secara berurutan: apakah grub-editenv list masih menampilkan nilai Anda atau sudah digunakan; apakah pengenal yang Anda tetapkan muncul dalam grub.cfg saat ini; dan apakah grub.cfg berisi baris set default yang membaca variabel yang Anda tetapkan. Salah satu dari tiga hal tersebut selalu menjelaskannya.

Menu muncul sendiri setelah crash. GRUB mencatat kegagalan boot dalam grubenv sebagai recordfail=1, lalu memaksa menu tampil pada boot berikutnya agar operator dapat melakukan intervensi. Hapus dengan sudo grub-editenv /boot/grub/grubenv unset recordfail setelah mesin kembali sehat.

Satu kalimat yang perlu diingat: file yang Anda edit bukan file yang dibaca GRUB, dan pada cloud image, celah di antara keduanya adalah sumber kebingungan. Baca konfigurasi yang dibuat terlebih dahulu. Setiap keputusan di halaman ini didasarkan pada isi sebenarnya.

FAQ

Mengapa GRUB_DEFAULT=1 tidak mengubah kernel yang digunakan VPS saya saat boot?

Karena pada cloud image Ubuntu, /boot/grub/grub.cfg yang dibuat biasanya hanya memuat satu entri boot. Oleh karena itu, indeks 1 tidak merujuk ke apa pun dan GRUB kembali menggunakan entri pertama. Pastikan dengan sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg. Hasil 1 adalah jawabannya. Penyebabnya adalah GRUB_FORCE_PARTUUID, yang ditetapkan oleh vendor image dalam file di bawah /etc/default/grub.d/. Pengaturan ini membuat generator menggunakan jalur boot langsung, bukan membuat daftar lengkap kernel yang terpasang. Temukan file tersebut dengan grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/.

Bagaimana cara melakukan boot menggunakan kernel sebelumnya hanya satu kali?

Jalankan sudo grub-reboot '<identifier>' dengan identifier yang disalin dari grub.cfg milik Anda, lalu reboot setelah console provider terbuka. GRUB menghapus next_entry sebelum melakukan boot. Dengan demikian, pilihan tersebut hanya berlaku untuk satu percobaan, dan kernel yang mengalami panic tidak akan dicoba lagi. Pastikan nilainya telah diterapkan dengan sudo grub-editenv list. Sebelum mengandalkannya, jalankan sudo grep -n next_entry /boot/grub/grub.cfg, karena image yang konfigurasinya tidak pernah memuat grubenv akan mengabaikan perintah tersebut tanpa menampilkan error.

Sebaiknya menggunakan nomor entri atau identifier?

Gunakan identifier. Nomor entri adalah posisi dalam daftar yang 10_linux buat ulang dengan urutan terbaru di bagian atas. Karena itu, pemasangan atau penghapusan kernel apa pun dapat menggeser nomor tersebut. 1>2 yang sudah tidak sesuai masih dapat merujuk ke entri yang benar-benar ada, tetapi salah, tanpa peringatan apa pun. Identifier memuat versi kernel, sehingga identifier tersebut akan cocok dengan kernel yang dimaksud atau gagal ditemukan. Tampilkan daftar identifier dengan sudo grep -n menuentry_id_option /boot/grub/grub.cfg, lalu salin string yang diapit tanda kutip setelah setiap baris entri.

Apakah menahan paket kernel lebih aman daripada mengubah bootloader?

Untuk tujuan umum, ya. sudo apt-mark hold linux-image-virtual linux-headers-virtual mencegah kernel yang lebih baru terpasang, sehingga jalur boot tidak pernah berubah dan tidak ada konfigurasi yang dapat keliru akibat akses console yang mungkin tidak Anda miliki. Periksa nama flavour yang terpasang pada server Anda dengan apt list --installed, lalu verifikasi bahwa paket tersebut ditahan dengan apt-mark showhold. Konsekuensinya, kernel yang ditahan tidak menerima perbaikan keamanan. Karena itu, tentukan kapan Anda akan menjalankan sudo apt-mark unhold sebelum menahan paket tersebut.