VPS Tidak Boleh Boot Selepas Kemas Kini Kernel

Perkara pertama yang perlu dilakukan apabila VPS tidak but selepas kemas kini kernel

VPS yang tidak but selepas kemas kini kernel biasanya boleh dipulihkan dalam beberapa minit, kerana kemas kini tersebut tidak memadamkan kernel yang berfungsi semalam. Ubuntu memasang kernel baharu di samping kernel lama dan hanya menukar entri yang dimulakan oleh GRUB secara lalai. Jadi, langkah pertama bukanlah pembaikan. Pilih kernel sebelumnya dalam menu but, dapatkan semula prompt log masuk, kemudian buat diagnosis daripada sistem yang sedang berjalan.

Membaiki perkara ini pada pelayan adalah berbeza daripada membaiki komputer riba, kerana tiada papan kekunci disambungkan dan tiada monitor yang memaparkan panik kernel. SSH juga tidak akan menjawab, kerana mesin tersebut tidak pernah mencapai tahap di mana sshd bermula. Semua perkara di bawah dilakukan melalui konsol pembekal anda.

Baca konsol anda sendiri sebelum anda menukar apa-apa. Teks pada skrin tersebut menentukan kelas kegagalan yang anda hadapi, dan dua pelayan yang kedua-duanya "tidak mahu but" mungkin memerlukan pembaikan yang bertentangan.

Bagaimanakah cara untuk mencapai konsol apabila SSH tidak berfungsi?

Buka panel kawalan pembekal anda dan cari konsol. Nama yang biasa digunakan ialah VNC console, web console, noVNC, dan serial console. Utamakan serial console jika kedua-duanya tersedia, kerana ia memberikan teks sebenar yang boleh anda tatal dan salin, manakala paparan VNC hanyalah gambar skrin. Cari kawalan ini sekarang, semasa mesin dalam keadaan sihat, dan pastikan ia boleh dibuka. Mencarinya semasa gangguan perkhidmatan akan menghilangkan ketenangan yang anda perlukan. Semakan itu perlu dilakukan dalam sepuluh minit pertama pada VPS baharu, bersama-sama dengan peraturan firewall dan kunci SSH.

Kebanyakan panel juga menawarkan mod penyelamat (rescue mode) atau imej pemulihan. Ia memulakan sistem kecil daripada rangkaian pembekal dan melampirkan cakera anda sebagai peranti tambahan, supaya tiada apa-apa pada cakera anda yang berjalan. Mod penyelamat adalah pilihan terakhir apabila GRUB sendiri rosak, dan ia juga merupakan cara anda menyalin data keluar daripada pelayan yang anda telah putuskan untuk tidak diselamatkan.

Anda biasanya memerlukan tetapan semula keras (hard reset) daripada panel untuk mencapai menu but, kerana anda tidak boleh menjalankan sudo reboot pada mesin yang anda tidak boleh log masuk. Tetapan semula keras adalah sama seperti memotong bekalan kuasa. Sistem fail akan mengalami penutupan yang tidak bersih, jadi jangkakan pemeriksaan sistem fail pada but seterusnya.

Bagaimanakah cara memilih kernel lama dalam menu GRUB?

Perhatikan konsol sebaik sahaja anda menekan butang reset. Tekan Esc berulang kali pada saat-saat awal, atau tahan Shift pada mesin yang but dalam mod legacy BIOS. Tetingkap masa ini sangat singkat, dan pemapar konsol sering mengambil masa sesaat untuk bersambung, jadi mulakan penekanan dengan awal dan teruskan menekan.

Apabila menu muncul, pilih "Advanced options for Ubuntu". Submenu tersebut menyenaraikan setiap kernel yang dipasang, bermula dengan yang paling baharu, berserta entri recovery mode untuk setiap satu. Pilih entri normal kedua, iaitu kernel di bawah yang paling baharu, dan tekan Enter. Recovery mode adalah perkara yang berbeza: ia memulakan sistem pengguna tunggal yang minimum, dan ia bertujuan untuk kerja pembaikan, bukan untuk mengembalikan perkhidmatan anda dalam talian.

Jika kernel lama berjaya but, anda mempunyai pelayan yang berfungsi semula. Sahkan versi yang anda gunakan dan catatkan nombor tersebut.

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

Output dpkg ialah senarai kernel yang dipasang pada sistem anda. Jika ia hanya mengandungi satu baris, anda tidak mempunyai sebarang sandaran (fallback), dan itu adalah perkara pertama yang perlu dibaiki.

Menu GRUB tidak pernah muncul. Apa yang perlu dilakukan?

Imej cloud membekalkan konfigurasi yang menyembunyikan menu tersebut. Imej Ubuntu biasanya menetapkan tempoh masa tamat (timeout) kepada 0 dalam fail di bawah /etc/default/grub.d/, jadi kernel terbaharu akan bermula serta-merta dan tiada apa-apa yang boleh ditekan.

Terdapat juga kes sebaliknya, di mana menu terpapar pada skrin dan menunggu, lalu ia kelihatan seperti sistem tergantung (hang). GRUB merekodkan kegagalan but, dan pada permulaan seterusnya ia boleh menahan menu tersebut terbuka sehingga seseorang menekan kekunci. Pada mesin tanpa papan kekunci, penantian itu tidak akan berakhir. Jika konsol anda menunjukkan menu dan tiada apa-apa yang bergerak, itulah yang telah berlaku. Pilih satu entri dan teruskan.

Selesaikan kedua-dua masalah ini semasa mesin dalam keadaan sihat. Sunting /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 gunakan perubahan tersebut dan pastikan suntingan anda kekal, kerana fail dalam /etc/default/grub.d/ dibaca selepas /etc/default/grub dan boleh mengatasi tetapan anda.

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

GRUB_TERMINAL="console serial" menghantar menu ke konsol grafik dan ke port bersiri, supaya ia muncul dalam mana-mana pemapar yang disediakan oleh panel anda. Argumen kernel console= melakukan perkara yang sama untuk mesej but yang menyusul. Sepuluh saat kelewatan bagi setiap but adalah harga yang murah untuk menu yang boleh anda capai pada pukul 2 pagi.

Kelas kegagalan manakah yang sedang saya hadapi?

Baca dua puluh baris terakhir sebelum konsol berhenti bergerak. Empat corak merangkumi kebanyakan perkara yang berlaku selepas kemas kini kernel.

GRUB tidak dapat mencari failnya sendiri. Anda mendapat prompt grub rescue>, atau ralat mengenai partition atau fail yang tidak wujud, dan tiada mesej kernel muncul. Kernel belum lagi terlibat. Ini berlaku selepas perubahan cakera atau partition, atau bootloader ditulis pada peranti yang salah, bukannya disebabkan oleh pakej kernel itu sendiri.

Kernel bermula tetapi tidak dapat melakukan mount pada root. Mesej kernel dipaparkan, kemudian anda mendarat dalam shell busybox yang prompt-nya berbunyi (initramfs), atau proses boot berakhir dengan panik kerana tidak dapat melakukan mount pada filesystem root. Kernel telah dimuatkan. Initramfs, iaitu root sementara kecil yang mencari dan melakukan mount pada filesystem root sebenar anda, tidak menemui cakera tersebut. Pada Ubuntu, shell ini biasanya didahului oleh mesej tentang kegagalan menunggu peranti root, dan ia menamakan UUID yang dicari. Salin UUID tersebut dan bandingkan dengan output blkid kemudian.

Logical volume tidak pernah muncul. Ini adalah kelas sebelumnya dengan satu punca khusus. Pada prompt (initramfs), jalankan ls /dev/mapper. Jika satu-satunya entri ialah control, maka tiada volume LVM (logical volume manager) diaktifkan, jadi peranti root belum wujud lagi. Aktifkan volume group secara manual:

lvm vgchange -ay
ls /dev/mapper
exit

exit menyerahkan semula kawalan kepada skrip initramfs, yang mencuba semula proses mount. Jika sistem kemudiannya berjaya boot, initramfs baharu kekurangan komponen LVM, dan pembaikannya adalah dengan membina semula imej tersebut dan bukannya menyentuh kernel.

Tiada apa-apa daripada Linux langsung. Konsol menunjukkan teks firmware, shell UEFI (unified extensible firmware interface), skrin kosong tanpa output kernel, atau gelung set semula (reset loop). Kegagalan berlaku sebelum Linux berjalan. Semak mod yang digunakan oleh pelayan anda sebaik sahaja ia kembali aktif, kerana banyak contoh VPS melakukan boot dalam mod legacy BIOS dan tidak pernah menyentuh laluan EFI:

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

/boot/efi yang tidak di-mount semasa naik taraf adalah punca biasa pada mesin UEFI, kerana pakej yang menyelenggara partition sistem EFI kemudiannya menulis ke direktori kosong biasa. Firmware terus memulakan entri boot lama sehingga entri tersebut tidak lagi sepadan dengan apa yang ada pada cakera.

Satu lagi corak bukanlah kegagalan boot sama sekali. Jika anda mencapai shell root yang menyatakan sistem berada dalam mod kecemasan (emergency mode), kernel telah boot dan userspace terhenti. Ini biasanya bermakna terdapat baris yang salah dalam /etc/fstab atau filesystem yang gagal dalam semakannya. Jalankan journalctl -xb dalam shell tersebut dan baca nama unit yang gagal.

Adakah pakej kernel yang rosak, atau initramfs?

Kedua-duanya kelihatan sama daripada konsol dan memerlukan pembaikan yang berbeza. But kernel lama, kemudian bandingkan fail-fail tersebut.

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

Anda perlukan satu vmlinuz- dan satu initrd.img- yang sepadan bagi setiap versi yang dipasang, dengan saiz yang munasabah bagi setiap satunya. Initrd yang hilang, atau yang jauh lebih kecil daripada fail jiran, bermakna penjanaan initramfs telah gagal. Sebab yang biasa ialah /boot yang penuh, dan bukti tersebut terdapat dalam log pakej:

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

history.log juga menyenaraikan dengan tepat pakej yang dipasang pada larian terakhir dan masanya, yang menyelesaikan sebarang pertikaian tentang perkara yang telah berubah.

Kosongkan ruang terlebih dahulu jika /boot penuh, kemudian bina semula imej untuk versi yang anda perlukan dan segarkan menu. Ambil rentetan versi daripada output ls anda sendiri, kerana pemegang tempat di bawah bukanlah keluaran sebenar:

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

ls terakhir itu ialah semakan. Fail dengan saiz biasa bermakna imej tersebut kini sudah ada. Jika sebaliknya imej kernel itu sendiri yang rosak, atau dpkg -l menunjukkan pakej dalam sebarang status selain ii, pasang semula pakej tersebut:

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

Membaiki sistem daripada mod penyelamat apabila tiada kernel yang boleh but

Jika setiap entri dalam menu gagal, but imej penyelamat pembekal anda dan baiki cakera dari luar. Cakera anda akan muncul sebagai peranti yang tidak dilekap (unmounted), jadi tiada apa-apa di dalamnya yang sedang berjalan dan tiada proses yang akan menghalang anda.

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 baharu tanpa menjejaskan but seterusnya

GRUB boleh memulakan satu entri untuk sekali sahaja dan kemudian kembali kepada lalai yang anda pilih. Tetapkan lalai kepada kernel yang anda percayai, kemudian lancarkan kernel baharu untuk satu sesi but sahaja. Jika ia gagal, tetapan semula keras (hard reset) daripada panel kawalan akan mengembalikan anda kepada kernel yang berfungsi tanpa perlu mengejar masa pada konsol.

Tetapkan GRUB_DEFAULT=saved dalam /etc/default/grub, jalankan sudo update-grub, kemudian senaraikan tajuk entri supaya anda boleh menamakan satu daripadanya dengan 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 sepatutnya mencetak tajuk pilihan anda sebagai saved_entry. Output tersebut adalah bukti bahawa mekanisme ini berfungsi, kerana penyimpanan memerlukan /boot/grub/grubenv yang boleh ditulis, dan pada sesetengah susun atur, ia gagal dilakukan secara senyap. Entri 0 ialah bahagian atas menu, iaitu kernel yang paling baharu. Tajuk adalah lebih selamat daripada nombor di sini, kerana nombor berubah setiap kali kernel dipasang atau dibuang.

Mengapa autoremove berisiko pada pelayan tanpa kepala

APT menyimpan senarai pakej kernel yang tidak boleh dibuang secara automatik. Semak senarai anda:

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

Fail tersebut dijana semula setiap kali pakej kernel berubah, dan ia melindungi kernel yang sedang berjalan serta kernel yang paling baharu. Perangkapnya terletak pada masa. Jalankan sudo apt autoremove --purge sejurus selepas but semula ke dalam kernel baharu, dan senarai yang dilindungi telah pun dikemas kini, jadi kernel lama yang anda harapkan tidak lagi dilindungi. Pada mesin yang mempunyai papan kekunci, ini hanyalah satu kesulitan. Pada pelayan tanpa kepala, ia adalah perbezaan antara memilih menu but dan perlu melekapkan cakera anda daripada imej penyelamat.

Kekalkan dua kernel sebagai jumlah minimum, dan tiga jika /boot mempunyai ruang yang mencukupi. Buang kernel lama mengikut nama selepas menyemak uname -r, supaya anda tidak akan memadam kernel yang sedang berjalan:

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

Jalankan arahan terakhir itu sekali lagi selepas itu. Jika jumlah berkurang daripada tiga kepada dua, itu adalah pembersihan yang betul. Jika jumlah berkurang kepada satu, itu adalah gangguan perkhidmatan yang bakal berlaku pada but semula yang seterusnya.

Ambil syot kilas sebelum naik taraf

Syot kilas yang diambil sebelum apt upgrade merupakan satu-satunya laluan pemulihan yang tidak bergantung pada proses but semula. Memulihkannya akan mengembalikan cakera kepada keadaan asal di mana kernel lama menjadi lalai, dan anda boleh mencuba semula naik taraf dengan konsol yang sudah dibuka. Syot kilas mesin yang sedang berjalan adalah crash consistent, bermakna ia merakam cakera seolah-olah bekalan kuasa terputus, jadi matikan pelayan terlebih dahulu jika pembekal anda menyokong syot kilas luar talian. Syot kilas juga bukan sandaran, kerana ia biasanya disimpan pada infrastruktur yang sama dengan volum yang disalin. Memahami perbezaan antara syot kilas VPS dan sandaran sebenar menentukan yang mana satu akan menyelamatkan anda apabila kegagalan berlaku lebih besar daripada sekadar isu kernel.

Perkara ini paling penting semasa naik taraf keluaran, di mana kernel, alatan initramfs, pemuat but, dan konfigurasi GRUB semuanya berubah dalam satu proses. Ambil syot kilas sejurus sebelum anda memulakan naik taraf Ubuntu 24.04 ke 26.04, bukan pada malam sebelumnya, supaya titik pemulihan sepadan dengan mesin yang bakal anda ubah.

Bagaimana unattended-upgrades mengendalikan pakej kernel

Perisian unattended-upgrades pada Ubuntu memasang kemas kini keselamatan secara automatik, dan pakej kernel tiba melalui repositori keselamatan seperti pakej lain. Terdapat dua kesan yang berlaku.

Pertama, kernel baharu dipasang tetapi tidak berjalan. Kernel hanya berkuat kuasa semasa but. Fail /var/run/reboot-required akan muncul, dan /var/run/reboot-required.pkgs menyatakan punca yang meminta but semula, namun tiada apa-apa yang akan dimulakan semula melainkan anda mendayakan Unattended-Upgrade::Automatic-Reboot dalam /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, jurang masa tersebut menyembunyikan puncanya. Sebuah pelayan boleh memasang kernel pada bulan Mac dan but semula pada bulan Jun atas sebab yang tidak berkaitan, kemudian gagal untuk hidup semula. Perubahan yang menyebabkan kegagalan but itu sudah berusia tiga bulan, jadi tiada tindakan anda pada hari tersebut yang dapat menjelaskannya. /var/log/apt/history.log ialah tempat anda mencari sesi yang memasang kernel yang menyebabkan kegagalan anda sekarang.

Lakukan but semula secara sengaja, pada hari yang anda pilih, dengan tetingkap konsol sudah dibuka. Tabiat tunggal itu mengubah gangguan misteri menjadi pemilihan menu selama dua minit. Jika anda mahukan automasi tanpa kejutan, kekalkan pemasangan automatik tetapi matikan but semula automatik, dan lihat cara mengkonfigurasi unattended-upgrades pada Ubuntu untuk tetapan yang tepat. Menahan pakej kernel dengan sudo apt-mark hold linux-image-generic akan menghentikannya sepenuhnya, dan ia juga menghentikan pembetulan keselamatan kernel pada masa yang sama, jadi anggaplah itu sebagai pertukaran yang anda putuskan untuk buat dan bukannya sebagai langkah keselamatan.

FAQ

Bagaimanakah cara untuk memulakan kernel lama pada VPS tanpa papan kekunci?

Buka konsol pembekal (VNC atau serial) dan lakukan hard reset daripada panel kawalan, kerana anda tidak boleh log masuk untuk melakukan but semula secara bersih. Apabila mesin dimulakan semula, tekan Esc berulang kali, atau tahan Shift pada but BIOS legasi, untuk menahan menu GRUB. Pilih "Advanced options for Ubuntu" dan pilih entri di bawah kernel yang paling baharu. Sebaik sahaja anda mendapat prompt log masuk, jalankan uname -r untuk mengesahkan kernel yang sedang digunakan dan dpkg -l 'linux-image-*' untuk melihat apa lagi yang dipasang. Lakukan diagnosis hanya selepas sistem berjalan semula.

Mengapakah VPS saya tidak memaparkan menu GRUB langsung?

Imej awan biasanya menetapkan timeout GRUB kepada 0 dalam fail di bawah /etc/default/grub.d/, jadi kernel paling baharu bermula tanpa sebarang pilihan untuk ditekan. Tetapkan GRUB_TIMEOUT=10 dan GRUB_TIMEOUT_STYLE=menu dalam /etc/default/grub, tambah GRUB_TERMINAL="console serial" supaya menu juga mencapai konsol serial, kemudian jalankan sudo update-grub. Sahkan dengan grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, kerana fail dalam direktori tersebut dibaca selepas fail utama dan boleh mengatasi suntingan anda.

Patutkah saya membuang kernel lama untuk mengosongkan ruang dalam /boot?

Buang kernel yang paling lama dan simpan sekurang-kurangnya dua. /boot yang penuh merupakan mod kegagalan tersendiri, kerana penjanaan initramfs akan gagal dan anda akan ditinggalkan dengan kernel yang tidak mempunyai imej berfungsi. Buang dengan nama pakej yang tepat selepas menyemak uname -r, supaya kernel yang sedang berjalan tidak menjadi calon untuk dibuang. Elakkan penggunaan sudo apt autoremove --purge secara menyeluruh pada mesin tanpa kepala (headless), memandangkan senarai kernel yang dilindungi dijana semula pada setiap perubahan kernel dan pelaksanaan yang tidak tepat masanya boleh menyebabkan anda hanya mempunyai satu kernel tanpa entri sandaran dalam menu.

Bolehkah unattended-upgrades merosakkan proses but saya?

Ia boleh memasang kernel yang kemudiannya gagal untuk but, tetapi ia tidak memulakan semula mesin melainkan Unattended-Upgrade::Automatic-Reboot ditetapkan kepada true dalam /etc/apt/apt.conf.d/50unattended-upgrades. Corak yang biasa berlaku ialah kegagalan tertunda: kernel dipasang semasa proses automatik, /var/run/reboot-required muncul, dan masalah hanya timbul pada but semula anda yang seterusnya beberapa minggu kemudian. Lakukan but semula secara sengaja dengan konsol sudah dibuka, dan baca /var/log/apt/history.log untuk mencari proses yang memasang kernel yang sedang anda gunakan.