VPS Hindi Nag-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 binura ng update ang kernel na gumana kahapon. Nag-i-install ang Ubuntu ng bagong kernel kasabay ng lumang kernel at binabago lamang kung aling entry ang default na sinisimulan ng GRUB. Kaya ang unang hakbang ay hindi repair. 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 kailanman umabot ang machine sa puntong nagsisimula ang sshd. Lahat ng nasa ibaba ay ginagawa sa pamamagitan ng console ng provider mo.

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

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

Buksan ang control panel ng provider mo at hanapin ang console. Ang mga karaniwang pangalan nito ay VNC console, web console, noVNC, at serial console. Piliin ang serial console kapag parehong available ang mga ito, dahil nagbibigay ito ng totoong text na maaari mong i-scroll at kopyahin, samantalang larawan lamang ng screen ang ipinapakita ng VNC view. Hanapin ang control na ito ngayon, habang maayos pa ang machine, at tiyaking nagbubukas ito. Kapag outage na, mahirap itong hanapin at mababawasan ang oras mo para maayos ang problema. Dapat kasama ang pagsusuring ito sa unang sampung minuto sa bagong VPS, kasabay 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. Ito rin ang ginagamit para mag-copy ng data mula sa server na napagpasyahan mong hindi na i-save.

Karaniwan, kailangan mo ng hard reset mula sa panel para maabot ang boot menu, dahil hindi mo maaaring patakbuhin ang sudo reboot sa machine na hindi mo ma-log in. Ang hard reset ay katumbas ng 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?

Bantayan ang console mula sa sandaling pindutin mo ang reset. Pindutin nang paulit-ulit ang Esc sa mga unang segundo, o pindutin nang matagal ang Shift sa machine na nagbo-boot sa legacy BIOS mode. Maikli ang window na ito, at kadalasang nangangailangan ng isang segundo para makakonekta ang console viewer, kaya simulan nang maaga ang pagpindot at ipagpatuloy ito.

Kapag lumitaw ang menu, piliin ang "Advanced options for Ubuntu". Ipinapakita ng 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. Ibang bagay ang recovery mode: nagbo-boot ito sa isang minimal na single user system, at para ito sa repair work, hindi para maibalik online ang iyong mga serbisyo.

Kung nag-boot ang mas lumang kernel, mayroon ka nang tumatakbong server. Kumpirmahin 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 dapat ayusin.

Hindi lumalabas ang GRUB menu. Ano ang dapat gawin?

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

May kabaligtarang sitwasyon din: 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 na iyon. Kung may menu sa console mo pero walang gumagalaw, iyon ang nangyari. Pumili ng entry at magpatuloy.

Ayusin ang dalawang sitwasyon habang maayos pa 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, i-apply ang pagbabago at tiyaking 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 serial port, kaya lalabas ito sa alinmang viewer na ibinibigay ng panel mo. Ginagawa rin ng console= kernel arguments ang parehong bagay para sa mga boot message na kasunod. Makatuwirang kapalit ang sampung segundong delay sa bawat boot para sa menu na maa-access mo talaga sa ganap na 2am.

Anong klaseng failure ito?

Basahin ang huling 20 linya bago tumigil sa paggalaw ang console. Apat na pattern ang sumasaklaw sa karamihan ng nangyayari matapos ang kernel update.

Hindi makita 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 matapos baguhin ang disk o partition, o kapag naisulat ang bootloader sa maling device, hindi dahil sa kernel package lamang.

Nagsimula ang kernel pero hindi ma-mount ang root. Mag-i-scroll ang mga kernel message, pagkatapos ay mapupunta ka sa busybox shell na ang prompt ay (initramfs), o magtatapos ang boot sa panic tungkol sa hindi ma-mount na root filesystem. Na-load ang kernel. Hindi nakita ng initramfs, ang maliit na pansamantalang root na naghahanap at nagmo-mount ng aktuwal na root filesystem, ang disk. Sa Ubuntu, karaniwang nauuna sa shell na ito ang mensaheng nagsasabing sumuko na ito sa paghihintay sa root device, at nakalagay doon ang UUID na hinahanap nito. Kopyahin ang UUID na iyon at ihambing sa output ng blkid sa susunod.

Hindi lumilitaw ang logical volume. Ang klase ito ng nakaraang problema 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. I-activate nang mano-mano 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, at ang dapat ay i-rebuild ang image na iyon, hindi galawin ang kernel.

Walang anumang galing sa Linux. Makikita sa console ang firmware text, isang UEFI (unified extensible firmware interface) shell, blankong screen na walang kernel output, o paulit-ulit na reset. Nangyayari ang failure bago tumakbo ang Linux. Suriin kung anong mode ang aktuwal na ginagamit ng server kapag nakabalik ka na, 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-u-upgrade, dahil sa halip na doon magsulat ang mga package na nagma-maintain ng EFI system partition, sa ordinaryong empty directory sila nagsulat. Patuloy na sinisimulan ng firmware ang lumang boot entry hanggang sa hindi na tumugma ang entry na iyon 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 linya sa /etc/fstab o filesystem na bumagsak 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 ito mula sa console, pero magkaiba ang kinakailangang repair. Mag-boot gamit 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 version, 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 pag-generate ng initramfs. Karaniwang dahilan ang punong /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 ng mga huling run at kung kailan, kaya malulutas nito ang anumang pagtatalo tungkol sa mga nabago.

Magbakante muna ng space kung puno ang /boot, pagkatapos ay i-rebuild ang image para sa kinakailangang version 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 pagsusuri. Ibig sabihin ng file na may normal na laki na naroon na ang image. Kung sira naman mismo ang kernel image, 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 nagfa-fail ang bawat entry sa menu, i-boot ang rescue image ng provider at ayusin ang disk mula sa labas. Lalabas ang disk bilang isang unmounted device, kaya walang tumatakbo mula 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 isinusugal ang susunod na boot

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

Itakda ang GRUB_DEFAULT=saved sa /etc/default/grub, patakbuhin ang sudo update-grub, pagkatapos ay ilista ang mga entry title para eksaktong matukoy 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 title bilang saved_entry. Patunay iyon na gumagana ang mekanismo, dahil kailangan ng pag-save ang isang writable na /boot/grub/grubenv, at sa ilang layout ay hindi ito tahasang ipinapakita. Ang Entry 0 ang nasa pinakataas ng menu, at iyon ang pinakabagong kernel. Mas ligtas gamitin dito ang mga title kaysa sa mga numero, dahil nagbabago ang mga numero sa tuwing may ini-install o inaalis na kernel.

Bakit delikado ang autoremove sa headless server

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

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 pinakabagong kernel. Ang panganib ay nasa timing. Patakbuhin ang sudo apt autoremove --purge kaagad pagkatapos mag-reboot gamit ang bagong kernel. Sa puntong iyon, na-update na ang protected list, kaya hindi na protected ang mas lumang kernel na inaasahan mong gagamitin. Sa machine na may keyboard, abala lang ito. Sa headless server, ito ang pagkakaiba ng pagpili ng menu entry at pag-mount ng disk mula sa rescue image.

Panatilihin ang hindi bababa sa dalawang kernel. Panatilihin ang tatlo kapag may sapat na espasyo ang /boot. Alisin ang mga lumang kernel ayon sa pangalan pagkatapos suriin ang uname -r. Sa ganitong paraan, hindi mo matatanggal 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 pagkatapos ang huling command. Kapag bumaba ang bilang mula tatlo tungo sa dalawa, cleanup lang ito. Kapag bumaba ito sa isa, outage iyon 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 anumang bagay. Kapag ni-restore ito, ibinabalik ang disk sa state kung saan ang lumang kernel ang default, at maaari mong ulitin ang upgrade habang bukas na ang console. Ang snapshot ng tumatakbong machine ay crash consistent. Ibig sabihin, nakukuha nito ang disk na parang pinutol ang power. Kaya i-shutdown muna ang server kapag 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 aktuwal na backups ang magpapasya kung alin ang sasagip sa iyo kapag mas malaki sa kernel ang failure.

Pinakamahalaga ito sa isang release upgrade, kung saan sabay na nagbabago ang kernel, initramfs tools, bootloader, at GRUB config. Kunin ang snapshot kaagad bago mo simulan ang upgrade mula Ubuntu 24.04 patungong 26.04, hindi noong gabi bago iyon, para tumugma ang restore point sa machine na babaguhin mo.

Paano itinuturing 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 pa ito ginagamit. Nagkakabisa lamang ang kernel sa pag-boot. Lumilitaw ang file na /var/run/reboot-required, at tinutukoy ng /var/run/reboot-required.pkgs kung ano ang humiling ng reboot, pero walang nagre-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 pagitan na ito ang sanhi. Maaaring mag-install ang server ng kernel noong March at mag-reboot noong June dahil sa ganap na ibang dahilan, saka hindi na muling mag-start nang maayos. Tatlong buwan na ang nakalipas nang mangyari ang pagbabagong sumira sa pag-boot, kaya walang ginawa mo noong araw na iyon ang direktang nagpapaliwanag dito. Sa /var/log/apt/history.log mo makikita ang run na nag-install ng kernel na kasalukuyang nagdudulot ng failure.

Mag-reboot nang planado, sa araw na pinili mo, habang nakabukas na ang console window. Dahil sa simpleng gawi na ito, nagiging dalawang minutong menu selection ang isang hindi maipaliwanag na outage. Kung gusto mo ng automation nang walang sorpresa, panatilihing naka-enable ang automatic installs at naka-disable ang automatic reboots, at tingnan ang kung paano i-configure ang unattended-upgrades sa Ubuntu para sa eksaktong settings. Ganap na pinipigilan ng pag-hold sa mga kernel package gamit ang sudo apt-mark hold linux-image-generic ang mga ito, pati ang kernel security fix, kaya ituring ito bilang trade-off na pinili mong tanggapin at hindi bilang safety measure.

FAQ

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

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

Bakit walang GRUB menu na ipinapakita ang VPS ko?

Karaniwang itinatakda ng cloud images sa 0 ang GRUB timeout sa isang file sa ilalim ng /etc/default/grub.d/, kaya nagsisimula ang pinakabagong kernel nang walang kailangang pindutin. 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 pagkatapos ay 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 upang magbakante ng space sa /boot?

Alisin ang pinakaluma at panatilihin ang hindi bababa sa dalawa. Ang puno nang /boot ay isa nang hiwalay na failure mode, dahil mabibigo ang paggawa 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 sa mga candidate ang kernel na kasalukuyang ginagamit. Iwasan ang blanket na sudo apt autoremove --purge sa isang 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 pag-run.

Maaari bang masira ng unattended-upgrades ang boot ko?

Maaari itong mag-install ng kernel na kalaunan ay hindi mag-boot, ngunit 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 habang may automatic run, lumilitaw ang /var/run/reboot-required, at lumalabas lamang ang problema sa susunod mong reboot pagkalipas ng ilang linggo. Magsagawa ng deliberate reboot na nakabukas 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.