kernel update తర్వాత boot కాని VPS ను ఎలా రికవర్ చేయాలి

kernel update తర్వాత VPS boot కాకపోతే ముందుగా ఏమి చేయాలి

kernel update తర్వాత boot కాని VPS ను సాధారణంగా కొన్ని నిమిషాల్లో తిరిగి పనిచేయించవచ్చు. కారణం, update నిన్న పనిచేసిన kernel ను సాధారణంగా తొలగించదు. Ubuntu కొత్త kernel ను పాత kernel పక్కనే install చేస్తుంది. GRUB డిఫాల్ట్‌గా ప్రారంభించే entry మాత్రమే మారుతుంది. కాబట్టి మొదటి చర్య repair చేయడం కాదు. boot menuలో మునుపటి kernel ను ఎంచుకుని, login prompt ను తిరిగి పొందండి. ఆ తర్వాత నడుస్తున్న system నుంచే సమస్యను నిర్ధారించండి.

serverలో దీన్ని పరిష్కరించడం laptopలో పరిష్కరించడంతో భిన్నంగా ఉంటుంది. serverకు keyboard అనుసంధానించి ఉండదు. panic కనిపించడానికి monitor కూడా ఉండదు. machine sshd ప్రారంభమయ్యే దశకు చేరుకోకపోవడంతో SSH కూడా స్పందించదు. కింది చర్యలన్నీ మీ provider console ద్వారా చేయాలి.

ఏదైనా మార్చే ముందు మీ consoleలో కనిపిస్తున్న సమాచారాన్ని చదవండి. ఆ screenలోని text మీరు ఎదుర్కొంటున్న failure class ను నిర్ణయిస్తుంది. “boot కాదు” అనే ఒకే లక్షణం ఉన్న రెండు serversకు పూర్తిగా భిన్నమైన fixes అవసరం కావచ్చు.

SSH పనిచేయనప్పుడు console ను ఎలా యాక్సెస్ చేయాలి?

మీ provider యొక్క control panel ను తెరిచి console కోసం చూడండి. సాధారణంగా దీనిని VNC console, web console, noVNC, serial console అని పిలుస్తారు. రెండూ అందుబాటులో ఉంటే serial console కు ప్రాధాన్యత ఇవ్వండి. ఎందుకంటే అందులో scroll చేసి copy చేయగల నిజమైన text కనిపిస్తుంది. VNC view మాత్రం screen యొక్క చిత్రం మాత్రమే చూపిస్తుంది. యంత్రం సక్రమంగా పనిచేస్తున్నప్పుడే ఈ control ను కనుగొని, అది తెరుచుకుంటుందో నిర్ధారించండి. outage సమయంలో దీని కోసం వెతకడం వల్ల అవసరమైన ప్రశాంతత కోల్పోతారు. ఈ తనిఖీ కొత్త VPS పై మొదటి పది నిమిషాల్లో చేయాల్సిన పనుల్లో ఒకటి. Firewall rules మరియు SSH keys పక్కనే దీన్ని కూడా నమోదు చేయండి.

చాలా panels rescue mode లేదా recovery image ను కూడా అందిస్తాయి. ఇది provider యొక్క network నుంచి ఒక చిన్న system ను boot చేసి, మీ disk ను అదనపు device గా attach చేస్తుంది. అందువల్ల మీ disk లోని ఏదీ run కాదు. GRUB పనిచేయనప్పుడు rescue mode fallback గా ఉపయోగపడుతుంది. ఇక రక్షించాల్సిన అవసరం లేదని నిర్ణయించిన server నుంచి data ను copy చేయడానికి కూడా ఇదే విధానం ఉపయోగపడుతుంది.

Boot menu ను చేరుకోవడానికి సాధారణంగా panel నుంచి hard reset చేయాలి. ఎందుకంటే login చేయలేని machine పై sudo reboot ను run చేయలేరు. Hard reset అంటే power ను నేరుగా నిలిపివేయడంతో సమానం. Filesystems clean గా shutdown కావు. కాబట్టి తదుపరి boot సమయంలో filesystem check జరుగుతుందని ఆశించండి.

GRUB మెనూలో పాత kernel ను ఎలా ఎంచుకోవాలి?

reset నొక్కిన క్షణం నుంచి console ను గమనించండి. మొదటి కొన్ని సెకన్లలో Esc ను పదేపదే నొక్కండి. Legacy BIOS mode లో boot అయ్యే యంత్రంలో Shift ను నొక్కి పట్టుకోండి. ఈ అవకాశం చాలా తక్కువ సమయం మాత్రమే ఉంటుంది. Console viewer కు connect అవ్వడానికి సాధారణంగా ఒక సెకను పడుతుంది. అందువల్ల ముందుగానే నొక్కడం ప్రారంభించి, వరుసగా నొక్కుతూ ఉండండి.

మెను కనిపించినప్పుడు "Ubuntu కోసం అధునాతన ఎంపికలు" ను ఎంచుకోండి. ఆ submenu లో install చేసిన ప్రతి kernel కనిపిస్తుంది. అవి కొత్తది మొదటగా ఉండే క్రమంలో ఉంటాయి. ప్రతి kernel కు recovery mode entry కూడా ఉంటుంది. రెండవ సాధారణ entry ను ఎంచుకోండి. అది కొత్తదాని కింద ఉన్న kernel. తరువాత Enter నొక్కండి. Recovery mode వేరు. ఇది కనిష్ఠ single-user system లో boot అవుతుంది. ఇది repair పనుల కోసం మాత్రమే. మీ services ను మళ్లీ online లోకి తీసుకురావడానికి దీనిని ఉపయోగించకండి.

పాత kernel సరిగ్గా boot అయితే, server మళ్లీ పనిచేస్తుంది. మీరు ప్రస్తుతం ఏ kernel పై నడుస్తున్నారో నిర్ధారించి, ఆ సంఖ్యలను రాసుకోండి.

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

dpkg output లో install చేసిన kernels జాబితా ఉంటుంది. అందులో ఒకే line ఉంటే, మీ వద్ద fallback ఏదీ లేదు. ముందుగా పరిష్కరించాల్సిన సమస్య అదే.

GRUB మెనూ కనిపించదు. ఇప్పుడు ఏమి చేయాలి?

Cloud images మెనూను దాచే configuration తో విడుదలవుతాయి. Ubuntu images సాధారణంగా /etc/default/grub.d/ కింద ఉన్న ఫైల్‌లో timeout ను 0గా సెట్ చేస్తాయి. అందువల్ల తాజా kernel వెంటనే ప్రారంభమవుతుంది. నొక్కడానికి ఏదీ ఉండదు.

దీనికి విరుద్ధమైన పరిస్థితి కూడా ఉంటుంది. మెనూ తెరపై కనిపిస్తూ, input కోసం వేచి ఉండవచ్చు. అప్పుడు system hang అయినట్లు అనిపిస్తుంది. GRUB విఫలమైన boot ను నమోదు చేస్తుంది. తదుపరి start సమయంలో ఎవరైనా key నొక్కే వరకు menu తెరిచి ఉంచవచ్చు. Keyboard లేని machine లో ఆ నిరీక్షణ ఎప్పటికీ ముగియదు. మీ console లో menu కనిపించి, ఏదీ కదలకపోతే ఇదే కారణం. ఒక entry ఎంచుకుని కొనసాగించండి.

Machine సక్రమంగా పనిచేస్తున్నప్పుడే ఈ రెండు సమస్యలను పరిష్కరించండి. /etc/default/grub ను edit చేయండి:

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"

తర్వాత మార్పును apply చేసి, అది అలాగే ఉందో తనిఖీ చేయండి. ఎందుకంటే /etc/default/grub.d/ లోని files ను /etc/default/grub తర్వాత చదువుతారు. అవి మీ మార్పులను override చేయవచ్చు.

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

GRUB_TERMINAL="console serial" menu ను graphical console మరియు serial port రెండింటికీ పంపుతుంది. అందువల్ల మీ panel ఇచ్చే viewer లో అది కనిపిస్తుంది. console= kernel arguments తర్వాత వచ్చే boot messages కు కూడా ఇదే విధంగా పనిచేస్తాయి. Boot కు 10 seconds ఆలస్యం అయినా, 2am సమయంలో మీరు నిజంగా చేరుకోగల menu కోసం అది తక్కువ ఖర్చే.

నేను ఏ వైఫల్య వర్గాన్ని పరిశీలిస్తున్నాను?

కన్సోల్‌లో మార్పులు ఆగిపోవడానికి ముందు కనిపించిన చివరి ఇరవై పంక్తులను చదవండి. Kernel update తర్వాత సాధారణంగా కనిపించే సమస్యలను నాలుగు నమూనాలు కవర్ చేస్తాయి.

GRUB తన ఫైళ్లను కనుగొనలేకపోతోంది. మీకు grub rescue> prompt కనిపించవచ్చు, లేదా లేని partition లేదా file గురించి error కనిపించవచ్చు. కానీ kernel message ఏదీ కనిపించదు. ఈ దశలో kernel ఇంకా ప్రారంభం కాలేదు. సాధారణంగా ఇది kernel package వల్ల మాత్రమే జరగదు. Disk లేదా partition మార్చడం, లేదా bootloader ను తప్పు device పై రాయడం వంటి కారణాల వల్ల జరుగుతుంది.

Kernel ప్రారంభమైంది, కానీ root ను mount చేయలేకపోతోంది. Kernel messages కనిపించిన తర్వాత (initramfs) prompt ఉన్న busybox shell కు చేరవచ్చు. లేదా root filesystem ను mount చేయలేకపోయిందని panic message తో boot ఆగిపోవచ్చు. Kernel load అయింది. నిజమైన root filesystem ను కనుగొని mount చేసే చిన్న తాత్కాలిక root అయిన initramfs disk ను కనుగొనలేకపోయింది. Ubuntu లో సాధారణంగా ఈ shell కు ముందు root device కోసం వేచి ఉండటం ఆపివేసినట్లు message కనిపిస్తుంది. అందులో అవసరమైన UUID ఇవ్వబడుతుంది. ఆ UUID ను కాపీ చేసి, తరువాత blkid output తో సరిపోల్చండి.

Logical volume కనిపించడం లేదు. ఇది మునుపటి వర్గానికి చెందినదే, కానీ ఒక నిర్దిష్ట కారణంతో జరుగుతుంది. (initramfs) prompt వద్ద ls /dev/mapper అమలు చేయండి. ఒకే entry control అయితే, ఏ LVM (logical volume manager) volume కూడా activate కాలేదు. అందువల్ల root device ఇంకా ఉనికిలో లేదు. Volume groups ను మాన్యువల్‌గా ప్రారంభించండి:

lvm vgchange -ay
ls /dev/mapper
exit

exit initramfs script కు నియంత్రణను తిరిగి ఇస్తుంది. అది mount ను మళ్లీ ప్రయత్నిస్తుంది. ఆ తర్వాత system boot అయితే, కొత్త initramfs లో LVM భాగాలు లేవు. Kernel ను మార్చకుండా ఆ image ను మళ్లీ నిర్మించాలి.

Linux నుంచి ఎలాంటి output లేదు. Console లో firmware text, UEFI (unified extensible firmware interface) shell, kernel output లేని ఖాళీ screen లేదా reset loop కనిపించవచ్చు. Linux ప్రారంభం కావడానికి ముందే వైఫల్యం జరుగుతోంది. Server తిరిగి ప్రారంభమైన తర్వాత అది వాస్తవంగా ఏ mode ఉపయోగిస్తుందో పరిశీలించండి. అనేక VPS instances legacy BIOS mode లో boot అవుతాయి. అవి EFI path ను అసలు ఉపయోగించవు:

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

UEFI machines లో upgrade సమయంలో /boot/efi mount కాకపోవడం సాధారణ కారణం. అప్పుడు EFI system partition ను నిర్వహించే packages సాధారణంగా ఖాళీగా ఉన్న మరో directory లోకి రాస్తాయి. Disk లో ఉన్నదానితో ఆ entry సరిపోలడం ఆగిపోయే వరకు firmware పాత boot entry ను ప్రారంభిస్తూనే ఉంటుంది.

ఇంకొక నమూనా అసలు boot failure కాదు. System emergency mode లో ఉందని చెప్పే root shell కు చేరితే, kernel boot అయింది మరియు userspace ఆగిపోయింది. సాధారణంగా /etc/fstab లోని తప్పు line లేదా check విఫలమైన filesystem దీనికి కారణం. ఆ shell లో journalctl -xb అమలు చేసి, విఫలమైన unit పేరు చదవండి.

కెర్నల్ package దెబ్బతిన్నదా, లేక initramfs దెబ్బతిన్నదా?

కన్సోల్‌లో ఈ రెండూ ఒకే విధంగా కనిపిస్తాయి. కానీ వీటికి వేర్వేరు పరిష్కారాలు అవసరం. పాత కెర్నల్‌ను boot చేసి, తరువాత files ను పోల్చండి.

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

ప్రతి installed version కోసం ఒక vmlinuz- మరియు దానికి సరిపోయే ఒక initrd.img- ఉండాలి. రెండింటికీ నమ్మదగిన file size ఉండాలి. initrd లేకపోవడం, లేదా దాని పరిమాణం పక్కనున్న files కంటే చాలా తక్కువగా ఉండటం, initramfs generation విఫలమైందని సూచిస్తుంది. సాధారణ కారణం /boot పూర్తి కావడం. దీనికి సంబంధించిన ఆధారం package logs లో ఉంటుంది:

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

చివరిసార్లు ఏ packages install అయ్యాయో, అవి ఎప్పుడు install అయ్యాయో history.log ఖచ్చితంగా చూపిస్తుంది. అందువల్ల ఏమి మారిందనే వివాదం కూడా పరిష్కారమవుతుంది.

/boot full గా ఉంటే ముందుగా free space కల్పించండి. తరువాత అవసరమైన version కోసం image ను rebuild చేసి, menu ను refresh చేయండి. మీ స్వంత ls output నుంచి version string తీసుకోండి. క్రింద ఉన్న placeholder నిజమైన release కాదు:

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

చివరి ls తనిఖీ కోసం ఉపయోగించేది. సాధారణ పరిమాణంలో ఉన్న file కనిపిస్తే image ఇప్పుడు అందుబాటులో ఉందని అర్థం. బదులుగా కెర్నల్ image దెబ్బతిన్నట్లయితే, లేదా dpkg -l package స్థితి ii కాకుండా మరేదైనా చూపిస్తే, package ను మళ్లీ install చేయండి:

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

రెస్క్యూ మోడ్‌లో ఏ kernel కూడా boot కాకపోతే మరమ్మతు చేయడం

మెనులోని ప్రతి entry విఫలమైతే, provider యొక్క rescue image ను boot చేసి, disk ను బయటి నుంచి మరమ్మతు చేయండి. మీ disk unmounted device గా కనిపిస్తుంది. అందువల్ల దానిపై ఏదీ నడవదు, ఏ ప్రక్రియ కూడా మీకు అడ్డంకి కలిగించదు.

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

తదుపరి boot ను పణంగా పెట్టకుండా కొత్త kernel ను పరీక్షించండి

GRUB ఒక entry ను ఒక్కసారి ప్రారంభించి, తర్వాత మీరు ఎంచుకున్న default కు తిరిగి వెళ్లగలదు. మీకు నమ్మకమైన kernel ను default గా సెట్ చేసి, కొత్త kernel ను ఒక boot కోసం మాత్రమే ప్రారంభించండి. అది విఫలమైతే, panel నుంచి hard reset చేయడం ద్వారా console timing సరిచేయాల్సిన అవసరం లేకుండా మంచి kernel కు తిరిగి వెళ్లవచ్చు.

/etc/default/grub లో GRUB_DEFAULT=saved ను సెట్ చేసి, sudo update-grub ను అమలు చేయండి. తర్వాత entry titles ను జాబితా చేయండి, తద్వారా ఒకదాన్ని ఖచ్చితంగా పేరుతో ఎంచుకోవచ్చు:

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 మీకు ఎంచుకున్న title ను saved_entry గా ముద్రించాలి. ఈ output ద్వారా విధానం పనిచేస్తోందని నిర్ధారించవచ్చు. ఎందుకంటే save చేయాలంటే వ్రాయగలిగే /boot/grub/grubenv అవసరం, అయితే కొన్ని layouts లో అది మౌనంగా అందుబాటులో ఉండదు. Entry 0 menu లోని మొదటి entry, అంటే అత్యంత కొత్త kernel. ఇక్కడ numbers కంటే titles సురక్షితం. ఎందుకంటే kernel ను install చేసినప్పుడు లేదా తొలగించినప్పుడు numbers మారుతాయి.

headless serverలో autoremove ఎందుకు ప్రమాదకరం

APT స్వయంగా తొలగించకూడని kernel packages జాబితాను నిర్వహిస్తుంది. మీ జాబితాను చూడండి:

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

kernel packages మారిన ప్రతిసారి ఆ file మళ్లీ రూపొందుతుంది. ఇది ప్రస్తుతం నడుస్తున్న kernel మరియు ఇటీవలివాటిని రక్షిస్తుంది. సమస్య సమయానికి సంబంధించినది. కొత్త kernelలోకి reboot చేసిన వెంటనే sudo apt autoremove --purge ను అమలు చేస్తే, protected list ఇప్పటికే ముందుకు మారి ఉంటుంది. అందువల్ల మీరు ఆధారపడుతున్న పాత kernel ఇకపై రక్షిత జాబితాలో ఉండదు. keyboard ఉన్న machineలో ఇది అసౌకర్యం మాత్రమే. headless serverలో ఇది menu entry ఎంచుకోవడం మరియు rescue image నుంచి మీ diskను mount చేయడం మధ్య ఉన్న తేడా.

కనీసం రెండు kernels ఉంచండి. /boot కు తగిన స్థలం ఉంటే మూడు kernels ఉంచండి. uname -r ను పరిశీలించిన తర్వాత పాత kernelsను పేరుతో తొలగించండి. అప్పుడు ప్రస్తుతం నడుస్తున్న kernelను తొలగించే అవకాశం ఉండదు:

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

ఆ చివరి commandను తర్వాత మళ్లీ అమలు చేయండి. count మూడు నుంచి రెండుకు తగ్గితే అది cleanup. count ఒకటికి తగ్గితే, తదుపరి reboot సమయంలో outage సంభవించే అవకాశం ఉంది.

అప్‌గ్రేడ్‌కు ముందు snapshot తీసుకోండి

apt upgradeకు ముందు తీసుకున్న snapshot, ఏదైనా boot చేయడంపై ఆధారపడని ఏకైక recovery మార్గం. దాన్ని restore చేస్తే disk పాత kernel defaultగా ఉన్న స్థితికి తిరిగి వస్తుంది. ఆ తర్వాత console ఇప్పటికే తెరిచి ఉండగానే upgradeను మళ్లీ ప్రయత్నించవచ్చు. నడుస్తున్న machine యొక్క snapshots crash consistentగా ఉంటాయి. అంటే power అకస్మాత్తుగా ఆపివేయబడినట్లుగా disk స్థితిని capture చేస్తాయి. అందువల్ల మీ provider offline snapshotకు మద్దతు ఇస్తే, ముందుగా serverను shut down చేయండి. Snapshot backup కాదు. సాధారణంగా అది copy చేసే volume ఉన్న infrastructureపైనే ఉంటుంది. VPS snapshots మరియు నిజమైన backups మధ్య తేడా అర్థం చేసుకోవడం ముఖ్యం. Kernel కంటే పెద్ద failure వచ్చినప్పుడు ఏది మిమ్మల్ని రక్షిస్తుందో అదే నిర్ణయిస్తుంది.

Release upgrade సమయంలో ఇది మరింత ముఖ్యమైనది. ఎందుకంటే kernel, initramfs tools, bootloader, GRUB config అన్నీ ఒకే runలో మారుతాయి. మీరు ప్రారంభించబోయే Ubuntu 24.04 నుంచి 26.04కు upgradeకు వెంటనే ముందు snapshot తీసుకోండి. ముందు రాత్రి తీసుకోవద్దు. అప్పుడు restore point మీరు మార్చబోయే machine స్థితితో సరిపోతుంది.

కెర్నల్ ప్యాకేజీలను unattended-upgrades ఎలా నిర్వహిస్తుంది

Ubuntu యొక్క unattended-upgrades అడగకుండానే security updates ను ఇన్‌స్టాల్ చేస్తుంది. కెర్నల్ ప్యాకేజీలు కూడా మిగతా ప్యాకేజీల మాదిరిగానే security pocket ద్వారా వస్తాయి. దీనివల్ల రెండు విషయాలు జరుగుతాయి.

మొదట, కొత్త కెర్నల్ ఇన్‌స్టాల్ అవుతుంది. కానీ అది ప్రస్తుతం నడుస్తూ ఉండదు. కెర్నల్ boot సమయంలో మాత్రమే అమల్లోకి వస్తుంది. /var/run/reboot-required ఫైల్ కనిపిస్తుంది. reboot ను కోరినది ఏమిటో /var/run/reboot-required.pkgs తెలియజేస్తుంది. అయితే Unattended-Upgrade::Automatic-Reboot ను /etc/apt/apt.conf.d/50unattended-upgrades లో enable చేయకపోతే ఏదీ స్వయంచాలకంగా restart కాదు.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

రెండవది, ఈ విరామం అసలు కారణాన్ని కనిపించకుండా చేస్తుంది. ఒక server March లో కెర్నల్‌ను ఇన్‌స్టాల్ చేసి, పూర్తిగా సంబంధం లేని కారణంతో June లో reboot కావచ్చు. ఆ తర్వాత అది ప్రారంభం కాకపోవచ్చు. boot ను విఫలం చేసిన మార్పు మూడు నెలల పాతది. అందువల్ల ఆ రోజున మీరు చేసిన పనుల్లో కారణం కనిపించదు. మీరు ఇప్పుడు ఎదుర్కొంటున్న సమస్యకు కారణమైన కెర్నల్‌ను ఇన్‌స్టాల్ చేసిన run వివరాలు /var/log/apt/history.log లో కనిపిస్తాయి.

మీరు ఎంచుకున్న రోజున ఉద్దేశపూర్వకంగా reboot చేయండి. ఆ సమయంలో console window ఇప్పటికే తెరిచి ఉంచండి. ఈ ఒక్క అలవాటు mystery outage ను రెండు నిమిషాల menu selection గా మార్చుతుంది. automation కావాలి కానీ ఆకస్మిక reboot వద్దనుకుంటే automatic installs ను enable చేసి, automatic reboots ను disable గా ఉంచండి. ఖచ్చితమైన settings కోసం Ubuntuలో unattended-upgrades ను ఎలా configure చేయాలో చూడండి. sudo apt-mark hold linux-image-generic తో కెర్నల్ ప్యాకేజీలను hold చేస్తే అవి పూర్తిగా ఆగిపోతాయి. అదే సమయంలో కెర్నల్ security fixes కూడా ఆగిపోతాయి. కాబట్టి దీన్ని safety measure గా కాకుండా, మీరు అంగీకరించిన trade-off గా పరిగణించండి.

FAQ

కీబోర్డ్ లేని VPSలో పాత kernel ను ఎలా boot చేయాలి?

Provider console (VNC లేదా serial) తెరిచి, control panel నుంచి hard reset ప్రారంభించండి. శుభ్రంగా reboot చేయడానికి మీరు login చేయలేరు. Machine restart అవుతున్నప్పుడు Esc ను పదేపదే నొక్కండి. Legacy BIOS boot అయితే GRUB menu కనిపించేలా Shift ను నొక్కి పట్టుకోండి. "Advanced options for Ubuntu" ఎంచుకుని, తాజా kernel కంటే దిగువన ఉన్న entry ను ఎంచుకోండి. Login prompt వచ్చిన తర్వాత, మీరు ఏ kernel పై ఉన్నారో నిర్ధారించడానికి uname -r ను run చేయండి. ఇన్‌స్టాల్ అయి ఉన్న ఇతర kernels చూడటానికి dpkg -l 'linux-image-*' ను run చేయండి. System మళ్లీ నడుస్తున్న తర్వాత మాత్రమే diagnosis చేయండి.

నా VPSలో GRUB menu అసలు ఎందుకు కనిపించదు?

Cloud images సాధారణంగా /etc/default/grub.d/ లోని ఒక fileలో GRUB timeout ను 0గా set చేస్తాయి. అందువల్ల నొక్కాల్సిన అవకాశం లేకుండానే తాజా kernel ప్రారంభమవుతుంది. /etc/default/grub లో GRUB_TIMEOUT=10 మరియు GRUB_TIMEOUT_STYLE=menu ను set చేయండి. Menu serial consoleకు కూడా చేరేలా GRUB_TERMINAL="console serial" ను add చేయండి. తరువాత sudo update-grub ను run చేయండి. grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ తో verify చేయండి. ఆ directoryలోని files ప్రధాన file తర్వాత చదవబడతాయి. అందువల్ల అవి మీరు చేసిన editను override చేయవచ్చు.

/bootలో స్థలం ఖాళీ చేయడానికి పాత kernels తొలగించాలా?

అత్యంత పాత kernels ను తొలగించి, కనీసం రెండు kernels ఉంచండి. /boot పూర్తిగా నిండిపోవడం ప్రత్యేకమైన failure mode. అప్పుడు initramfs generation విఫలమవుతుంది. పనిచేసే image లేని kernel మాత్రమే మిగిలే ప్రమాదం ఉంటుంది. uname -r ను పరిశీలించిన తర్వాత exact package nameతో purge చేయండి. దాంతో ప్రస్తుతం నడుస్తున్న kernel ఎప్పుడూ candidateగా ఉండదు. Headless machineలో blanket sudo apt autoremove --purge ను నివారించండి. ప్రతి kernel మార్పు సమయంలో protected-kernel list మళ్లీ రూపొందుతుంది. సరైన సమయంలో కాకుండా command run అయితే, menuలో ఒకే kernel ఉండి fallback entry లేకుండా పోవచ్చు.

unattended-upgrades వల్ల boot విఫలమవుతుందా?

తరువాత boot కావడంలో విఫలమయ్యే kernelను అది install చేయవచ్చు. కానీ /etc/apt/apt.conf.d/50unattended-upgrades లో Unattended-Upgrade::Automatic-Reboot trueగా set చేసి ఉంటే తప్ప machineను restart చేయదు. సాధారణంగా failure ఆలస్యంగా కనిపిస్తుంది. Automatic run సమయంలో kernel install అవుతుంది, /var/run/reboot-required కనిపిస్తుంది, కానీ సమస్య కొన్ని వారాల తర్వాత మీరు చేసే తదుపరి reboot సమయంలో మాత్రమే బయటపడుతుంది. Consoleను ముందుగానే తెరిచి ఉంచి reboot చేయండి. మీరు boot చేస్తున్న kernelను ఏ run install చేసిందో తెలుసుకోవడానికి /var/log/apt/history.log ను చదవండి.