Ubuntu VPS پر اگلا kernel boot کیسے pin کریں

آپ کے VPS کو اگلی بار کون سا kernel boot کرنا ہے، یہ فیصلہ ایک generated file، /boot/grub/grub.cfg، کرتی ہے۔ اس file میں براہ راست ترمیم نہ کریں۔ اس کے inputs میں ترمیم کریں اور اسے دوبارہ generate کریں۔ Ubuntu cloud image میں ان inputs میں سے ایک image vendor فراہم کرتا ہے۔ یہ menu selection کو غیر مؤثر بنا سکتا ہے۔ اسی لیے rented server پر GRUB_DEFAULT=1 کے بعد update-grub چلانے سے کچھ تبدیل نہیں ہوتا، جبکہ laptop install پر یہی دونوں steps کام کرتے ہیں۔

یہ کام اسی ترتیب سے کریں۔ پہلے تصدیق کریں کہ kernel منتخب کرنے کا اختیار آپ کے پاس ہے۔ تمام input files پڑھیں، ان files کو بھی جنہیں vendor نے شامل کیا ہے۔ generated output پڑھیں اور گنیں کہ اس میں حقیقتاً کتنی entries موجود ہیں۔ اس کے بعد ہی pinning method منتخب کریں۔ SSH کے ذریعے قابل رسائی مشین پر یہ کام غلط کرنے سے آپ کو rescue console درکار ہو سکتی ہے۔ اسی لیے اس صفحے کے آخر میں دیے گئے محفوظ ترین طریقے اکثر درست انتخاب ہوتے ہیں۔

پہلے یقینی بنائیں کہ kernel آپ کے اختیار میں ہے تاکہ اسے pin کر سکیں

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

systemd-detect-virt کا output kvm، qemu یا xen ہو تو اس کا مطلب ہے کہ آپ اپنا kernel چلا رہے ہیں، اور ذیل کی تمام ہدایات لاگو ہوتی ہیں۔ lxc یا openvz کا output ہو تو آپ کا server host کا kernel استعمال کر رہا ہے۔ اس لیے آپ کا کوئی bootloader نہیں جسے آپ configure کر سکیں، اور pin کرنے کے لیے بھی کچھ نہیں ہے۔ ایسی صورت میں uname -r ایسا version دکھاتا ہے جو /boot/vmlinuz-* میں بالکل موجود نہیں ہوتا، کیونکہ چلنے والا kernel host کا ہے اور آپ کی disk پر کوئی setting اسے تبدیل نہیں کر سکتی۔

ls -1 /boot/vmlinuz-* ان kernels کی اصل فہرست ہے جن میں سے آپ انتخاب کر سکتے ہیں۔ اگر اس میں صرف ایک line ہو تو پچھلا kernel پہلے ہی delete ہو چکا ہے، اور کوئی bootloader setting اسے واپس نہیں لا سکتی۔ عموماً ایسا autoremove کے دوران ہوتا ہے۔ اپنے اہم server پر Ubuntu میں پرانے kernels صاف کرنے سے پہلے اس عمل کو سمجھ لینا بہتر ہے۔

آپ جس فائل میں ترمیم کرتے ہیں، وہ وہ فائل نہیں جسے 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 چلاتا ہے، جو variables پڑھتا ہے، /etc/grub.d/ میں موجود ہر script چلاتا ہے، اور نتیجہ لکھتا ہے۔ دو commands، ایک سمت: input اندر جاتا ہے اور grub.cfg باہر آتا ہے۔

آپ کی setting کو کیا 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 جیسی settings set کرتی ہیں۔ آپ کی GRUB_TIMEOUT=10 کو /etc/default/grub میں چند لمحوں بعد vendor file overwrite کر دیتی ہے، جو اسے 0 پر set کرتی ہے۔ اوپر دیا گیا grep آپ کی image میں موجود exact assignments دکھاتا ہے، اس لیے اس جملے پر بھروسا کرنے کے بجائے وہ assignments پڑھیں۔

اس سے عملی اصول یہ نکلتا ہے: اپنی settings ایسی file میں رکھیں جو sorting میں آخر میں آئے، مثلاً /etc/default/grub.d/99-local.cfg، اور /etc/default/grub میں براہِ راست ترمیم نہ کریں۔ اس طرح image کی فراہم کردہ کوئی file آپ کی file کے بعد load نہیں ہو سکے گی۔

کیوں 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 استعمال کرنے کی ہدایت دیتا ہے۔ یہ قدر براہ راست kernel command line پر root=PARTUUID=... کے طور پر لکھی جاتی ہے، اس کے بجائے کہ boot کے دوران filesystem UUID تلاش کی جائے۔ image vendor اسے اس لیے set کرتا ہے کہ ایک ہی disk image ایسے hardware پر بھی قابلِ اعتماد طریقے سے boot ہو سکے جس پر اسے تیار نہیں کیا گیا تھا۔ دوسری grep آپ کو /etc/grub.d/10_linux میں موجود وہ code دکھاتی ہے جو اس variable پر عمل کرتا ہے۔ یہ script آپ کی اپنی disk پر موجود ہے، اور یہی اس بات کا حتمی ماخذ ہے کہ آپ کی image کیا کرتی ہے۔

یہاں اہم نتیجہ یہ ہے: اس path پر جنریٹر installed kernels کی مکمل فہرست کے بجائے براہِ راست boot entry لکھتا ہے۔ دیکھیں کہ آخر میں کتنی entries بنی ہیں۔

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

اگر count 1 ہے تو منتخب کرنے کے لیے دوسری entry موجود نہیں۔ اس لیے GRUB_DEFAULT=1 ایسی entry کو نامزد کرتا ہے جو موجود ہی نہیں۔ GRUB اسے resolve نہیں کر پاتا، چنانچہ پہلی entry boot کرتا ہے، اور یہی وہ نیا kernel ہے جس سے آپ بچنا چاہتے تھے۔ grub-set-default بھی مدد نہیں کرتا، کیونکہ خرابی default میں نہیں ہے۔ جس menu میں سے آپ انتخاب کرنا چاہتے ہیں، وہ کبھی generate ہی نہیں ہوا۔

مکمل menu واپس حاصل کرنے کے لیے vendor file کو عارضی طور پر دوسری جگہ منتقل کریں، پھر تبدیلی لاگو کرنے سے پہلے نتیجہ 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) '

اگر count 1 سے کئی تک بڑھ جائے تو اس کا مطلب ہے کہ forcing ختم ہونے کے بعد entries ظاہر ہو رہی ہیں۔ ابھی disk پر کچھ نہیں لکھا گیا۔ اگر دوسرا count درست نہ لگے تو file واپس رکھ دیں، کیونکہ forced PARTUUID ہی آپ کے provider کی image کو اس کے root filesystem تک پہنچاتا ہے۔ اسے ہٹانے سے machine search path استعمال کرنے لگتی ہے۔ update-grub حقیقتاً چلانے سے پہلے snapshot لیں۔

اگر آپ کا واحد مقصد ایک خراب kernel کے دوران system کو چلتا رکھنا ہے تو یہیں رک جائیں اور نیچے دیے گئے زیادہ محفوظ options استعمال کریں۔ صرف ایک upgrade سے بچنے کے لیے remote server پر boot menu دوبارہ بنانا، اس مسئلے کے مقابلے میں زیادہ خطرناک ہے۔

انٹری نمبرز کو pin کرنا غلط انتخاب کیوں ہے

GRUB_DEFAULT ایک نمبر، عنوان یا identifier قبول کرتا ہے۔ نمبرز 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 میں define کیے جانے والے variable کو دکھاتی ہیں۔ اس کے بعد بائیں طرف وہ title ہوتا ہے جو reader دیکھتا ہے، جبکہ دائیں طرف وہ identifier ہوتا ہے جسے آپ tools کو دیتے ہیں۔ submenu کے اندر موجود entry کے لیے submenu identifier اور entry identifier کو > کے ساتھ اسی ترتیب میں جوڑیں، جیسے numeric form میں کیا جاتا ہے۔

پچھلا kernel ایک بار grub-reboot کے ذریعے boot کریں

Remote server پر ایک بار کی selection درست طریقہ ہے، کیونکہ یہ خود ہی ختم ہو جاتی ہے۔ grub-reboot، next_entry کو /boot/grub/grubenv میں لکھتا ہے۔ GRUB اس variable کو پڑھتا ہے، اسے صاف کرتا ہے، اور کسی بھی چیز کو boot کرنے سے پہلے صاف شدہ value محفوظ کرتا ہے۔ اس لیے panic کرنے والے kernel کو اگلے boot پر دوبارہ نہیں آزمایا جاتا۔ آپ کو ایک کوشش ملتی ہے، پھر machine خود ہی اپنے معمول کے default پر واپس آ جاتی ہے۔

پہلے تصدیق کریں کہ generated config اس variable کو پڑھتی بھی ہے:

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

آپ کو load_env کی ایک line اور ایسا block نظر آنا چاہیے جو next_entry سے default set کرتا ہو۔ اگر grep کچھ بھی print نہ کرے تو آپ کی image boot کے وقت 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 print کرنی چاہیے، جس میں وہی value بالکل موجود ہو جو آپ نے pass کی تھی۔ اپنے provider کا console browser tab میں کھولیں، پھر reboot کریں اور نتیجہ check کریں۔

sudo reboot

uname -r

uname -r کا older version report کرنا بتاتا ہے کہ pin کامیاب رہا۔ نئے version کی رپورٹ کا مطلب ہے کہ یا تو identifier resolve نہیں ہوا یا grubenv کو read نہیں کیا جا رہا۔ دونوں صورتوں میں machine up ہے، اور one shot form استعمال کرنے کا مقصد بھی یہی ہے۔

GRUB_DEFAULT=saved کے ساتھ انتخاب برقرار رکھیں

GRUB_DEFAULT=saved طے کرتا ہے کہ default قدر 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}" دکھانا چاہیے۔ اگر یہ set default="0" دکھائے تو آپ کی file کے بعد source ہونے والی کسی چیز نے GRUB_DEFAULT کو دوبارہ literal value پر مقرر کر دیا ہے۔ اس لیے /etc/default/grub.d/ دوبارہ درج کریں اور تصدیق کریں کہ 99-local.cfg واقعی سب سے آخر میں sort ہوتا ہے۔

GRUB_SAVEDEFAULT=true ایک مختلف setting ہے، اور اسے اس setting کے ساتھ آسانی سے خلط ملط کیا جا سکتا ہے۔ یہ اس kernel کو، جس سے آپ نے ابھی boot کیا ہے، نیا default محفوظ کر دیتی ہے۔ اس طرح default آخری کامیاب boot کی پیروی کرتا ہے۔ Server پر اس کا مطلب ہے کہ unattended reboot خاموشی سے آپ کا مقررہ انتخاب بدل سکتا ہے۔ جب تک آپ یہی نہ چاہتے ہوں، اسے بند رکھیں۔

Identifier کے ذریعے مقرر کیا گیا انتخاب ایک صورت میں پھر بھی ناکام ہو سکتا ہے۔ جس kernel کا نام identifier میں ہے، اسے remove کرنے پر identifier resolve نہیں ہوتا، اور نظام پہلے entry پر واپس چلا جاتا ہے۔ اس لیے package کو بھی hold کریں، یا اس kernel کو autoremove سے خارج رکھیں۔

فراہم کنندہ کے console پر menu دکھانا

تعامل کے ذریعے انتخاب کرنے کے لیے menu کا اسکرین پر دکھائی دینا ضروری ہے، لیکن cloud images اسے چھپا دیتی ہیں۔ یہ سطور اس file میں شامل کریں جو آخری ترتیب سے load ہوتی ہے، پھر sudo update-grub چلائیں۔

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

GRUB_TIMEOUT_STYLE=hidden اور GRUB_TIMEOUT=0 کو ساتھ استعمال کرنے پر کچھ بھی دکھائی نہیں دیتا۔ اس لیے console کو مانیٹر کرنے والے شخص کو kernel messages فوراً شروع ہوتے دکھائی دیتے ہیں، اور وہ نتیجہ اخذ کرتا ہے کہ bootloader کو چھوڑ دیا گیا تھا۔ GRUB_RECORDFAIL_TIMEOUT اس boot کے مکمل نہ ہونے کے بعد استعمال ہونے والا الگ timeout ہے۔ cloud images اسے بھی 0 پر set کرتی ہیں۔ اسی وجہ سے جو server ابھی boot ہونے میں ناکام ہوا ہو، وہ بھی رک کر آپ کا انتظار نہیں کرتا۔

اگر آپ کا provider graphical console کے بجائے serial console فراہم کرتا ہے اور پھر بھی کچھ دکھائی نہیں دیتا، تو GRUB ایسے terminal پر لکھ رہا ہے جسے آپ دیکھ نہیں سکتے۔ دونوں سطور ایک ساتھ شامل کریں، کیونکہ پہلی output منتخب کرتی ہے اور دوسری port configure کرتی ہے:

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

اب سے ہر boot میں 10 seconds شامل ہوں گے۔ کام مکمل ہونے کے بعد timeout کو دوبارہ 0 پر set کریں۔

بوٹ لوڈر میں ترمیم کے بجائے زیادہ محفوظ طریقے

جس مشین تک آپ صرف SSH کے ذریعے پہنچتے ہیں، اس کے بوٹ لوڈر کے input میں تبدیلی اس صفحے پر موجود سب سے زیادہ خطرناک اختیار ہے۔ کم خرچ طریقے موجود ہیں، اور عموماً وہ اصل مسئلہ حل کر دیتے ہیں۔

kernel packages کو hold کریں۔ اگر مقصد یہ ہے کہ "مجھے نیا kernel نہ دیں"، تو یہ بات بوٹ لوڈر کے بجائے 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 میں عموماً virtual یا kvm flavor انسٹال ہوتا ہے، generic نہیں۔ اگر نیا kernel کسی image refresh کے دوران ظاہر ہوا اور آپ کو شبہ ہے کہ release آپ کی مشین پر خود بخود تبدیل ہو گئی، تو ایسا نہیں ہوا، کیونکہ point release وہی updates ہیں جو نئے install media میں پہلے سے شامل کر دیے گئے ہیں، اور پہلے سے patched server کو ایسی کوئی چیز نہیں ملتی جو اسے کئی ہفتے پہلے پیش نہ کی گئی ہو۔ held package کو apt upgrade چھوڑ دیتا ہے، اور The following packages have been kept back: کے ذریعے اس کی اطلاع دیتا ہے۔ Ubuntu میں unattended upgrades بھی اسے چھوڑ دیتے ہیں۔ اس کی حقیقی قیمت ہے: held kernel کو security fixes موصول نہیں ہوتیں۔ اس لیے اسے تاریخ مقرر کر کے عارضی توقف سمجھیں، اور sudo apt-mark unhold کے ذریعے hold ختم کریں۔ اگر آپ kernel updates سے اس لیے بچ رہے ہیں کہ reboot سے downtime ہوتا ہے، نہ کہ اس لیے کہ کوئی ایک kernel خراب ہے، تو VPS پر live kernel patching اس مسئلے کا متبادل حل ہے۔

upgrade سے پہلے snapshot لیں۔ Snapshot چند منٹ میں restore ہو جاتا ہے۔ اس میں console پر typing کی ضرورت نہیں ہوتی اور bootloader میں ادھوری تبدیلی کا خطرہ بھی نہیں ہوتا۔ Snapshot لیں، upgrade کریں، reboot کریں، اور تصدیق کریں۔ اگر نیا kernel درست کام نہ کرے تو rollback کریں؛ boot path بالکل پہلے جیسا ہو جائے گا۔

جو box پہلے ہی down ہو، اس کے لیے console یا rescue image استعمال کریں۔ جب server boot نہ ہو رہا ہو تو bootloader config وہ جگہ نہیں جہاں مسئلہ حل کیا جائے۔ اس recovery path کا اپنا طریقۂ کار ہے: kernel update کے بعد VPS boot نہ ہو تو کیا کریں۔

کیا خراب ہوتا ہے، اور آپ کو کون سا پیغام نظر آئے گا

/boot/grub/grub.cfg میں آپ کی ترمیم غائب ہو گئی۔ kernel package نصب یا حذف ہوا، اس کے maintainer script نے update-grub چلایا، اور file کو input locations سے دوبارہ تیار کر دیا گیا۔ # 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 دوبارہ set کریں اور sudo grub-editenv list سے تصدیق کریں۔

Pinned kernel، VFS: Unable to mount root fs on unknown-block(0,0) کے ساتھ kernel panic کرتا ہے۔ آپ کی pinned entry ایسے kernel یا initrd کی طرف اشارہ کرتی ہے جو اب disk پر موجود نہیں۔ عموماً package حذف ہو چکا ہوتا ہے، جبکہ identifier grubenv میں برقرار رہتا ہے۔ بحالی کے لیے console سے کسی درست entry پر boot کریں، پھر پرانی value صاف کریں۔

جس reboot کے بعد uname -r تبدیل ہونا چاہیے تھا، اس کے بعد بھی وہ تبدیل نہیں ہوا۔ تین چیزیں اسی ترتیب سے چیک کریں: کیا grub-editenv list اب بھی آپ کی value دکھا رہا ہے یا وہ استعمال ہو چکی ہے؛ کیا آپ کا set کردہ identifier موجودہ grub.cfg میں نظر آتا ہے؛ کیا grub.cfg میں ایسی set default line موجود ہے جو آپ کی set کردہ variable کو پڑھتی ہو۔ ہر بار ان تین میں سے ایک چیز وجہ واضح کر دیتی ہے۔

Crash کے بعد menu خود ظاہر ہو گیا۔ GRUB ناکام boot کو grubenv میں recordfail=1 کے طور پر record کرتا ہے۔ اس سے اگلے boot پر menu ظاہر ہوتا ہے تاکہ administrator مداخلت کر سکے۔ Machine کے درست ہونے کے بعد sudo grub-editenv /boot/grub/grubenv unset recordfail کے ذریعے اسے صاف کریں۔

یاد رکھنے کے قابل واحد جملہ یہ ہے: آپ جس file میں ترمیم کرتے ہیں، GRUB وہ file نہیں پڑھتا، اور cloud image میں ان دونوں کے درمیان موجود فرق ہی الجھن پیدا کرتا ہے۔ پہلے generated config پڑھیں۔ اس صفحے کا ہر فیصلہ اسی بات پر مبنی ہے کہ config میں حقیقتاً کیا لکھا ہے۔

FAQ

GRUB_DEFAULT=1 سے میرے VPS کے boot ہونے والے kernel میں تبدیلی کیوں نہیں آتی؟

کیونکہ Ubuntu cloud image میں تیار کردہ /boot/grub/grub.cfg میں اکثر صرف ایک boot entry ہوتی ہے۔ اس لیے index 1 کسی entry کو نامزد نہیں کرتا اور GRUB پہلی entry پر واپس چلا جاتا ہے۔ sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg سے اس کی تصدیق کریں۔ اگر count 1 ہو تو یہی وجہ ہے۔ سبب GRUB_FORCE_PARTUUID ہے، جسے image vendor /etc/default/grub.d/ کے تحت موجود file میں set کرتا ہے۔ اس سے generator installed kernels کی مکمل فہرست بنانے کے بجائے direct boot path استعمال کرتا ہے۔ grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ سے یہ file تلاش کریں۔

صرف ایک مرتبہ previous kernel پر boot کیسے کروں؟

اپنے grub.cfg سے نقل کیے گئے identifier کے ساتھ sudo grub-reboot '<identifier>' چلائیں، پھر provider console پہلے سے کھلی رکھ کر reboot کریں۔ GRUB boot سے پہلے next_entry صاف کر دیتا ہے، اس لیے یہ انتخاب صرف ایک attempt پر لاگو ہوتا ہے اور panic کرنے والے kernel کو دوبارہ try نہیں کیا جاتا۔ sudo grub-editenv list سے تصدیق کریں کہ value set ہو گئی ہے۔ اس پر انحصار کرنے سے پہلے sudo grep -n next_entry /boot/grub/grub.cfg چلائیں، کیونکہ ایسی image جس کی config grubenv load نہیں کرتی، command کو بغیر کسی error کے نظرانداز کر دے گی۔

کیا entry number یا identifier کے ذریعے pin کرنا چاہیے؟

Identifier کے ذریعے۔ Entry numbers اس فہرست میں positions ہوتے ہیں جسے 10_linux newest first ترتیب میں دوبارہ بناتا ہے۔ اس لیے کسی بھی kernel کو install یا remove کرنے سے numbers بدل جاتے ہیں۔ پرانا 1>2 پھر بھی کسی حقیقی مگر غلط entry کو resolve کر سکتا ہے، اور خبردار کرنے کے لیے کچھ بھی print نہیں ہوتا۔ Identifiers میں kernel version شامل ہوتا ہے، اس لیے وہ یا تو مطلوبہ kernel سے match کرتے ہیں یا resolve نہیں ہوتے۔ sudo grep -n menuentry_id_option /boot/grub/grub.cfg سے انہیں list کریں اور ہر entry line پر اس کے بعد آنے والی quoted string نقل کریں۔

کیا kernel package کو hold کرنا bootloader تبدیل کرنے سے زیادہ محفوظ ہے؟

عام مقصد کے لیے، ہاں۔ sudo apt-mark hold linux-image-virtual linux-headers-virtual نئے kernel کو install ہونے سے ہی روک دیتا ہے، اس لیے boot path تبدیل نہیں ہوتا اور ایسی console سے غلطی کا خطرہ نہیں رہتا جس تک ممکن ہے آپ کی رسائی نہ ہو۔ پہلے اپنے box پر installed flavour names کو apt list --installed سے check کریں، پھر apt-mark showhold سے hold کی تصدیق کریں۔ اس کا نقصان یہ ہے کہ held kernel کو security fixes نہیں ملتے۔ اس لیے hold لگانے سے پہلے طے کریں کہ sudo apt-mark unhold کب چلائیں گے۔