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 kurekebishika 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 tena sehemu ya kuingia (login prompt), 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 kifuatiliaji (monitor) kinachoonyesha hitilafu ya mfumo (panic). SSH haitaitika pia, kwa kuwa mashine haijafika hatua ambapo sshd huanza. Kila kitu hapa chini kinafanyika kupitia console ya mtoa huduma wako.

Soma console yako mwenyewe kabla ya kubadilisha chochote. Maandishi kwenye skrini hiyo ndiyo huamua uko katika kundi 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. Kuitafuta 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 hali ya rescue au recovery image. Hii huwasha mfumo mdogo kutoka kwenye mtandao wa mtoa huduma na kuunganisha diski yako kama kifaa cha ziada, hivyo hakuna kitu kwenye diski yako kinachoendeshwa. Hali ya rescue ndiyo njia ya dharura 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 hupata shutdown isiyo safi, kwa hivyo tarajia ukaguzi wa mfumo wa faili (filesystem check) kwenye boot inayofuata.

Ninawezaje kuchagua kernel ya zamani kwenye menyu ya GRUB?

Fuatilia console kuanzia wakati unapobonyeza kitufe cha kuwasha upya (reset). Bonyeza Esc mara kwa mara katika sekunde za kwanza, au shikilia Shift kwenye mashine inayowaka kwa kutumia hali ya legacy BIOS. Muda wa kufanya hivi ni mfupi, 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 ile mpya zaidi, ikiwa 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 (single user system), 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'

Toleo la dpkg ndilo orodha yako ya kernels zilizosakinishwa. Ikiwa lina 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 mara nyingi huweka muda wa kusubiri (timeout) kuwa 0 kwenye faili iliyo chini ya /etc/default/grub.d/, hivyo kernel mpya zaidi huanza mara moja na hakuna nafasi ya kubonyeza kitufe chochote.

Kuna pia hali ya kinyume, ambapo menyu huonekana kwenye skrini na kusubiri, na inaonekana kama mfumo umekwama. GRUB hurekodi hitilafu ya boot, na katika kuanza kwa mara nyingine inaweza kuweka 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 (entry) na uendelee.

Rekebisha hali zote mbili 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 zilizopo 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 (viewer) anayotolewa na paneli yako. Hoja za kernel za console= hufanya vivyo hivyo kwa ujumbe wa boot unaofuata. Sekunde 10 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 isiyokuwepo, 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 inasomeka (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 la awali lenye sababu moja mahususi. Kwenye prompt ya (initramfs), endesha ls /dev/mapper. Ikiwa ingizo pekee ni control, basi hakuna LVM (logical volume manager) volume iliyowashwa, kwa hivyo kifaa cha root hakipo bado. Washa volume groups kwa mkono:

lvm vgchange -ay
ls /dev/mapper
exit

exit inarudisha udhibiti kwa 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, UEFI (unified extensible firmware interface) shell, skrini tupu bila matokeo ya kernel, au mzunguko wa kuanza upya (reset loop). Hitilafu inatokea kabla ya Linux kuanza. Angalia hali ambayo seva yako inatumia mara tu utakapofanikiwa kuingia, kwa sababu VPS nyingi huwaka katika hali ya legacy BIOS na hazigusi kamwe njia ya EFI:

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

/boot/efi ambayo haija-mountwa 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 kile kilicho kwenye diski.

Mfumo mwingine 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 ni initramfs?

Hali hizi mbili zinaonekana sawa kutoka kwenye console na zinahitaji marekebisho tofauti. Boot 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 majirani zake, inamaanisha kuwa utengenezaji wa initramfs umefeli. Sababu ya kawaida ni /boot kujaa, na ushahidi unapatikana kwenye 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 ni vifurushi vipi vilivyosakinishwa kwenye operesheni za mwisho na lini, jambo linalomaliza mjadala wowote kuhusu nini kimebadilika.

Futa nafasi kwanza ikiwa /boot imejaa, kisha jenga upya image kwa toleo unalohitaji na uburudishe menyu. Chukua kamba ya toleo (version string) kutoka kwenye matokeo yako ya ls, 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 isipokuwa ii, sakinisha upya kifurushi hicho:

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

Kurekebisha mfumo kutoka rescue mode wakati kernel haifunguki

Ikiwa kila chaguo kwenye menyu linashindwa, fungua (boot) 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 la msingi kwenye kernel unayoiamini, kisha anzisha ile mpya kwa ajili ya boot moja tu. Ikiwa itashindwa, hard reset kutoka kwenye paneli itakurudisha kwenye kernel nzuri bila kuhitaji muda wa console ili kuifanya kwa usahihi.

Weka GRUB_DEFAULT=saved ndani ya /etc/default/grub, endesha sudo update-grub, kisha orodhesha vichwa vya maingizo ili uweze kutaja moja 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 kuwa utaratibu huu unafanya kazi, kwa sababu kuhifadhi kunahitaji /boot/grub/grubenv inayoweza kuandikika, na kwenye baadhi ya miundo haifanyi hivyo kimyakimya. Ingizo 0 ni sehemu ya juu ya menyu, ambayo ndiyo 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 (headless)

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 (reboot) kwenye kernel mpya, na orodha iliyolindwa itakuwa imeshasogea mbele, kwa hivyo kernel ya zamani uliyokuwa unaihitaji haitalindwa tena. Kwenye mashine yenye keyboard hilo ni usumbufu tu. Kwenye seva isiyo na terminal (headless), hilo ni tofauti kati ya kuchagua chaguo kwenye menyu 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 ukafuta ile unayotumia 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. Idadi kupungua hadi moja ni ishara ya hitilafu inayongojea 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 ndiyo chaguo-msingi, na unaweza kujaribu tena upgrade hiyo huku console ikiwa tayari imefunguliwa. 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 ndiko kunakoamua 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 kwa wakati mmoja. Chukua snapshot mara moja kabla ya kuanza upgrade ya Ubuntu 24.04 kwenda 26.04, si usiku uliotangulia, ili sehemu ya kurejeshea ilingane na mashine unayotaka kuibadilisha. Ikiwa upgrade hiyo haijatolewa kwenye seva yako bado, sababu ni upangaji wa muda badala ya usanidi mbovu, kwa sababu mabadiliko kutoka LTS moja kwenda nyingine hufunguka tu kwenye toleo la kwanza la marekebisho, 26.04.1.

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 ilivyo kwa vifurushi vingine. Hii huleta matokeo mawili.

Kwanza, kernel mpya husakinishwa lakini haifanyi kazi. Kernel huanza kufanya kazi wakati wa boot pekee. Faili ya /var/run/reboot-required huonekana, na /var/run/reboot-required.pkgs huonyesha kilichoomba reboot, lakini hakuna kinachojianzisha upya isipokuwa uwe umewezesha Unattended-Upgrade::Automatic-Reboot ndani ya /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 yaliyosababisha tatizo la 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, 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 uzime reboot za kiotomatiki, na uone jinsi ya kusanidi unattended-upgrades kwenye Ubuntu kwa mipangilio sahihi. Kuzuia vifurushi vya kernel kwa kutumia sudo apt-mark hold linux-image-generic huvisimamisha kabisa, na pia husimamisha marekebisho ya usalama ya kernel kwa wakati mmoja, kwa hivyo chukulia hilo kama makubaliano uliyofanya badala ya hatua ya usalama.

FAQ

Je, 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 kusimamisha menyu ya GRUB. Chagua "Advanced options for Ubuntu" na uchague chaguo lililo chini ya kernel mpya zaidi. Mara tu unapopata sehemu ya kuingia (login prompt), endesha uname -r ili kuthibitisha kernel unayotumia na dpkg -l 'linux-image-*' ili kuona nini kingine kimesakinishwa. Fanya utambuzi (diagnose) baada ya mfumo kuanza kufanya kazi tena.

Kwa nini VPS yangu haionyeshi menyu ya GRUB hata kidogo?

Picha za cloud (cloud images) mara nyingi huweka muda wa kusubiri wa GRUB (timeout) 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 kernel za zamani ili kupata nafasi kwenye /boot?

Ondoa zile za zamani zaidi na ubakize 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 kernel 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. Mtindo 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 kupata ni uendeshaji upi uliosakinisha kernel unayojaribu kuwasha.