VPS తదుపరి boot కోసం kernel ను ఎలా pin చేయాలి

మీ VPS తదుపరి ఏ kernel తో boot అవుతుందో నిర్ణయించేది ఒక generated file, /boot/grub/grub.cfg. ఆ file ను మీరు ఎప్పుడూ నేరుగా edit చేయకండి. దానికి సంబంధించిన input files ను edit చేసి, దాన్ని మళ్లీ generate చేయాలి. Ubuntu cloud image లో ఆ input files లో ఒకటి image vendor నుంచి వస్తుంది. అది menu selection ను పట్టించుకోకుండా చేయవచ్చు. అందుకే rented server పై GRUB_DEFAULT=1 తర్వాత update-grub అమలు చేసినా ఏ మార్పూ కనిపించదు. అదే రెండు దశలు laptop install లో పనిచేస్తాయి.

ఈ క్రమంలో పని చేయండి. Kernel ను ఎంచుకునే హక్కు మీకు ఉందో నిర్ధారించండి. Vendor జోడించిన files సహా ప్రతి input file ను చదవండి. Generated output ను చదివి, అందులో నిజంగా ఎన్ని entries ఉన్నాయో లెక్కించండి. ఆ తర్వాత మాత్రమే pinning method ను ఎంచుకోండి. SSH ద్వారా మాత్రమే చేరగల machine పై ఈ విషయాన్ని తప్పుగా నిర్ణయిస్తే rescue console అవసరం కావచ్చు. అందువల్ల ఈ page చివరలో ఉన్న సురక్షితమైన పద్ధతులే సాధారణంగా సరైన ఎంపికలు.

First check that the kernel is yours to pin

uname -r
systemd-detect-virt
ls -1 /boot/vmlinuz-*

systemd-detect-virt printing kvm, qemu or xen means you run your own kernel and everything below applies. Printing lxc or openvz means your server shares the host's kernel, so there is no bootloader of yours and nothing to pin. In that case uname -r reports a version that does not appear in /boot/vmlinuz-* at all, because the running kernel belongs to the host and no setting on your disk can change it.

ls -1 /boot/vmlinuz-* is the real list of kernels you can choose between. If it holds one line, the previous kernel is already deleted, and no bootloader setting brings it back. That usually happens during an autoremove, which is worth understanding before you clean up old kernels on Ubuntu on a box you care about.

మీరు సవరించే ఫైల్‌ను GRUB చదవదు

/etc/default/grub లో సాధారణ shell variable assignments ఉంటాయి. ఇది input file. /boot/grub/grub.cfg output file. ఇది # DO NOT EDIT THIS FILE మరియు ఆ కారణంతో ప్రారంభమవుతుంది. మీరు output file లో నేరుగా రాసినది, తదుపరి kernel package install లేదా remove చేసినప్పుడు పోతుంది. కారణం, ఆ package scripts దాన్ని మళ్లీ రూపొందిస్తాయి.

cat /usr/sbin/update-grub

update-grub ఒక wrapper. ఇది grub-mkconfig -o /boot/grub/grub.cfg ను అమలు చేస్తుంది. grub-mkconfig -o /boot/grub/grub.cfg variables ను చదివి, /etc/grub.d/ లోని ప్రతి script ను అమలు చేసి, ఫలితాన్ని రాస్తుంది. రెండు commands, ఒకే దిశ: inputs లోపలికి వెళ్తాయి, grub.cfg బయటకు వస్తుంది.

మీ సెట్టింగ్‌ను ఏది override చేస్తుంది: /etc/default/grub.d

grep -rn '^[^#]' /etc/default/grub /etc/default/grub.d/

రెండవ path‌ను చాలామంది గమనించరు. grub-mkconfig ముందుగా /etc/default/grub ను source చేస్తుంది. తరువాత /etc/default/grub.d/ లోని ప్రతి *.cfg file ను glob క్రమంలో source చేస్తుంది. దీన్ని చేసే code ను చదవండి:

grep -n 'default/grub' /usr/sbin/grub-mkconfig

Sourcing సాధారణ shell విధానమే. అందువల్ల చివరి assignment అమలులో ఉంటుంది. Ubuntu cloud images ఆ directory లో files ను అందిస్తాయి. మీ file ఇప్పటికే చదివిన తరువాత అవి timeout, kernel command line వంటి విలువలను సెట్ చేస్తాయి. /etc/default/grub లోని మీ GRUB_TIMEOUT=10 ను కొన్ని క్షణాల తరువాత vendor file overwrite చేస్తుంది. ఆ file విలువను 0గా సెట్ చేస్తుంది. పై grep మీ image లోని ఖచ్చితమైన assignments ను చూపిస్తుంది. కాబట్టి ఈ వాక్యాన్ని నమ్మకుండా వాటినే పరిశీలించండి.

దీని ఆధారంగా పాటించాల్సిన నియమం: మీ స్వంత settings ను చివరలో sort అయ్యే file లో ఉంచండి. ఉదాహరణకు /etc/default/grub.d/99-local.cfg ను ఉపయోగించండి. /etc/default/grub ను నేరుగా edit చేయవద్దు. అప్పుడు image అందించే ఏ file కూడా మీ తరువాత load కాదు.

GRUB_FORCE_PARTUUID వల్ల menu selection ఎందుకు పనికిరాకుండా పోతుంది

grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/
grep -n GRUB_FORCE_PARTUUID /etc/grub.d/10_linux
sudo grep -n 'root=PARTUUID' /boot/grub/grub.cfg

GRUB_FORCE_PARTUUID generator కు root filesystem ను partition UUID ద్వారా కనుగొనమని చెబుతుంది. ఇది boot సమయంలో filesystem UUID కోసం శోధించకుండా, నేరుగా kernel command line పై root=PARTUUID=... గా వ్రాయబడుతుంది. image vendor దీన్ని సెట్ చేస్తుంది, ఎందుకంటే తాను నిర్మించని hardware పై కూడా ఒకే disk image విశ్వసనీయంగా boot కావడానికి ఇది సహాయపడుతుంది. రెండవ grep లో /etc/grub.d/10_linux లో ఈ variable పై చర్య తీసుకునే code కనిపిస్తుంది. ఆ script మీ స్వంత disk లో ఉంటుంది. మీ image ఎలా పనిచేస్తుందో నిర్ణయించే ప్రామాణిక ఆధారం అదే.

ఇక్కడ ముఖ్యమైనది దాని ఫలితం. ఈ మార్గంలో generator, install చేసిన kernels యొక్క పూర్తి జాబితాకు బదులుగా నేరుగా boot entry ను వ్రాస్తుంది. చివరికి మీ వద్ద ఎన్ని entries ఉన్నాయో లెక్కించండి.

sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg
sudo grep -nE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg

లెక్క 1 అయితే, ఎంచుకోవడానికి రెండవ entry ఉండదు. అందువల్ల GRUB_DEFAULT=1 లేని entry ను సూచిస్తుంది. GRUB దాన్ని పరిష్కరించలేకపోతుంది. కాబట్టి అది మొదటి entry ను boot చేస్తుంది. మీరు నివారించాలనుకున్న కొత్త kernel అదే entry. grub-set-default కూడా సహాయపడదు, ఎందుకంటే సమస్య default లో లేదు. మీరు ఎంచుకోవాలనుకుంటున్న menu అసలు generate కాలేదు.

పూర్తి menu ను తిరిగి పొందడానికి vendor file ను తాత్కాలికంగా మరోచోటుకు తరలించండి. తరువాత ఫలితాన్ని పరిశీలించి మాత్రమే మార్పును అమలు చేయండి. grub-mkconfig ను -o లేకుండా ఉపయోగిస్తే అది standard output కు వ్రాస్తుంది. Disk పై ఏ మార్పూ చేయదు.

sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '
sudo mkdir -p /root/grub-backup
sudo mv /etc/default/grub.d/<the file your grep named> /root/grub-backup/
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '

లెక్క 1 నుంచి అనేక entries కు పెరిగితే, forcing తొలగించిన తర్వాత entries కనిపిస్తున్నాయని అర్థం. ఇప్పటివరకు ఏదీ వ్రాయబడలేదు. రెండవ లెక్క సరైనదిగా కనిపించకపోతే file ను తిరిగి ఉంచండి. మీ provider యొక్క image root filesystem ను గుర్తించడానికి forced PARTUUID ను ఉపయోగిస్తుంది. దాన్ని తొలగిస్తే machine search path కు మారుతుంది. update-grub ను వాస్తవంగా అమలు చేయడానికి ముందు snapshot తీసుకోండి.

ఒక చెడు kernel వల్ల కలిగే సమస్యను ఒక్కసారి అధిగమించడమే మీ లక్ష్యం అయితే, ఇక్కడే ఆపి కింద ఉన్న సురక్షితమైన ఎంపికలను ఉపయోగించండి. ఒక్క upgrade నుంచి బయటపడటానికి remote server లో boot menu ను మళ్లీ నిర్మించడం, సమస్య విలువకన్నా ఎక్కువ ప్రమాదాన్ని కలిగిస్తుంది.

పిన్స్‌గా ఉపయోగించడానికి entry సంఖ్యలు ఎందుకు సరైనవి కావు

GRUB_DEFAULT ఒక సంఖ్య, title లేదా identifier ను స్వీకరిస్తుంది. Numbers top-level entries ను 0 నుంచి లెక్కిస్తాయి. Nested entry కోసం > separator గా ఉపయోగించబడుతుంది. అందువల్ల GRUB_DEFAULT="1>2" అంటే index 1 వద్ద ఉన్న submenu లోని index 2 entry అని అర్థం.

Indices మారుతాయి. 10_linux kernels ను కొత్తవి ముందుగా చూపిస్తుంది. కాబట్టి ఒక kernel ను install చేస్తే అంతకంటే పాత ప్రతి entry ఒక స్థానం కిందికి వెళ్తుంది. ఒక kernel ను remove చేస్తే అవి ఒక స్థానం పైకి వస్తాయి. మీరు జాగ్రత్తగా అమర్చిన 1>2 ఆ మార్పు తర్వాత కూడా resolve అవుతుంది. కానీ ఇప్పుడు అది వేరే kernel ను సూచిస్తుంది. ఎలాంటి error రాదు. ఎలాంటి warning కూడా కనిపించదు. Reboot చేసిన తర్వాతే విషయం తెలుస్తుంది.

Identifiers మారవు, ఎందుకంటే ప్రతి identifier లో kernel version ఉంటుంది. మీ identifier ను ఇలా చూడండి:

sudo awk -F"'" '/menuentry_id_option/ {print $2, "==>", $4}' /boot/grub/grub.cfg

Output లోని మొదటి కొన్ని lines ను పట్టించుకోకండి. అవి header లో నిర్వచించిన variable ను చూపిస్తాయి. ఆ తర్వాత ఎడమ వైపు reader చూసే title ఉంటుంది. కుడి వైపు tools కు pass చేయాల్సిన identifier ఉంటుంది. Submenu లోని entry కోసం submenu identifier మరియు entry identifier ను > తో కలపాలి. వాటి క్రమం ఇదే ఉండాలి. Numeric form లో ఉన్న క్రమాన్ని కూడా ఇదే విధంగా అనుసరిస్తుంది.

grub-reboot తో మునుపటి kernel ను ఒక్కసారి boot చేయండి

Remote server‌లో ఒక్కసారి చేసే ఎంపిక సరైన విధానం, ఎందుకంటే అది స్వయంగా రద్దవుతుంది. grub-reboot, /boot/grub/grubenv లోకి next_entry ను వ్రాస్తుంది. GRUB ఆ variable ను చదివి, దాన్ని clear చేసి, ఏదైనా boot చేయడానికి ముందే clear చేసిన value ను save చేస్తుంది. అందువల్ల panic అయ్యే kernel ను తదుపరి boot‌లో మళ్లీ ప్రయత్నించదు. ఒకసారి ప్రయత్నం జరుగుతుంది. ఆ తర్వాత machine స్వయంగా సాధారణ default కు తిరిగి వస్తుంది.

ముందుగా మీ generated config ఆ variable ను అసలు చదువుతుందో లేదో నిర్ధారించండి:

sudo grep -n -B2 -A5 'next_entry' /boot/grub/grub.cfg

మీకు load_env line మరియు next_entry నుంచి default ను set చేసే block కనిపించాలి. grep ఏ output ఇవ్వకపోతే, boot సమయంలో మీ image grubenv ను అసలు చదవడం లేదని అర్థం. అప్పుడు grub-reboot shell‌లో అంగీకరించబడుతుంది, కానీ bootloader దాన్ని పట్టించుకోదు. మునుపటి section‌లో కనిపించిన అదే forced direct boot path ఇక్కడ రెండో చోట కనిపిస్తోంది.

sudo grub-reboot '<the identifier you copied>'
sudo grub-editenv list

grub-editenv list ఇప్పుడు మీరు ఇచ్చిన value ను యథాతథంగా కలిగి ఉన్న next_entry= line ను చూపాలి. మీ provider console ను browser tab‌లో తెరిచి ఉంచండి. తర్వాత reboot చేసి ఫలితాన్ని పరిశీలించండి.

sudo reboot

uname -r

uname -r పాత version ను చూపితే pin పనిచేసిందని అర్థం. కొత్త version ను చూపితే identifier resolve కాలేదో లేదా grubenv చదవబడటం లేదో అర్థం. ఏ పరిస్థితిలోనైనా machine పనిచేస్తూనే ఉంటుంది. ఒక్కసారి ఉపయోగించే విధానాన్ని ఎంచుకోవడానికి ఇదే కారణం.

GRUB_DEFAULT=savedతో ఎంపికను స్థిరంగా ఉంచండి

GRUB_DEFAULT=saved డిఫాల్ట్ విలువను grubenv లోని saved_entry నుంచి తీసుకుంటుంది. ఆ విలువను grub-set-default తో సెట్ చేయాలి. Kernel install చేసిన తర్వాత కూడా ఇది అలాగే ఉంటుంది. ఎందుకంటే update-grub, grub.cfg ను తిరిగి రాస్తుంది కానీ grubenv ను ఎప్పుడూ మార్చదు.

echo 'GRUB_DEFAULT=saved' | sudo tee /etc/default/grub.d/99-local.cfg
sudo update-grub
sudo grub-set-default '<the identifier you copied>'
sudo grub-editenv list
sudo grep -n 'set default' /boot/grub/grub.cfg

చివరి command తప్పనిసరిగా set default="${saved_entry}" ను print చేయాలి. అది set default="0" ను print చేస్తే, మీ file తర్వాత source అయిన ఏదో ఒకటి GRUB_DEFAULT ను మళ్లీ literal value కు సెట్ చేసింది. అందువల్ల /etc/default/grub.d/ ను మళ్లీ జాబితా చేసి, 99-local.cfg నిజంగా చివరగా sort అవుతోందో లేదో తనిఖీ చేయండి.

GRUB_SAVEDEFAULT=true వేరే setting. దీన్ని ప్రస్తుత setting తో గందరగోళపరచడం సులభం. మీరు ఇప్పుడే boot చేసిన entry ను కొత్త default గా ఇది save చేస్తుంది. అందువల్ల default, చివరిగా విజయవంతమైన boot ను అనుసరిస్తుంది. Serverలో unattended reboot జరిగితే మీ pin నిశ్శబ్దంగా మారవచ్చు. అదే మీకు కావాలనుకుంటే తప్ప దీన్ని off గానే ఉంచండి.

Identifier ద్వారా చేసిన pin ఒక సందర్భంలో ఇప్పటికీ విఫలమవుతుంది. అది సూచించే kernel ను తొలగిస్తే identifier resolve కాదు. అప్పుడు default మొదటి entryకి తిరిగి వస్తుంది. కాబట్టి ఆ package ను కూడా hold చేయండి లేదా ఆ kernel autoremove నుంచి మినహాయించండి.

ప్రొవైడర్ కన్సోల్‌లో మెనూను చూపించడం

ఇంటరాక్టివ్‌గా ఎంపికలు చేయాలంటే మెనూ తెరపై కనిపించాలి. అయితే cloud images దీన్ని దాచిపెడతాయి. ఇవి చివరగా sort అయ్యే ఫైల్‌లో చేర్చి, తరువాత sudo update-grub ను అమలు చేయండి.

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

GRUB_TIMEOUT_STYLE=hidden మరియు GRUB_TIMEOUT=0 రెండింటినీ కలిపి ఉపయోగించినా ఏదీ కనిపించదు. అందువల్ల కన్సోల్‌ను పర్యవేక్షిస్తున్న వ్యక్తికి kernel messages వెంటనే ప్రారంభమైనట్లు కనిపిస్తుంది. దీంతో bootloader దాటవేయబడిందని వారు భావించవచ్చు. GRUB_RECORDFAIL_TIMEOUT అనేది boot పూర్తికాని సందర్భంలో ఉపయోగించే ప్రత్యేక timeout. cloud images దీన్ని కూడా 0గా సెట్ చేస్తాయి. అందుకే boot అవ్వడంలో విఫలమైన server కూడా ఆగి మీ కోసం వేచి ఉండదు.

మీ provider graphical console బదులుగా serial console ఇస్తే, ఇంకా ఏమీ కనిపించకపోవచ్చు. GRUB మీకు కనిపించని terminal కు output రాస్తోంది. రెండు lines ను కలిపి చేర్చండి. మొదటిది outputs ను ఎంచుకుంటుంది. రెండవది port ను configure చేస్తుంది:

GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

ఇకపై ప్రతి boot కు పది seconds జోడించబడతాయి. పని పూర్తయిన తర్వాత timeout ను తిరిగి 0గా సెట్ చేయండి.

బూట్‌లోడర్‌ను సవరించడంకంటే సురక్షితమైన మార్గాలు

మీరు SSH ద్వారా మాత్రమే చేరగల యంత్రంలో బూట్‌లోడర్ ఇన్‌పుట్‌ను మార్చడం ఈ పేజీలోని అత్యధిక ప్రమాదం ఉన్న ఎంపిక. తక్కువ ప్రమాదం ఉన్న మార్గాలు ఉన్నాయి. అవి సాధారణంగా అసలు సమస్యను పరిష్కరిస్తాయి.

kernel packages ను hold చేయండి. “నాకు కొత్త kernel ఇవ్వకూడదు” అనేదే లక్ష్యమైతే, ఆ విషయాన్ని bootloader కు కాకుండా package manager కు తెలియజేయండి.

apt list --installed 2>/dev/null | grep -E '^linux-(image|headers|generic|virtual|kvm|aws|azure|gcp|oracle)'
sudo apt-mark hold linux-image-virtual linux-headers-virtual
apt-mark showhold

మొదటి command చూపించిన పేర్లనే ఉపయోగించండి. Cloud images లో సాధారణంగా generic flavour బదులుగా virtual లేదా kvm flavour ఇన్‌స్టాల్ అవుతుంది. Image refresh సమయంలో కొత్త kernel కనిపించి, release మీకు తెలియకుండా మారిందని అనుమానిస్తే, అలా జరగలేదు. point release అంటే మీరు ఇప్పటికే పొందిన updates ను కొత్త install media లో కలిపిన విడుదల; అందువల్ల ఇప్పటికే patched అయిన server కు కొన్ని వారాల క్రితం అందించని దానిని అది ఇవ్వదు. Held package ను apt upgrade skip చేస్తుంది. దాన్ని The following packages have been kept back: తో స్పష్టంగా చూపిస్తుంది. Ubuntu లో unattended upgrades కూడా దాన్ని skip చేస్తాయి. అయితే దీని ప్రభావం ఉంటుంది: held kernel కు security fixes అందవు. కాబట్టి దీన్ని తేదీతో కూడిన తాత్కాలిక విరామంగా పరిగణించి, sudo apt-mark unhold తో మళ్లీ విడుదల చేయండి. ఒక kernel లో సమస్య ఉందని కాకుండా, reboots వల్ల downtime ఏర్పడుతుందని kernel updates ను నివారిస్తుంటే, VPS లో live kernel patching ఆ సమస్యకు వేరే పరిష్కారం ఇస్తుంది.

upgrade కు ముందు snapshot తీసుకోండి. Snapshot ను కొన్ని నిమిషాల్లో restore చేయవచ్చు. Console లో typing అవసరం ఉండదు. అర్థాంతరంగా అమలైన bootloader మార్పు జరిగే ప్రమాదం కూడా ఉండదు. Snapshot తీసుకోండి, upgrade చేయండి, reboot చేయండి, verify చేయండి. కొత్త kernel సరిగ్గా పనిచేయకపోతే rollback చేయండి. అప్పుడు boot path ముందున్నట్లుగానే ఉంటుంది.

ఇప్పటికే down అయిన యంత్రానికి console లేదా rescue image ఉపయోగించండి. Server boot కాకపోతే, bootloader config లోనే దాన్ని సరిచేయలేరు. ఆ recovery path కు ప్రత్యేక విధానం ఉంటుంది: kernel update తర్వాత VPS boot కాకపోతే ఏమి చేయాలి.

ఏది విఫలమవుతుంది, మీరు చూడబోయే సందేశం

/boot/grub/grub.cfg లో చేసిన మీ మార్పు కనిపించదు. Kernel package ఇన్‌స్టాల్ చేయబడింది లేదా తొలగించబడింది, దాని maintainer script update-grub ను అమలు చేసింది, మరియు inputs ఆధారంగా ఆ file మళ్లీ రూపొందించబడింది. # DO NOT EDIT THIS FILE header రెండు input locations పేర్లను చూపిస్తుంది. ఆ locations లో మార్పులు చేయండి.

grub-editenv: error: environment block too small. /boot/grub/grubenv కనిపించడం లేదు లేదా పూర్తిగా లేదు. sudo grub-editenv /boot/grub/grubenv create తో దాన్ని మళ్లీ సృష్టించండి. తరువాత మీ value ను మళ్లీ సెట్ చేసి, sudo grub-editenv list తో నిర్ధారించండి.

Pinned kernel VFS: Unable to mount root fs on unknown-block(0,0) తో panic అవుతుంది. మీరు pin చేసిన entry diskలో ఇక లేదు ఉన్న kernel లేదా initrd ను సూచిస్తోంది. సాధారణంగా identifier grubenv లో అలాగే ఉండగా package తొలగించబడటం దీనికి కారణం. పనిచేసే entryతో console boot చేసి recovery చేయండి. తరువాత పాత value ను clear చేయండి.

మీరు మార్పు వస్తుందని ఊహించిన reboot తర్వాత uname -r మారలేదు. ఈ మూడు విషయాలను వరుసగా తనిఖీ చేయండి: grub-editenv list ఇప్పటికీ మీ value ను చూపిస్తుందా, లేదా అది ఉపయోగించబడిందా; మీరు సెట్ చేసిన identifier ప్రస్తుత grub.cfg లో కనిపిస్తుందా; మీరు సెట్ చేసిన variable ను చదివే set default line grub.cfg లో ఉందా. ఈ మూడింటిలో ఒకటి ప్రతిసారీ కారణాన్ని వివరిస్తుంది.

Crash తర్వాత menu స్వయంగా కనిపించింది. GRUB విఫలమైన boot ను grubenv లో recordfail=1 గా నమోదు చేస్తుంది. దీనివల్ల తరువాతి boot సమయంలో menu కనిపిస్తుంది, తద్వారా ఒక వ్యక్తి జోక్యం చేసుకోవచ్చు. Machine సరిగ్గా పనిచేస్తున్న తర్వాత sudo grub-editenv /boot/grub/grubenv unset recordfail తో దాన్ని clear చేయండి.

గుర్తుంచుకోవాల్సిన ముఖ్యమైన ఒకే వాక్యం: మీరు edit చేసే file, GRUB చదివే file కాదు. Cloud imageలో ఈ రెండింటి మధ్య ఉన్న తేడానే గందరగోళానికి కారణం. ముందుగా generated config ను చదవండి. ఈ పేజీలోని ప్రతి నిర్ణయం అది వాస్తవంగా ఏమి చెబుతుందనే దానిపై ఆధారపడి ఉంటుంది.

FAQ

GRUB_DEFAULT=1 మార్చినా నా VPS ఏ kernel నుంచి boot అవుతుందో ఎందుకు మారదు?

Ubuntu cloud image లో రూపొందించిన /boot/grub/grub.cfg సాధారణంగా ఒకే boot entry ను కలిగి ఉంటుంది. అందువల్ల index 1 ఏదినీ సూచించదు, కాబట్టి GRUB మొదటి entry కి fallback అవుతుంది. దీన్ని sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg తో నిర్ధారించండి. Count 1 రావడమే కారణాన్ని నిర్ధారిస్తుంది. దీనికి కారణం image vendor /etc/default/grub.d/ కింద ఉన్న ఒక file లో సెట్ చేసిన GRUB_FORCE_PARTUUID. ఇది అన్ని installed kernels కోసం పూర్తి జాబితాను నిర్మించకుండా generator ను direct boot path పై నడుపుతుంది. ఆ file ను grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ తో కనుగొనండి.

మునుపటి kernel ను ఒక్కసారి మాత్రమే ఎలా boot చేయాలి?

మీ స్వంత grub.cfg నుంచి identifier ను copy చేసి sudo grub-reboot '<identifier>' నడపండి. తరువాత provider console ఇప్పటికే open చేసి ఉంచి reboot చేయండి. GRUB boot చేయడానికి ముందు next_entry ను clear చేస్తుంది. అందువల్ల ఈ ఎంపిక ఒక్క ప్రయత్నానికి మాత్రమే వర్తిస్తుంది, panic అయ్యే kernel ను మళ్లీ ప్రయత్నించదు. విలువ నమోదు అయిందో లేదో sudo grub-editenv list తో నిర్ధారించండి. దీనిపై ఆధారపడే ముందు sudo grep -n next_entry /boot/grub/grub.cfg నడపండి. ఎందుకంటే config లో grubenv ఎప్పుడూ load కాకపోతే command ను ఎలాంటి error లేకుండా విస్మరిస్తుంది.

Entry number ఆధారంగా pin చేయాలా, identifier ఆధారంగా pin చేయాలా?

Identifier ఆధారంగా pin చేయాలి. 10_linux list ను newest first గా మళ్లీ నిర్మిస్తుంది. అందువల్ల ఏ kernel ను install చేసినా లేదా remove చేసినా entry numbers మారతాయి. పాత 1>2 ఎలాంటి warning లేకుండా వాస్తవమైన కానీ తప్పు entry కి resolve కావచ్చు. Identifiers లో kernel version ఉంటుంది. కాబట్టి అవి మీరు ఉద్దేశించిన kernel కి match అవుతాయి లేదా resolve కావు. వాటిని sudo grep -n menuentry_id_option /boot/grub/grub.cfg తో list చేసి, ప్రతి entry line లో తరువాత వచ్చే quoted string ను copy చేయండి.

Bootloader ను మార్చడం కంటే kernel package ను hold చేయడం సురక్షితమా?

సాధారణ లక్ష్యానికి అవును. sudo apt-mark hold linux-image-virtual linux-headers-virtual కొత్త kernel రావడాన్ని పూర్తిగా ఆపుతుంది. అందువల్ల boot path మారదు, మీకు అందుబాటులో లేకపోవచ్చిన console నుంచి తప్పు జరిగే అవకాశమూ ఉండదు. ముందుగా మీ స్వంత box లో install అయిన flavour names ను apt list --installed తో చూడండి. తరువాత hold అమలులో ఉందో apt-mark showhold తో నిర్ధారించండి. అయితే held kernel కు security fixes అందవు. కాబట్టి hold అమలు చేయడానికి ముందు sudo apt-mark unhold ఎప్పుడు నడపాలో నిర్ణయించండి.