VPS haianzi baada ya kernel update: Nini cha kufanya

Nini cha kufanya kwanza wakati VPS haianzi baada ya kernel update

VPS ambayo haianzi baada ya kernel update kwa kawaida inaweza kurejeshwa ndani ya dakika chache, kwa sababu update haikufuta kernel iliyokuwa ikifanya kazi jana. Ubuntu husakinisha kernel mpya kando ya ile ya zamani na kubadilisha tu ni ingizo lipi la GRUB litakalotumika kuanzia mfumo kwa chaguo-msingi. Kwa hivyo, hatua ya kwanza si ukarabati. Chagua kernel iliyotangulia kwenye menyu ya boot, pata prompt ya kuingia, kisha fanya uchunguzi ukiwa ndani ya mfumo unaofanya kazi.

Kurekebisha hili kwenye seva ni tofauti na kurekebisha kompyuta ya mkononi, kwa sababu hakuna kibodi iliyounganishwa na hakuna monitor inayoonyesha panic. SSH haitaitika pia, kwa kuwa mashine haikufika hatua ambapo sshd huanza. Kila kitu hapa chini hufanyika kupitia console ya mtoa huduma wako.

Soma console yako mwenyewe kabla ya kubadilisha chochote. Maandishi kwenye skrini hiyo ndiyo huamua uko katika daraja gani la hitilafu, na seva mbili ambazo zote "hazianzi" zinaweza kuhitaji marekebisho tofauti kabisa.

Ninawezaje kufikia console wakati SSH imekufa?

Fungua paneli ya kudhibiti ya mtoa huduma wako na utafute console. Majina ya kawaida ni VNC console, web console, noVNC, na serial console. Ikiwa zote zipo, chagua serial console kwa sababu inakupa maandishi halisi unayoweza kusogeza na kunakili, wakati VNC ni picha tu ya skrini. Tafuta kidhibiti hiki sasa, wakati mashine ikiwa katika hali nzuri, na uhakikishe inafunguka. Kutafuta console wakati wa hitilafu kunakupotezea utulivu unaohitaji. Ukaguzi huo unapaswa kufanyika katika dakika kumi za kwanza kwenye VPS mpya, sambamba na sheria za firewall na funguo za SSH.

Paneli nyingi pia hutoa rescue mode au recovery image. Hii huwasha mfumo mdogo kutoka kwenye mtandao wa mtoa huduma na kuunganisha diski yako kama kifaa cha ziada, hivyo hakuna kitu kinachoendeshwa kutoka kwenye diski yako. Rescue mode ni njia mbadala wakati GRUB yenyewe imeharibika, na pia ndiyo njia unayotumia kunakili data kutoka kwenye seva ambayo umeamua kutoihifadhi.

Kwa kawaida utahitaji hard reset kutoka kwenye paneli ili kufikia menyu ya boot, kwa sababu huwezi kuendesha sudo reboot kwenye mashine ambayo huwezi kuingia. Hard reset ni sawa na kukata umeme. Mifumo ya faili itapata shutdown isiyo rasmi, kwa hivyo tarajia ukaguzi wa mfumo wa faili (filesystem check) wakati wa boot inayofuata.

Ninawezaje kuchagua kernel ya zamani kwenye menyu ya GRUB?

Fuatilia console kuanzia wakati unapobonyeza kitufe cha reset. Bonyeza Esc mara kwa mara katika sekunde za kwanza, au shikilia Shift kwenye mashine inayowaka kwa hali ya legacy BIOS. Dirisha hili ni fupi, na mara nyingi kifaa cha kuonyesha console huchukua sekunde moja kuunganisha, kwa hivyo anza kubonyeza mapema na uendelee kubonyeza.

Menyu inapoonekana, chagua "Advanced options for Ubuntu". Menyu hiyo ndogo huorodhesha kila kernel iliyosakinishwa, ikianzia na mpya zaidi, pamoja na ingizo la recovery mode kwa kila moja. Chagua ingizo la pili la kawaida, ambalo ni kernel iliyo chini ya ile mpya zaidi, kisha bonyeza Enter. Recovery mode ni kitu tofauti: huwasha mfumo mdogo wa mtumiaji mmoja, na ni kwa ajili ya kazi za ukarabati, si kwa ajili ya kurudisha huduma zako mtandaoni.

Ikiwa kernel ya zamani itawaka, utakuwa na seva inayofanya kazi tena. Thibitisha toleo unalotumia na uandike namba hizo.

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

Matokeo ya dpkg ndiyo orodha yako ya kernels zilizosakinishwa. Ikiwa ina mstari mmoja tu, huna njia mbadala ya kurudi nyuma, na hilo ndilo jambo la kwanza la kurekebisha.

Menyu ya GRUB haionekani kamwe. Nifanye nini?

Picha za mfumo wa Cloud huja na usanidi unaoficha menyu hiyo. Picha za Ubuntu kwa kawaida huweka muda wa kusubiri (timeout) kuwa 0 kwenye faili iliyo ndani ya /etc/default/grub.d/, hivyo kernel mpya zaidi huanza mara moja na hakuna nafasi ya kubonyeza kitufe chochote.

Kuna hali nyingine kinyume chake, ambapo menyu huonekana kwenye skrini na kusubiri, na inaonekana kama mfumo umekwama. GRUB hurekodi boot iliyoshindwa, na kwenye kuanza kwa mara nyingine inaweza kuacha menyu wazi hadi mtu abonyeze kitufe. Kwenye mashine isiyo na kibodi, kusubiri huko hakumaliziki. Ikiwa console yako inaonyesha menyu na hakuna kinachoendelea, ndicho kilichotokea. Chagua ingizo na uendelee.

Rekebisha yote mawili wakati mashine ikiwa katika hali nzuri. Hariri /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"

Kisha itekeleze na uhakikishe kuwa marekebisho yako yamebaki, kwa sababu faili zilizomo kwenye /etc/default/grub.d/ husomwa baada ya /etc/default/grub na zinaweza kubatilisha usanidi wako.

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

GRUB_TERMINAL="console serial" hutuma menyu kwenye console ya picha na kwenye serial port, hivyo huonekana kwenye mtazamaji yeyote anayotolewa na paneli yako. Hoja za kernel za console= hufanya vivyo hivyo kwa ujumbe wa boot unaofuata. Sekunde kumi za kusubiri kwa kila boot ni gharama nafuu kwa menyu unayoweza kuifikia saa 8 usiku.

Ninatazama daraja gani la hitilafu?

Soma mistari ishirini ya mwisho kabla ya konsole kuacha kusonga. Mifumo minne inashughulikia sehemu kubwa ya kinachotokea baada ya sasisho la kernel.

GRUB haiwezi kupata faili zake. Unapata prompt ya grub rescue>, au hitilafu kuhusu partition au faili ambayo haipo, na hakuna ujumbe wa kernel unaoonekana. Kernel bado haijahusika. Hii hutokea baada ya mabadiliko ya diski au partition, au bootloader kuandikwa kwenye kifaa kisicho sahihi, badala ya kifurushi cha kernel chenyewe.

Kernel inaanza lakini haiwezi ku-mount root. Ujumbe wa kernel unatiririka, kisha unafika kwenye busybox shell ambayo prompt yake inasoma (initramfs), au boot inaishia kwenye panic kuhusu kutoweza ku-mount root filesystem. Kernel ilipakia. Initramfs, ambayo ni root ndogo ya muda inayotafuta na ku-mount root filesystem yako halisi, haikupata diski. Kwenye Ubuntu, shell hii kwa kawaida hutanguliwa na ujumbe kuhusu kuacha kusubiri kifaa cha root, na inataja UUID iliyokuwa ikitafuta. Nakili UUID hiyo na uilinganishe na matokeo ya blkid baadaye.

Logical volume haionekani kamwe. Hii ni daraja iliyotangulia ikiwa na sababu moja mahususi. Kwenye prompt ya (initramfs), endesha ls /dev/mapper. Ikiwa ingizo pekee ni control, basi hakuna volume ya LVM (logical volume manager) iliyoamilishwa, kwa hivyo kifaa cha root bado hakipo. Amilisha volume groups kwa mkono:

lvm vgchange -ay
ls /dev/mapper
exit

exit inarudisha udhibiti kwenye hati ya initramfs, ambayo inajaribu tena ku-mount. Ikiwa mfumo utawaka baada ya hapo, initramfs mpya inakosa vipengele vya LVM, na ukarabati wake ni kujenga upya image hiyo badala ya kugusa kernel.

Hakuna chochote kutoka Linux kabisa. Konsole inaonyesha maandishi ya firmware, shell ya UEFI (unified extensible firmware interface), skrini tupu bila matokeo ya kernel, au mzunguko wa kuanza upya (reset loop). Hitilafu inatokea kabla ya Linux kuanza kufanya kazi. Angalia hali ambayo seva yako inatumia mara tu utakapoweza kuingia, kwa sababu mifano mingi ya VPS huwaka katika hali ya legacy BIOS na haigusi kamwe njia ya EFI:

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

/boot/efi ambayo haija-mount wakati wa upgrade ni sababu ya kawaida kwenye mashine za UEFI, kwa sababu vifurushi vinavyosimamia EFI system partition viliandika kwenye saraka ya kawaida tupu badala yake. Firmware inaendelea kuanza ingizo la zamani la boot hadi ingizo hilo liache kulingana na kilicho kwenye diski.

Mfumo mwingine mmoja si hitilafu ya boot hata kidogo. Ikiwa utafika kwenye root shell inayosema mfumo uko katika hali ya dharura (emergency mode), kernel iliwaka na userspace ikasimama. Hiyo kwa kawaida inamaanisha mstari mbaya katika /etc/fstab au filesystem iliyoshindwa ukaguzi wake. Endesha journalctl -xb katika shell hiyo na usome jina la unit iliyoshindwa.

Je, kifurushi cha kernel kimeharibika, au initramfs?

Hali hizi mbili zinaonekana sawa kutoka kwenye console na zinahitaji marekebisho tofauti. Anzisha seva kwa kutumia kernel ya zamani, kisha ulinganishe faili hizo.

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

Unahitaji vmlinuz- moja na initrd.img- inayolingana kwa kila toleo lililosakinishwa, kila moja ikiwa na ukubwa unaoeleweka. Initrd inayokosekana, au iliyo ndogo sana ikilinganishwa na nyingine, inamaanisha kuwa utengenezaji wa initramfs umefeli. Sababu ya kawaida ni /boot kujaa, na ushahidi unapatikana katika logi za kifurushi:

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

history.log pia huorodhesha kwa usahihi vifurushi vilivyosakinishwa katika mara za mwisho na wakati gani, jambo ambalo hutatua mjadala wowote kuhusu kile kilichobadilika.

Futa nafasi kwanza ikiwa /boot imejaa, kisha ujenge upya image kwa toleo unalohitaji na uburudishe menyu. Chukua kamba ya toleo (version string) kutoka kwenye matokeo ya ls yako mwenyewe, kwa sababu kishika nafasi (placeholder) kilicho hapa chini si toleo halisi:

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

ls hiyo ya mwisho ni kwa ajili ya ukaguzi. Faili yenye ukubwa wa kawaida inamaanisha kuwa image sasa ipo. Ikiwa badala yake image ya kernel yenyewe imeharibika, au dpkg -l inaonyesha kifurushi katika hali yoyote isiyokuwa ii, sakinisha upya kifurushi hicho:

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

Kurekebisha mfumo kutoka rescue mode wakati kernel haianzi

Ikiwa kila chaguo kwenye menyu linashindwa, anzisha seva kwa kutumia rescue image ya mtoa huduma na urekebishe diski ukiwa nje ya mfumo. Diski yako itaonekana kama kifaa ambacho hakijapandishwa (unmounted), kwa hivyo hakuna kinachoendelea ndani yake na hakuna kitakachokuzuia.

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

Jaribu kernel mpya bila kuhatarisha boot inayofuata

GRUB inaweza kuanzisha ingizo moja kwa mara moja kisha kurudi kwenye chaguo lako la msingi. Elekeza chaguo-msingi kwenye kernel unayoiamini, kisha anzisha ile mpya kwa ajili ya boot moja pekee. Ikiwa itashindwa, hard reset kutoka kwenye paneli itakurudisha kwenye kernel nzuri bila kuhitaji muda wa console ili kuifanya kwa usahihi.

Weka GRUB_DEFAULT=saved katika /etc/default/grub, endesha sudo update-grub, kisha orodhesha vichwa vya maingizo ili uweze kutaja kimoja kwa usahihi:

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 inapaswa kuchapisha kichwa ulichochagua kama saved_entry. Tokeo hilo ni uthibitisho kwamba utaratibu huu unafanya kazi, kwa sababu kuhifadhi kunahitaji /boot/grub/grubenv inayoweza kuandikika, na kwenye baadhi ya miundo haifanyi hivyo kimyakimya. Ingizo 0 ndilo la juu kabisa kwenye menyu, ambalo ndilo kernel mpya zaidi. Vichwa ni salama zaidi kuliko namba hapa, kwa sababu namba hubadilika kila wakati kernel inaposakinishwa au kuondolewa.

Kwa nini autoremove ni hatari kwenye seva isiyo na terminal ya moja kwa moja

APT huweka orodha ya vifurushi vya kernel ambavyo haipaswi kuviondoa vyenyewe. Soma orodha yako:

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

Faili hilo hutengenezwa upya kila vifurushi vya kernel vinapobadilika, na hulinda kernel inayotumika pamoja na zile za hivi karibuni. Mtego upo kwenye muda. Endesha sudo apt autoremove --purge mara tu baada ya kuwasha upya seva (reboot) kwenye kernel mpya, na orodha iliyolindwa itakuwa imeshasasishwa, kwa hivyo kernel ya zamani uliyokuwa unaihitaji haitalindwa tena. Kwenye mashine yenye keyboard hiyo ni usumbufu mdogo. Kwenye seva isiyo na terminal ya moja kwa moja (headless), hiyo ndiyo tofauti kati ya kuchagua chaguo kwenye menyu ya boot na kulazimika ku-mount diski yako kutoka kwenye rescue image.

Weka kernel mbili kama kiwango cha chini, na tatu ikiwa /boot ina nafasi ya kutosha. Ondoa zile za zamani kwa jina baada ya kukagua uname -r, ili usije kufuta ile unayoitumia sasa:

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

Endesha amri hiyo ya mwisho tena baada ya hapo. Idadi kupungua kutoka tatu hadi mbili ni usafishaji wa kawaida. Idadi kupungua hadi moja ni ishara ya hitilafu inayongoja kutokea kwenye reboot inayofuata.

Chukua snapshot kabla ya upgrade

Snapshot inayochukuliwa kabla ya apt upgrade ndiyo njia pekee ya kurejesha mfumo ambayo haitegemei kuwasha kitu chochote. Kuirejesha huurudisha diski katika hali ambapo kernel ya zamani ilikuwa chaguo-msingi, na unaweza kujaribu tena upgrade ukiwa na console iliyo wazi. Snapshot za mashine inayofanya kazi ni "crash consistent", kumaanisha kuwa hunasa diski kama vile umeme umekatika, kwa hivyo zima seva kwanza ikiwa mtoa huduma wako anaruhusu snapshot ya nje ya mtandao (offline). Snapshot pia si backup, kwa sababu kwa kawaida hukaa kwenye miundombinu sawa na diski inayoinakili. Kuelewa tofauti kati ya snapshot za VPS na backup halisi huamua ni ipi itakuokoa wakati hitilafu ni kubwa kuliko kernel.

Hili ni muhimu zaidi wakati wa release upgrade, ambapo kernel, zana za initramfs, bootloader, na usanidi wa GRUB vyote hubadilika katika hatua moja. Chukua snapshot mara moja kabla ya kuanza upgrade ya Ubuntu 24.04 kwenda 26.04, si usiku uliotangulia, ili sehemu ya kurejesha (restore point) ilingane na mashine unayokaribia kuibadilisha.

Jinsi unattended-upgrades inavyoshughulikia vifurushi vya kernel

Huduma ya unattended-upgrades ya Ubuntu husakinisha masasisho ya usalama bila kuuliza, na vifurushi vya kernel hufika kupitia security pocket kama vifurushi vingine vyovyote. Matokeo yake ni mawili.

Kwanza, kernel mpya husakinishwa lakini haiendeshi. Kernel huanza kufanya kazi wakati wa boot pekee. Faili ya /var/run/reboot-required huonekana, na /var/run/reboot-required.pkgs huonyesha kile kilichoomba reboot, lakini hakuna kinachojianzisha upya isipokuwa kama umewezesha Unattended-Upgrade::Automatic-Reboot katika /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

Pili, pengo hilo huficha chanzo cha tatizo. Seva inaweza kusakinisha kernel mwezi Machi na kufanya reboot mwezi Juni kwa sababu isiyohusiana kabisa, kisha ikashindwa kuwaka. Mabadiliko yaliyovuruga boot yana umri wa miezi mitatu, kwa hivyo hakuna ulichokifanya siku hiyo kinachoweza kuelezea tatizo hilo. /var/log/apt/history.log ndipo unapoweza kupata kumbukumbu ya usakinishaji wa kernel inayokupa shida sasa.

Fanya reboot kwa makusudi, siku uliyochagua mwenyewe, huku dirisha la console likiwa wazi. Tabia hiyo moja hubadilisha hitilafu ya kushtukiza kuwa uteuzi wa menyu wa dakika mbili. Ikiwa unataka otomatiki bila mshangao, acha usakinishaji wa kiotomatiki uwe umewashwa na reboot za kiotomatiki zizimwe, na tazama jinsi ya kusanidi unattended-upgrades kwenye Ubuntu kwa mipangilio kamili. Kushikilia vifurushi vya kernel kwa kutumia sudo apt-mark hold linux-image-generic huvisimamisha kabisa, na pia husimamisha marekebisho ya usalama ya kernel wakati huo huo, kwa hivyo chukulia hilo kama biashara uliyochagua kufanya badala ya hatua ya usalama.

FAQ

Ninawezaje kuwasha kernel ya zamani kwenye VPS isiyo na kibodi?

Fungua console ya mtoa huduma (VNC au serial) na uanzishe hard reset kutoka kwenye control panel, kwa sababu huwezi kuingia kwenye mfumo ili kufanya reboot ya kawaida. Mashine inapoanza kuwaka, bonyeza Esc mara kwa mara, au shikilia Shift kwenye BIOS ya zamani, ili kushikilia menyu ya GRUB. Chagua "Advanced options for Ubuntu" na uchague ingizo lililo chini ya kernel mpya zaidi. Mara tu unapopata prompt ya kuingia, endesha uname -r ili kuthibitisha ni kernel ipi unayotumia na dpkg -l 'linux-image-*' ili kuona ni nini kingine kilichosakinishwa. Fanya utambuzi baada ya mfumo kuanza kufanya kazi tena.

Kwa nini VPS yangu haionyeshi menyu ya GRUB hata kidogo?

Picha za cloud (cloud images) kwa kawaida huweka muda wa kusubiri wa GRUB kuwa 0 kwenye faili iliyo chini ya /etc/default/grub.d/, hivyo kernel mpya zaidi huanza bila nafasi ya kubonyeza chochote. Weka GRUB_TIMEOUT=10 na GRUB_TIMEOUT_STYLE=menu ndani ya /etc/default/grub, ongeza GRUB_TERMINAL="console serial" ili menyu ifike pia kwenye serial console, kisha endesha sudo update-grub. Thibitisha kwa grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, kwa sababu faili zilizomo kwenye saraka hiyo husomwa baada ya faili kuu na zinaweza kubatilisha marekebisho yako.

Je, niondoe kernels za zamani ili kupata nafasi kwenye /boot?

Ondoa zile za zamani zaidi na uweke angalau mbili. /boot iliyojaa ni tatizo lenyewe, kwa sababu utengenezaji wa initramfs utafeli na utabaki na kernel isiyo na image inayofanya kazi. Futa kwa kutumia jina kamili la kifurushi baada ya kuangalia uname -r, ili kernel inayotumika isije ikafutwa. Epuka kutumia sudo apt autoremove --purge kwa wingi kwenye mashine isiyo na ufuatiliaji wa moja kwa moja (headless), kwa sababu orodha ya kernels zilizolindwa hutengenezwa upya kila kernel inapobadilika na uendeshaji usiofaa unaweza kukuacha na kernel moja bila njia mbadala kwenye menyu.

Je, unattended-upgrades inaweza kuharibu boot yangu?

Inaweza kusakinisha kernel ambayo baadaye inashindwa kuwaka, lakini haianzishi upya mashine isipokuwa Unattended-Upgrade::Automatic-Reboot ikiwa imewekwa kuwa true ndani ya /etc/apt/apt.conf.d/50unattended-upgrades. Mfumo wa kawaida ni kufeli kwa kuchelewa: kernel huingia wakati wa uendeshaji wa kiotomatiki, /var/run/reboot-required inaonekana, na tatizo hujitokeza tu kwenye reboot yako inayofuata wiki kadhaa baadaye. Fanya reboot kwa makusudi huku console ikiwa wazi, na usome /var/log/apt/history.log ili kujua ni uendeshaji upi uliosanikisha kernel unayoiwasha.