VPS Hindi Nagbo-boot Matapos ang Kernel Update

Ano ang unang gagawin kapag hindi nag-boot ang VPS matapos ang kernel update

Karaniwang nare-recover sa loob ng ilang minuto ang VPS na hindi nag-boot matapos ang kernel update, dahil hindi naman karaniwang dine-delete ng update ang kernel na gumana kahapon. Nag-i-install ang Ubuntu ng bagong kernel kasabay ng luma at binabago lamang kung aling entry ang awtomatikong sisimulan ng GRUB. Kaya hindi repair ang unang hakbang. Piliin ang naunang kernel sa boot menu, ibalik ang login prompt, at saka mag-diagnose mula sa tumatakbong system.

Iba ang pag-aayos nito sa server kumpara sa laptop dahil walang nakakabit na keyboard at walang monitor na nagpapakita ng panic. Hindi rin sasagot ang SSH dahil hindi pa umabot ang machine sa puntong nagsisimula ang sshd. Lahat ng nasa ibaba ay isinasagawa sa console ng iyong provider.

Basahin muna ang sarili mong console bago magbago ng anuman. Ang text sa screen na iyon ang magpapakita kung anong failure class ang kinakaharap mo, at ang dalawang server na parehong “hindi nag-boot” ay maaaring mangailangan ng magkasalungat na fix.

Paano ko maa-access ang console kapag hindi gumagana ang SSH?

Buksan ang control panel ng provider mo at hanapin ang console. Karaniwang tawag dito ang VNC console, web console, noVNC, at serial console. Piliin ang serial console kapag parehong available, dahil nagbibigay ito ng aktuwal na text na maaari mong i-scroll at kopyahin, samantalang larawan lang ng screen ang ipinapakita ng VNC. Hanapin at subukan ang control na ito habang maayos pa ang machine. Kapag outage na, nakakaubos ng oras ang paghahanap dito at nawawala ang kalmadong kailangan mo. Dapat kasama ang pagsusuring ito sa unang sampung minuto sa bagong VPS, kasama ng firewall rules at SSH keys.

Karamihan sa mga panel ay may rescue mode o recovery image. Nagbo-boot ito ng maliit na system mula sa network ng provider at ikinakabit ang disk mo bilang karagdagang device, kaya walang tumatakbo mula sa disk mo. Ang rescue mode ang fallback kapag sira mismo ang GRUB. Ginagamit din ito para makopya ang data mula sa server na napagpasyahan mong hindi na i-save.

Karaniwan, kailangan mong magsagawa ng hard reset mula sa panel para ma-access ang boot menu, dahil hindi mo maaaring patakbuhin ang sudo reboot sa machine na hindi mo ma-log in. Katumbas ng hard reset ang pagputol ng power. Magkakaroon ng unclean shutdown ang filesystems, kaya asahan ang filesystem check sa susunod na boot.

Paano pumili ng mas lumang kernel sa GRUB menu?

Subaybayan ang console mula sa sandaling pindutin mo ang reset. Paulit-ulit na pindutin ang Esc sa mga unang segundo, o pindutin nang matagal ang Shift sa machine na nagbo-boot sa legacy BIOS mode. Maikli ang window, at madalas ay nangangailangan ng isang segundo ang console viewer para kumonekta, kaya magsimulang pumindot nang maaga at ipagpatuloy ang pagpindot.

Kapag lumitaw ang menu, piliin ang "Advanced options for Ubuntu". Nasa submenu na iyon ang lahat ng naka-install na kernel, mula sa pinakabago, kasama ang isang recovery mode entry para sa bawat isa. Piliin ang ikalawang normal na entry, ang kernel na nasa ibaba ng pinakabago, at pindutin ang Enter. Iba ang recovery mode: nagbo-boot ito sa isang minimal na single user system at ginagamit para sa repair work, hindi para maibalik online ang iyong mga service.

Kung nag-boot ang mas lumang kernel, mayroon ka nang gumaganang server. Tiyakin kung aling kernel ang ginagamit at itala ang mga numero.

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

Ang output ng dpkg ang listahan ng mga naka-install na kernel. Kung isang linya lamang ang laman nito, wala kang fallback at iyon ang unang kailangang ayusin.

Hindi lumalabas ang GRUB menu. Ano ang gagawin?

May configuration ang cloud images na nagtatago sa menu. Karaniwang itinatakda ng Ubuntu images sa 0 ang timeout sa isang file sa ilalim ng /etc/default/grub.d/, kaya agad nagsisimula ang pinakabagong kernel at walang kailangang pindutin.

May kabaligtarang sitwasyon kung saan nasa screen ang menu at naghihintay, kaya mukhang nag-hang ang system. Itinatala ng GRUB ang failed boot, at sa susunod na pagsisimula ay maaaring panatilihing bukas ang menu hanggang may pumindot ng key. Sa machine na walang keyboard, hindi matatapos ang paghihintay. Kung may menu na ipinapakita ang console mo pero walang gumagalaw, iyon ang nangyari. Pumili ng entry at magpatuloy.

Ayusin ang dalawang sitwasyon habang maayos ang machine. I-edit ang /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"

Pagkatapos, ilapat ang pagbabago at tingnan kung nanatili ito, dahil binabasa ang mga file sa /etc/default/grub.d/ pagkatapos ng /etc/default/grub at maaari nilang ma-override ang ginawa mo.

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

Ipinapadala ng GRUB_TERMINAL="console serial" ang menu sa graphical console at sa serial port, kaya lumalabas ito sa alinmang viewer ang ibigay ng panel mo. Ginagawa rin iyon ng console= kernel arguments para sa mga boot message na kasunod. Murang kapalit ang 10 segundong delay sa bawat boot para sa menu na maa-access mo talaga kapag 2am.

Anong uri ng failure ang nakikita ko?

Basahin ang huling twenty lines bago tumigil ang galaw ng console. Karamihan ng nangyayari pagkatapos ng kernel update ay pasok sa apat na pattern.

Hindi mahanap ng GRUB ang sarili nitong files. Makakakita ka ng grub rescue> prompt, o error tungkol sa partition o file na hindi umiiral, at walang lalabas na kernel message. Hindi pa kasali ang kernel sa puntong ito. Karaniwang nangyayari ito pagkatapos baguhin ang disk o partition, o kapag sa maling device naisulat ang bootloader, hindi dahil sa kernel package lamang.

Nagsisimula ang kernel pero hindi ma-mount ang root. Mag-i-scroll ang kernel messages, pagkatapos ay mapupunta ka sa busybox shell na may (initramfs) prompt, o matatapos ang boot sa panic tungkol sa hindi ma-mount na root filesystem. Na-load ang kernel. Hindi nahanap ng initramfs, ang maliit na pansamantalang root filesystem na naghahanap at nag-mount sa aktuwal na root filesystem, ang disk. Sa Ubuntu, karaniwang may mensahe muna ang shell na ito tungkol sa pagsuko sa paghihintay sa root device, at nakasaad dito ang UUID na hinahanap nito. Kopyahin ang UUID na iyon at ihambing sa output ng blkid mamaya.

Hindi lumilitaw ang logical volume. Ang naunang class ito na may isang partikular na sanhi. Sa (initramfs) prompt, patakbuhin ang ls /dev/mapper. Kung control lamang ang entry, walang na-activate na LVM (logical volume manager) volume, kaya hindi pa umiiral ang root device. Manu-manong i-activate ang volume groups:

lvm vgchange -ay
ls /dev/mapper
exit

Ibinabalik ng exit ang control sa initramfs script, na muling susubok na mag-mount. Kung magbo-boot ang system pagkatapos nito, kulang ang bagong initramfs ng mga LVM component, kaya kailangang i-rebuild ang image na iyon sa halip na galawin ang kernel.

Walang Linux output. Maaaring firmware text, UEFI (unified extensible firmware interface) shell, blangkong screen na walang kernel output, o paulit-ulit na reset loop ang makita sa console. Nangyayari ang failure bago patakbuhin ang Linux. Kapag nakabalik ka na sa system, tingnan kung aling mode ang aktuwal na ginagamit ng server, dahil maraming VPS instance ang nagbo-boot sa legacy BIOS mode at hindi kailanman dumadaan sa EFI path:

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

Karaniwang sanhi sa mga UEFI machine ang hindi naka-mount na /boot/efi habang nag-a-upgrade, dahil sa ordinaryong walang lamang directory naisusulat ng mga package na nagma-maintain sa EFI system partition. Patuloy na sinisimulan ng firmware ang lumang boot entry hanggang sa hindi na ito tumugma sa nasa disk.

May isa pang pattern na hindi talaga boot failure. Kung makakarating ka sa root shell na nagsasabing nasa emergency mode ang system, nag-boot ang kernel at huminto ang userspace. Karaniwang sanhi nito ang maling line sa /etc/fstab o filesystem na hindi pumasa sa check. Patakbuhin ang journalctl -xb sa shell na iyon at basahin ang pangalan ng unit na nag-fail.

Sira ba ang kernel package, o ang initramfs?

Magkapareho ang hitsura ng dalawang problemang ito sa console, pero magkaiba ang kinakailangang repair. I-boot ang lumang kernel, pagkatapos ay ikumpara ang mga file.

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

Dapat may isang vmlinuz- at isang katugmang initrd.img- para sa bawat naka-install na bersyon, at dapat kapani-paniwala ang laki ng bawat isa. Kapag nawawala ang initrd, o mas maliit ito nang malaki kaysa sa mga katabi nito, nabigo ang pagbuo ng initramfs. Karaniwang sanhi nito ang punô na /boot, at nasa package logs ang ebidensiya:

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

Eksaktong inililista rin ng history.log kung aling mga package ang na-install sa mga huling run at kung kailan, kaya malulutas nito ang anumang pagtatalo tungkol sa mga nabago.

Magbakante muna ng espasyo kung punô ang /boot, pagkatapos ay buuin muli ang image para sa bersyong kailangan mo at i-refresh ang menu. Kunin ang version string mula sa sarili mong output ng ls, dahil hindi totoong release ang placeholder sa ibaba:

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

Ang huling ls ang magsisilbing pagsusuri. Kapag normal ang laki ng file, nangangahulugang naroon na ang image. Kung sira naman ang kernel image mismo, o ipinapakita ng dpkg -l ang package sa anumang state maliban sa ii, i-reinstall ang package:

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

Pag-aayos mula sa rescue mode kapag walang kernel na nagbo-boot

Kung nabibigo ang bawat entry sa menu, i-boot ang rescue image ng provider at ayusin ang disk mula sa labas. Lalabas ang disk bilang isang hindi naka-mount na device, kaya walang tumatakbo rito at walang prosesong makikialam sa pag-aayos.

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

Subukan ang bagong kernel nang hindi isinasapalaran ang susunod na boot

Maaaring simulan ng GRUB ang isang entry nang isang beses at pagkatapos ay bumalik sa napili mong default. Ituro ang default sa isang kernel na pinagkakatiwalaan mo, pagkatapos ay ilunsad ang bago para sa isang boot lamang. Kung mabigo ito, ibabalik ka ng hard reset mula sa panel sa gumaganang kernel nang hindi kailangang itama ang timing sa console.

Itakda ang GRUB_DEFAULT=saved sa /etc/default/grub, patakbuhin ang sudo update-grub, pagkatapos ay ilista ang mga pamagat ng entry upang eksaktong mapangalanan ang isa:

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

Dapat i-print ng grub-editenv list ang napili mong pamagat bilang saved_entry. Patunay ang output na iyon na gumagana ang mekanismo, dahil kailangan ng pag-save ang isang /boot/grub/grubenv na writable, at sa ilang layout ay hindi ito tahasang ipinapakita. Ang Entry 0 ang nasa itaas ng menu, at ito ang pinakabagong kernel. Mas ligtas gamitin dito ang mga pamagat kaysa mga numero, dahil nagbabago ang mga numero sa tuwing may ini-install o inaalis na kernel.

Bakit mapanganib ang autoremove sa isang headless box

May listahan ang APT ng mga kernel package na hindi nito dapat awtomatikong alisin. Basahin ang iyo:

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

Nire-regenerate ang file na iyon kapag nagbabago ang mga kernel package. Pinoprotektahan nito ang kasalukuyang kernel at ang mga pinakabago. Ang panganib ay nasa timing. Patakbuhin ang sudo apt autoremove --purge kaagad pagkatapos mag-reboot sa bagong kernel, at na-update na ang protected list. Dahil dito, hindi na protected ang mas lumang kernel na inaasahan mong gagamitin. Sa machine na may keyboard, abala lamang ito. Sa headless server, ito ang pagkakaiba sa pagitan ng pagpili ng menu entry at pag-mount ng disk mula sa rescue image.

Panatilihin ang dalawang kernel bilang minimum. Panatilihin ang tatlo kapag may sapat na puwang ang /boot. Alisin ang mga lumang kernel ayon sa pangalan pagkatapos suriin ang uname -r, para hindi mo kailanman matanggal ang kernel na kasalukuyan mong ginagamit:

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

Patakbuhin muli ang huling command pagkatapos nito. Ang pagbaba ng bilang mula tatlo tungo sa dalawa ay cleanup. Ang pagbaba nito tungo sa isa ay outage na naghihintay sa susunod na reboot.

Kumuha ng snapshot bago ang upgrade

Ang snapshot na kinuha bago ang apt upgrade ang tanging recovery path na hindi nakadepende sa pag-boot ng anuman. Kapag ibinalik mo ito, maibabalik ang disk sa kalagayan kung saan default ang lumang kernel, at maaari mong ulitin ang upgrade habang bukas na ang console. Crash consistent ang snapshot ng tumatakbong machine. Ibig sabihin, kinukuha nito ang disk na parang pinutol ang power. Kaya i-shut down muna ang server kung sinusuportahan ng provider mo ang offline snapshot. Hindi rin backup ang snapshot, dahil karaniwan itong nasa parehong infrastructure ng volume na kinopyahan nito. Ang pag-unawa sa pagkakaiba ng VPS snapshots at mga totoong backup ang magpapasya kung alin ang makapagliligtas sa iyo kapag mas malaki sa kernel ang failure.

Pinakamahalaga ito sa release upgrade, kung saan sabay na nagbabago ang kernel, initramfs tools, bootloader, at GRUB config sa isang run. Kunin ang snapshot kaagad bago mo simulan ang upgrade mula Ubuntu 24.04 papuntang 26.04, hindi noong gabi bago iyon, upang tumugma ang restore point sa machine na babaguhin mo. Kung hindi pa iniaalok ang upgrade na iyon sa server mo, scheduling ang sanhi at hindi sirang setup, dahil nagbubukas lamang ang pagtalon mula LTS papuntang LTS sa unang point release, 26.04.1.

Paano tinatrato ng unattended-upgrades ang mga kernel package

Ini-install ng unattended-upgrades ng Ubuntu ang mga security update nang hindi nagtatanong, at dumarating ang mga kernel package sa security pocket tulad ng iba pang package. Dalawang epekto ang kasunod nito.

Una, naka-install ang bagong kernel pero hindi ito ang kasalukuyang tumatakbo. Nagkakabisa lamang ang kernel kapag nag-boot. Lumilitaw ang file na /var/run/reboot-required, at ipinapakita ng /var/run/reboot-required.pkgs kung ano ang humiling ng reboot, pero walang magre-restart maliban kung na-enable mo ang Unattended-Upgrade::Automatic-Reboot sa /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

Ikalawa, itinatago ng agwat na ito ang sanhi. Maaaring mag-install ang isang server ng kernel noong March at mag-reboot noong June dahil sa ganap na ibang dahilan, saka hindi na muling makapag-boot nang maayos. Tatlong buwan na ang nakalipas nang mangyari ang pagbabagong sumira sa boot, kaya walang ginawa noong araw na iyon ang malinaw na makapagpapaliwanag dito. Sa /var/log/apt/history.log mo makikita ang run na nag-install ng kernel na kasalukuyan mong hindi mapatakbo.

Mag-reboot nang sadya sa araw na pinili mo, habang nakabukas na ang console window. Dahil sa simpleng gawi na ito, nagiging dalawang minutong pagpili sa menu ang dating misteryosong outage. Kung gusto mo ang automation pero ayaw mo ng hindi inaasahang reboot, panatilihing naka-enable ang automatic installs at naka-disable ang automatic reboots. Tingnan ang kung paano i-configure ang unattended-upgrades sa Ubuntu para sa eksaktong settings. Kapag pinigil ang mga kernel package gamit ang sudo apt-mark hold linux-image-generic, tuluyan silang hindi mai-install. Kasabay nito, mapipigilan din ang mga kernel security fix, kaya ituring ito bilang isang trade-off na sinadya mong piliin, hindi bilang safety measure.

FAQ

Paano ako magbo-boot gamit ang mas lumang kernel sa VPS na walang keyboard?

Buksan ang console ng provider, VNC man ito o serial, at mag-trigger ng hard reset mula sa control panel dahil hindi ka makakapag-log in para magsagawa ng maayos na reboot. Habang nagre-restart ang machine, paulit-ulit na pindutin ang Esc, o hawakan ang Shift kung legacy BIOS boot, upang manatiling bukas ang GRUB menu. Piliin ang "Advanced options for Ubuntu" at ang entry sa ibaba ng pinakabagong kernel. Kapag lumabas na ang login prompt, patakbuhin ang uname -r upang kumpirmahin kung aling kernel ang ginagamit at ang dpkg -l 'linux-image-*' upang makita kung ano pa ang naka-install. Magsagawa lamang ng diagnosis kapag tumatakbo na muli ang system.

Bakit walang lumalabas na GRUB menu sa VPS ko?

Karaniwang itinatakda ng cloud image ang GRUB timeout sa 0 sa isang file sa ilalim ng /etc/default/grub.d/, kaya direktang nagsisimula ang pinakabagong kernel nang walang hinihintay na input. Itakda ang GRUB_TIMEOUT=10 at GRUB_TIMEOUT_STYLE=menu sa /etc/default/grub, idagdag ang GRUB_TERMINAL="console serial" upang lumabas din ang menu sa serial console, at patakbuhin ang sudo update-grub. I-verify gamit ang grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, dahil binabasa ang mga file sa directory na iyon pagkatapos ng pangunahing file at maaaring ma-override ng mga ito ang iyong edit.

Dapat ko bang alisin ang mga lumang kernel para lumuwag ang espasyo sa /boot?

Alisin ang mga pinakaluma at mag-iwan ng hindi bababa sa dalawa. Ang puno nang /boot ay hiwalay na failure mode dahil mabibigo ang pag-generate ng initramfs at maiiwan ka sa kernel na walang gumaganang image. Mag-purge ayon sa eksaktong package name pagkatapos suriin ang uname -r, upang hindi mapasama ang kasalukuyang ginagamit na kernel. Iwasan ang blanket sudo apt autoremove --purge sa headless machine, dahil nire-regenerate ang protected-kernel list sa bawat pagbabago ng kernel at maaaring maiwan ka ng isang kernel lamang at walang fallback entry sa menu kapag hindi tama ang timing ng pagpapatakbo.

Maaari bang masira ng unattended-upgrades ang boot ko?

Maaari itong mag-install ng kernel na hindi makapag-boot sa susunod, pero hindi nito ire-restart ang machine maliban kung nakatakda sa true ang Unattended-Upgrade::Automatic-Reboot sa /etc/apt/apt.conf.d/50unattended-upgrades. Karaniwang delayed failure ang nangyayari: nai-install ang kernel sa isang automatic run, lumilitaw ang /var/run/reboot-required, at mapapansin lamang ang problema sa susunod mong reboot makalipas ang ilang linggo. Mag-reboot nang planado habang bukas na ang console, at basahin ang /var/log/apt/history.log upang malaman kung aling run ang nag-install ng kernel na bina-boot mo.