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

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

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

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

ఏదైనా మార్చే ముందు మీ console లో కనిపిస్తున్న సమాచారాన్ని చదవండి. ఆ స్క్రీన్‌లోని text మీరు ఎదుర్కొంటున్న failure class ను నిర్ణయిస్తుంది. "boot కావడం లేదు" అనే స్థితి ఉన్న రెండు servers కు పరస్పర విరుద్ధమైన fixes అవసరం కావచ్చు.

SSH పనిచేయనప్పుడు console ను ఎలా తెరవాలి?

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

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

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

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

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

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

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

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

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

GRUB menu కనిపించకపోతే ఏమి చేయాలి?

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

దీనికి విరుద్ధమైన పరిస్థితి కూడా ఉంటుంది. Menu తెరపై కనిపిస్తూ, input కోసం వేచి ఉండవచ్చు. అప్పుడు system hang అయినట్లు అనిపిస్తుంది. GRUB boot విఫలమైందని నమోదు చేస్తుంది. తదుపరి start సమయంలో ఎవరైనా key నొక్కే వరకు menu ను తెరిచి ఉంచవచ్చు. Keyboard లేని server లో ఆ వేచి ఉండటం ఎప్పటికీ ముగియదు. మీ 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 లోనైనా అది కనిపిస్తుంది. తరువాత వచ్చే boot messages కు console= kernel arguments ఇదే విధంగా పనిచేస్తాయి. ప్రతి boot కు పది seconds delay ఉండటం, తెల్లవారుజామున 2am సమయంలో మీరు నిజంగా చేరుకోగల menu కోసం చెల్లించాల్సిన చిన్న ధర.

నేను ఎదుర్కొంటున్నది ఏ వైఫల్య వర్గం?

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

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

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 కనిపిస్తుంది. ఆ 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 ను rebuild చేయాలి.

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

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

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

కెర్నల్ ప్యాకేజీ దెబ్బతిన్నదా, లేక initramfs దెబ్బతిన్నదా?

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

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

ఇన్‌స్టాల్ చేసిన ప్రతి version కు ఒక vmlinuz- మరియు దానికి సరిపోలే ఒక initrd.img- ఉండాలి. రెండింటి size కూడా నమ్మదగినదిగా ఉండాలి. initrd కనిపించకపోవడం, లేదా పక్కనున్న files కంటే దాని size చాలా తక్కువగా ఉండటం, 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

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

/boot నిండిపోయి ఉంటే ముందుగా ఖాళీ స్థలం కల్పించండి. తరువాత అవసరమైన version కోసం image ను మళ్లీ build చేసి, 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 తనిఖీ కోసం ఉపయోగించేది. సాధారణ size ఉన్న file కనిపిస్తే image ఇప్పుడు ఉంది. అయితే kernel image దెబ్బతిన్నా, లేదా dpkg -l లో package స్థితి ii కాకుండా మరేదైనా కనిపించినా, package ను మళ్లీ install చేయండి:

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

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

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

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 కు తిరిగి వెళ్లగలదు. Default ను మీరు విశ్వసించే kernel కు సెట్ చేసి, కొత్త kernel ను ఒక్క boot కోసం మాత్రమే ప్రారంభించండి. అది విఫలమైతే, panel నుంచి hard reset చేయడం ద్వారా console లో సరైన సమయాన్ని పాటించాల్సిన అవసరం లేకుండా పనిచేసే 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 ద్వారా mechanism సరిగ్గా పనిచేస్తోందని నిర్ధారించవచ్చు. ఎందుకంటే save చేయడానికి writable /boot/grub/grubenv అవసరం, కొన్ని layouts లో అది నిశ్శబ్దంగా writable గా ఉండకపోవచ్చు. Entry 0 menu లోని పైభాగపు entry, అంటే తాజా kernel. ఇక్కడ numbers కంటే titles సురక్షితం, ఎందుకంటే kernel ను install లేదా remove చేసిన ప్రతిసారీ numbers మారుతాయి.

headless సర్వర్‌లో autoremove ఎందుకు ప్రమాదకరం

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

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

kernel packages మారిన ప్రతిసారి ఆ ఫైల్ మళ్లీ రూపొందుతుంది. ఇది ప్రస్తుతం నడుస్తున్న kernel మరియు ఇటీవలి kernelలను రక్షిస్తుంది. సమస్య సమయం విషయంలో ఉంటుంది. కొత్త kernelలోకి reboot చేసిన వెంటనే sudo apt autoremove --purge ను అమలు చేస్తే, protected list ఇప్పటికే ముందుకు మారి ఉంటుంది. అందువల్ల మీరు ఆధారపడుతున్న పాత kernel ఇక protected గా ఉండదు. 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 ఇప్పటికే తెరిచి ఉండటంతో మీరు అప్‌గ్రేడ్‌ను మళ్లీ ప్రయత్నించవచ్చు. నడుస్తున్న machine యొక్క snapshotలు crash consistent గా ఉంటాయి. అంటే power అకస్మాత్తుగా నిలిచిపోయినట్లుగా disk స్థితిని capture చేస్తాయి. అందువల్ల మీ provider offline snapshot కు మద్దతిస్తే ముందుగా server ను shutdown చేయండి. Snapshot backup కాదు. సాధారణంగా అది copy చేసే volume ఉన్న infrastructure పైనే ఉంటుంది. VPS snapshotలు మరియు నిజమైన backupల మధ్య తేడా తెలుసుకోవడం ముఖ్యం. Kernel కంటే పెద్ద వైఫల్యం వచ్చినప్పుడు మిమ్మల్ని ఏది రక్షిస్తుందో అదే నిర్ణయిస్తుంది.

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

అత్యంత పాత kernel లను తొలగించి, కనీసం రెండు kernel లను ఉంచండి. /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 నడిస్తే, menu లో fallback entry లేకుండా ఒకే kernel మిగిలే అవకాశం ఉంది.

unattended-upgrades నా boot ను విఫలం చేయగలదా?

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