SSD Nodes Learn 🎉 VPS $5.50/నెల నుండి

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

Ubuntu cloud image లో GRUB_DEFAULT పనిచేయకపోవడానికి కారణం తెలుసుకోండి. నిజమైన GRUB menu entries చదివి, rescue console ప్రమాదం లేకుండా తదుపరి boot kernel ను pin చేయండి.

మీ VPS తదుపరి bootలో ఏ kernel ప్రారంభమవుతుందో నిర్ణయించేది ఏమిటి

మీ VPS తదుపరి bootలో ఏ kernel ప్రారంభమవుతుందో ఒకే 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 పద్ధతిని ఎంచుకోండి. SSH ద్వారా మాత్రమే చేరుకోగల machine లో ఈ విషయాన్ని తప్పుగా చేస్తే rescue console అవసరం అవుతుంది. అందువల్ల ఈ పేజీ చివర ఇచ్చిన సురక్షితమైన పరిష్కారాలనే ముందుగా పరిగణించండి. అవే చాలా సందర్భాల్లో సరైనవి.

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 ఫైల్. /boot/grub/grub.cfg output ఫైల్. ఇది # DO NOT EDIT THIS FILE మరియు కారణంతో ప్రారంభమవుతుంది. output ఫైల్‌లో మీరు రాసిన ఏదైనా విషయం, తదుపరి kernel package install లేదా remove సమయంలో తొలగిపోతుంది. కారణం, ఆ package scripts ఈ ఫైల్‌ను మళ్లీ generate చేస్తాయి.

cat /usr/sbin/update-grub

update-grub ఒక wrapper. ఇది grub-mkconfig -o /boot/grub/grub.cfg ను run చేస్తుంది. grub-mkconfig -o /boot/grub/grub.cfg variables ను చదివి, /etc/grub.d/ లోని ప్రతి script ను run చేసి, ఫలితాన్ని రాస్తుంది. రెండు 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 order లో 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 కూడా మీ తర్వాత అమలు కాలేదు.

GRUB_FORCE_PARTUUID వల్ల మెను ఎంపిక ఎందుకు ప్రభావం చూపదు

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

ఇక్కడ ముఖ్యమైనది దాని ఫలితం. ఈ మార్గంలో generator, ఇన్‌స్టాల్ చేసిన 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 దాన్ని resolve చేయలేకపోతుంది. కాబట్టి మొదటి entry ను boot చేస్తుంది. అది మీరు నివారించాలనుకున్న కొత్త kernel అవుతుంది. grub-set-default కూడా సహాయపడదు, ఎందుకంటే default సమస్య కాదు. మీరు ఎంచుకోవాలనుకుంటున్న menu అసలు generate కాలేదు.

పూర్తి menu ను తిరిగి పొందడానికి vendor file ను తాత్కాలికంగా పక్కకు తరలించండి. Commit చేయడానికి ముందు ఫలితాన్ని preview చేయండి. 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 ను దాటి system ను నడపడం మాత్రమే మీ లక్ష్యమైతే, ఇక్కడే ఆపండి. కింద ఉన్న మరింత సురక్షితమైన options ను ఉపయోగించండి. ఒక upgrade నుంచి బయటపడటానికి remote server పై boot menu ను rebuild చేయడం, ఈ సమస్యకు అవసరమైన దానికంటే ఎక్కువ ప్రమాదాన్ని కలిగిస్తుంది.

ఎంట్రీ సంఖ్యలకు pin చేయడం ఎందుకు తప్పు

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

Indices స్థిరంగా ఉండవు. 10_linux kernels ను newest first క్రమంలో చూపిస్తుంది. కాబట్టి కొత్త kernel install చేస్తే పాత ప్రతి entry ఒక స్థానం కిందికి వెళ్తుంది. Kernel తొలగిస్తే అవి ఒక స్థానం పైకి వస్తాయి. మీ జాగ్రత్తగా రూపొందించిన 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కు అందించే 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 చేసిన విలువను 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, మీరు ఇచ్చిన విలువను ఖచ్చితంగా కలిగి ఉన్న next_entry= line ను చూపాలి. మీ provider console ను browser tabలో తెరిచి, తరువాత reboot చేసి ఫలితాన్ని తనిఖీ చేయండి.

sudo reboot
uname -r

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

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

GRUB_DEFAULT=saved డిఫాల్ట్ విలువను grubenv లోని saved_entry నుంచి తీసుకుంటుంది. ఆ విలువను grub-set-default తో సెట్ చేయాలి. ఇది kernel installs తర్వాత కూడా అలాగే ఉంటుంది. ఎందుకంటే 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}" ను ముద్రించాలి. అది set default="0" ను ముద్రిస్తే, మీ file తర్వాత source అయిన ఏదో ఒకటి GRUB_DEFAULT ను మళ్లీ literal value గా సెట్ చేసింది. అందువల్ల /etc/default/grub.d/ ను మళ్లీ జాబితా చేసి, 99-local.cfg నిజంగా చివరిగా sort అవుతోందో తనిఖీ చేయండి.

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

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

provider consoleలో menu ను చూపించడం

ఇంటరాక్టివ్‌గా ఎంపిక చేయాలంటే screenపై menu కనిపించాలి. Cloud images దీన్ని దాచిపెడతాయి. ఈ పంక్తులను చివరిగా sort అయ్యే fileలో ఉంచి, తరువాత sudo update-grub ను run చేయండి.

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

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

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

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

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

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

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 ను install చేస్తాయి. Hold చేసిన package ను apt upgrade దాటవేస్తుంది. దీన్ని The following packages have been kept back: తో ప్రకటిస్తుంది. Ubuntu లోని unattended upgrades కూడా దాన్ని దాటవేస్తాయి. దీనికి నిజమైన ప్రతికూలత ఉంది: hold చేసిన kernel కు security fixes అందవు. అందువల్ల దీన్ని గడువు తేదీతో కూడిన తాత్కాలిక విరామంగా పరిగణించి, sudo apt-mark unhold తో మళ్లీ విడుదల చేయండి. ఒక kernel లో సమస్య ఉన్నందువల్ల కాకుండా, reboot వల్ల downtime ఏర్పడుతుందనే కారణంతో kernel updates ను నివారిస్తుంటే, దానికి బదులుగా VPSలో live kernel patching ఉపయోగించండి.

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

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

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

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

grub-editenv: error: environment block too small. /boot/grub/grubenv అందుబాటులో లేదు లేదా truncated అయింది. దాన్ని sudo grub-editenv /boot/grub/grubenv create తో మళ్లీ సృష్టించి, మీ value ను మళ్లీ set చేసి 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 remove చేయడం వల్ల ఇది జరుగుతుంది. పనిచేసే entry తో console boot చేసి, ఆపై stale value ను clear చేయాలి.

మీరు మార్చాలని ఆశించిన reboot తర్వాత uname -r మారలేదు. ఈ మూడు విషయాలను వరుసగా పరిశీలించండి: grub-editenv list ఇప్పటికీ మీ value ను చూపిస్తుందా, లేదా అది ఇప్పటికే వినియోగించబడిందా; మీరు set చేసిన identifier ప్రస్తుత grub.cfg లో కనిపిస్తుందా; మీరు set చేసిన 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 ఏ entry ని సూచించదు, కాబట్టి GRUB మొదటి entry కి fallback అవుతుంది. దీన్ని sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg తో నిర్ధారించండి. count 1 రావడమే కారణాన్ని నిర్ధారిస్తుంది. దీనికి కారణం GRUB_FORCE_PARTUUID. image vendor దీన్ని /etc/default/grub.d/ లోని ఒక file లో సెట్ చేస్తుంది. దాంతో generator, ఇన్‌స్టాల్ చేసిన kernel ల పూర్తి జాబితాను రూపొందించకుండా 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>' ను run చేయండి. తరువాత provider console ఇప్పటికే తెరిచి ఉండగానే reboot చేయండి. boot చేయడానికి ముందు GRUB next_entry ను clear చేస్తుంది. అందువల్ల ఈ ఎంపిక కేవలం ఒక attempt కు మాత్రమే వర్తిస్తుంది. panic అయ్యే kernel ను మళ్లీ ప్రయత్నించదు. విలువ సరిగ్గా చేరిందో sudo grub-editenv list తో నిర్ధారించండి. దీనిపై ఆధారపడే ముందు sudo grep -n next_entry /boot/grub/grub.cfg ను run చేయండి. ఎందుకంటే config grubenv ను load చేయకపోతే command ఎలాంటి error లేకుండానే పట్టించుకోదు.

Entry number తో pin చేయాలా, identifier తోనా?

Identifier తో pin చేయండి. 10_linux జాబితాను newest first క్రమంలో మళ్లీ రూపొందిస్తుంది. అందువల్ల ఏ kernel ను install చేసినా లేదా remove చేసినా entry numbers మారుతాయి. పాత 1>2 అయినా warning లేకుండా సరైనదిగా కనిపించే, కానీ తప్పు entry కి resolve అవుతుంది. Identifier లో kernel version ఉంటుంది. కాబట్టి అవి మీరు ఉద్దేశించిన kernel కు match అవుతాయి లేదా resolve కావు. వాటిని sudo grep -n menuentry_id_option /boot/grub/grub.cfg తో list చేసి, ప్రతి entry line లో తరువాత వచ్చే quotes లోని 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 ను ఎప్పుడు run చేస్తారో నిర్ణయించండి.