Ubuntu VPS پر اگلا kernel boot کیسے منتخب کریں

آپ کے VPS کا اگلا boot کس kernel سے ہوگا، اس کا فیصلہ کون کرتا ہے

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

اسی ترتیب سے کام کریں۔ پہلے تصدیق کریں کہ kernel منتخب کرنے کا اختیار آپ کے پاس ہے۔ ہر input file پڑھیں، ان files سمیت جو vendor نے شامل کی ہیں۔ generated output پڑھیں اور entries گنیں کہ اس میں واقعی کتنی entries موجود ہیں۔ اس کے بعد ہی pinning method منتخب کریں۔ اگر آپ یہ کام ایسی machine پر غلط کریں جس تک رسائی صرف 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 بھی آپ کا نہیں ہے اور pin کرنے کے لیے کچھ موجود نہیں۔ ایسی صورت میں uname -r ایسا version دکھاتا ہے جو /boot/vmlinuz-* میں بالکل موجود نہیں ہوتا، کیونکہ چلنے والا kernel host کا ہوتا ہے اور آپ کی disk کی کوئی setting اسے تبدیل نہیں کر سکتی۔

ls -1 /boot/vmlinuz-* ان kernels کی اصل فہرست ہے جن میں سے آپ انتخاب کر سکتے ہیں۔ اگر اس میں صرف ایک line ہو تو پچھلا kernel پہلے ہی delete ہو چکا ہے، اور کوئی bootloader setting اسے واپس نہیں لا سکتی۔ یہ عموماً autoremove کے دوران ہوتا ہے۔ اپنی اہم مشین پر 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 read ہونے کے بعد timeout اور kernel command line جیسی settings مقرر کرتی ہیں۔ آپ کی GRUB_TIMEOUT=10 کو /etc/default/grub میں ایک vendor file چند لمحوں بعد overwrite کر دیتی ہے اور اسے 0 مقرر کر دیتی ہے۔ اوپر دیا گیا grep آپ کی image پر موجود exact assignments دکھاتا ہے، اس لیے اس جملے پر بھروسا کرنے کے بجائے وہ assignments پڑھیں۔

اس سے عملی اصول یہ نکلتا ہے: اپنی settings ایسی file میں رکھیں جو sorting میں آخر میں آئے، مثلاً /etc/default/grub.d/99-local.cfg، بجائے اس کے کہ /etc/default/grub میں ترمیم کریں۔ پھر image کی فراہم کردہ کوئی 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 generator کو partition UUID کے ذریعے root filesystem تلاش کرنے کی ہدایت دیتا ہے۔ یہ قدر براہ راست kernel command line پر root=PARTUUID=... کے طور پر لکھی جاتی ہے، تاکہ boot کے دوران filesystem UUID تلاش نہ کیا جائے۔ image vendor اسے اس لیے set کرتا ہے کہ ایک ہی disk image ایسے hardware پر بھی قابل اعتماد طریقے سے boot ہو سکے جس پر اسے build نہیں کیا گیا تھا۔ دوسرا grep آپ کو /etc/grub.d/10_linux میں موجود اس variable پر عمل کرنے والا code دکھاتا ہے۔ یہ script آپ کی اپنی disk پر موجود ہے، اور یہی اس بات کا حتمی ماخذ ہے کہ آپ کی image کیا کرتی ہے۔

یہاں اہم نتیجہ یہ ہے: اس path پر generator 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 کے بغیر چلانے سے output 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 کو newest first ترتیب میں دکھاتا ہے، اس لیے 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 بھی یہی ترتیب استعمال کرتی ہے۔

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

Remote server پر ایک بار کے لیے selection کرنا درست طریقہ ہے، کیونکہ یہ خود بخود ختم ہو جاتی ہے۔ grub-reboot، /boot/grub/grubenv میں next_entry لکھتا ہے۔ GRUB اس variable کو پڑھتا ہے، اسے clear کرتا ہے، اور کسی بھی چیز کو boot کرنے سے پہلے cleared value محفوظ کر دیتا ہے۔ اس لیے panic کرنے والا kernel اگلے boot پر دوبارہ try نہیں ہوتا۔ آپ کو ایک attempt ملتی ہے، پھر 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 اسے نظرانداز کر دے گا۔ یہی forced direct boot path ہے جو پچھلے section میں تھا، اور اب دوسری جگہ ظاہر ہو رہا ہے۔

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 کریں اور result check کریں۔

sudo reboot

uname -r

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

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

GRUB_DEFAULT=saved میں default، grubenv کے اندر موجود saved_entry سے لیا جاتا ہے، اور یہ قدر آپ grub-set-default کے ذریعے مقرر کرتے ہیں۔ Kernel انسٹال ہونے کے بعد بھی یہ برقرار رہتی ہے، کیونکہ 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/ کو دوبارہ list کریں اور تصدیق کریں کہ 99-local.cfg واقعی آخر میں sort ہوتا ہے۔

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

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

provider console پر menu دکھانا

Interactive انتخاب کے لیے menu کا screen پر دکھائی دینا ضروری ہے، لیکن cloud images اسے چھپا دیتی ہیں۔ یہ settings سب سے آخر میں sort ہونے والی file میں شامل کریں، پھر 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 کو skip کر دیا گیا ہے۔ GRUB_RECORDFAIL_TIMEOUT اس boot کے بعد استعمال ہونے والا الگ timeout ہے جو مکمل نہیں ہوا تھا۔ cloud images اسے بھی 0 پر set کرتی ہیں۔ اسی وجہ سے جو server ابھی boot ہونے میں fail ہوا ہو، وہ بھی رک کر آپ کے input کا انتظار نہیں کرتا۔

اگر آپ کا provider graphical console کے بجائے serial console فراہم کرتا ہے اور پھر بھی کچھ دکھائی نہیں دیتا، تو GRUB ایسے terminal پر لکھ رہا ہے جسے آپ نہیں دیکھ سکتے۔ دونوں lines ایک ساتھ شامل کریں، کیونکہ پہلی outputs منتخب کرتی ہے اور دوسری 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 نہ دیا جائے"، تو یہ ہدایت 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 کے output میں دکھائے گئے نام استعمال کریں، کیونکہ cloud images میں عموماً virtual یا kvm flavour انسٹال ہوتا ہے، generic نہیں۔ held package کو apt upgrade چھوڑ دیتا ہے، اور اسے The following packages have been kept back: کے ذریعے ظاہر کرتا ہے۔ Ubuntu میں unattended upgrades بھی ایسے package کو چھوڑ دیتا ہے۔ اس کا حقیقی نقصان ہے: 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 بالکل پہلے جیسا ہو جائے گا۔

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

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

/boot/grub/grub.cfg میں کی گئی آپ کی ترمیم غائب ہو گئی۔ ایک kernel package install یا remove ہوا، اس کا maintainer script update-grub چلایا گیا، اور inputs سے file دوبارہ generate ہو گئی۔ # DO NOT EDIT THIS FILE header ان دونوں input locations کے نام بتاتا ہے۔ انہی files میں ترمیم کریں۔

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 کر جاتا ہے۔ جس entry کو آپ نے pin کیا ہے، وہ ایسے kernel یا initrd کی طرف اشارہ کرتی ہے جو اب disk پر موجود نہیں۔ عموماً package remove ہو جاتا ہے، لیکن identifier grubenv میں برقرار رہتا ہے۔ Recovery کے لیے console سے کسی working entry کو boot کریں، پھر stale value صاف کریں۔

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

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

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

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 کی مکمل فہرست بنانے کے بجائے براہ راست boot path استعمال کرتا ہے۔ grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ سے یہ file تلاش کریں۔

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

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

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

identifier کے ذریعے۔ Entry numbers اس فہرست میں positions ہوتی ہیں جسے 10_linux جدید ترین kernel کو پہلے رکھ کر دوبارہ بناتا ہے۔ اس لیے کوئی بھی 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 آنے سے ہی روک دیتا ہے۔ اس سے boot path تبدیل نہیں ہوتا اور ایسی console سے غلطی ہونے کا خطرہ نہیں رہتا جس تک شاید آپ کی رسائی نہ ہو۔ پہلے اپنے box پر installed flavour names apt list --installed سے چیک کریں، پھر apt-mark showhold سے hold کی تصدیق کریں۔ اس کا نقصان یہ ہے کہ held kernel کو security fixes نہیں ملتیں۔ اس لیے hold لگانے سے پہلے طے کریں کہ آپ sudo apt-mark unhold کب چلائیں گے۔