Kernel update کے بعد VPS boot نہ ہو تو کیا کریں

کرنل update کے بعد VPS boot نہ ہو تو سب سے پہلے کیا کریں

کرنل update کے بعد boot نہ ہونے والا VPS عموماً چند منٹ میں بحال ہو جاتا ہے، کیونکہ update نے وہ kernel حذف نہیں کیا ہوتا جو کل درست کام کر رہا تھا۔ Ubuntu نیا kernel پرانے kernel کے ساتھ install کرتا ہے اور صرف یہ تبدیل کرتا ہے کہ GRUB بطور default کون سی entry شروع کرے۔ اس لیے پہلا قدم repair نہیں ہے۔ boot menu میں پچھلا kernel منتخب کریں، login prompt دوبارہ حاصل کریں، پھر چلتے ہوئے system سے مسئلے کی تشخیص کریں۔

سرور پر اس مسئلے کو حل کرنا laptop کے مسئلے کو حل کرنے سے مختلف ہے، کیونکہ سرور کے ساتھ keyboard منسلک نہیں ہوتا اور panic دکھانے کے لیے monitor بھی موجود نہیں ہوتا۔ SSH بھی جواب نہیں دے گا، کیونکہ machine ابھی اس مرحلے تک نہیں پہنچی جہاں sshd شروع ہوتا ہے۔ ذیل کے تمام اقدامات آپ کے provider کے console کے ذریعے کیے جاتے ہیں۔

کچھ بھی تبدیل کرنے سے پہلے اپنے console کو پڑھیں۔ اس screen پر موجود متن طے کرتا ہے کہ آپ کس failure class سے دوچار ہیں۔ دو ایسے servers جن کے بارے میں کہا جائے کہ وہ دونوں "boot نہیں ہو رہے"، ان کے لیے بالکل متضاد fixes درکار ہو سکتی ہیں۔

جب SSH دستیاب نہ ہو تو کنسول تک کیسے پہنچوں؟

اپنے provider کے control panel میں جا کر console تلاش کریں۔ عام نام VNC console، web console، noVNC اور serial console ہیں۔ اگر دونوں دستیاب ہوں تو serial console کو ترجیح دیں، کیونکہ اس میں حقیقی متن دکھائی دیتا ہے جسے آپ scroll اور copy کر سکتے ہیں، جبکہ VNC view صرف اسکرین کی تصویر ہوتی ہے۔ یہ control ابھی تلاش کریں، جب machine درست حالت میں ہو، اور تصدیق کریں کہ یہ کھلتا ہے۔ outage کے دوران اسے تلاش کرنے سے وہ سکون ختم ہو جاتا ہے جس کی آپ کو ضرورت ہوتی ہے۔ یہ check نئے VPS پر پہلے دس منٹ کے اقدامات میں firewall rules اور SSH keys کے ساتھ شامل ہونا چاہیے۔

زیادہ تر panels rescue mode یا recovery image بھی فراہم کرتے ہیں۔ یہ provider کے network سے ایک چھوٹا system boot کرتا ہے اور آپ کی disk کو اضافی device کے طور پر attach کرتا ہے، اس لیے disk پر موجود کوئی چیز run نہیں ہوتی۔ جب خود GRUB خراب ہو تو rescue mode fallback ہوتا ہے۔ یہ اس server سے data copy کرنے کا طریقہ بھی ہے جسے آپ نے بچانے کی کوشش نہ کرنے کا فیصلہ کیا ہو۔

boot menu تک پہنچنے کے لیے عموماً panel سے hard reset کرنا پڑتا ہے، کیونکہ جس machine میں آپ log in نہیں کر سکتے اس پر sudo reboot نہیں چلا سکتے۔ hard reset بجلی منقطع کرنے کے برابر ہے۔ Filesystems کی shutdown حالت غیر صاف ہو جائے گی، اس لیے اگلے boot پر filesystem check کی توقع رکھیں۔

GRUB menu میں پرانا kernel کیسے منتخب کریں؟

Reset دبانے کے لمحے سے console کو دیکھیں۔ ابتدائی چند سیکنڈ کے دوران بار بار Esc دبائیں، یا اس مشین پر Shift کو دبائے رکھیں جو legacy BIOS mode میں boot ہوتی ہے۔ یہ موقع بہت مختصر ہوتا ہے، اور console viewer کو connect ہونے میں اکثر ایک سیکنڈ لگتا ہے، اس لیے جلدی دبانا شروع کریں اور مسلسل دباتے رہیں۔

Menu ظاہر ہونے پر "Advanced options for Ubuntu" منتخب کریں۔ اس submenu میں نصب شدہ ہر kernel درج ہوتا ہے۔ تازہ ترین kernel سب سے اوپر ہوتا ہے، اور ہر kernel کے لیے recovery mode entry بھی موجود ہوتی ہے۔ دوسری normal entry منتخب کریں۔ یہ تازہ ترین kernel سے ایک ورژن پرانا kernel ہوگا۔ پھر Enter دبائیں۔ Recovery mode الگ چیز ہے۔ یہ minimal single user system میں boot ہوتا ہے اور repair کے لیے استعمال ہوتا ہے، services کو دوبارہ online لانے کے لیے نہیں۔

اگر پرانا kernel boot ہو جائے تو server دوبارہ چل رہا ہے۔ موجودہ kernel اور متعلقہ معلومات کی تصدیق کریں، اور نمبرز لکھ لیں۔

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

dpkg کا output نصب شدہ kernels کی فہرست ہے۔ اگر اس میں صرف ایک line ہو تو آپ کے پاس کوئی fallback موجود نہیں۔ سب سے پہلے اسی مسئلے کو حل کریں۔

GRUB مینو ظاہر نہیں ہوتا۔ اب کیا کریں؟

Cloud images میں ایسی configuration شامل ہوتی ہے جو مینو چھپا دیتی ہے۔ Ubuntu images عام طور پر /etc/default/grub.d/ کے اندر موجود ایک file میں timeout کو 0 مقرر کرتی ہیں، اس لیے جدید ترین kernel فوراً شروع ہو جاتا ہے اور دبانے کے لیے کچھ موجود نہیں ہوتا۔

اس کے برعکس صورت بھی ہو سکتی ہے۔ مینو screen پر موجود ہوتا ہے اور input کا انتظار کر رہا ہوتا ہے، جس سے یہ محسوس ہوتا ہے کہ system hang ہو گیا ہے۔ GRUB failed boot ریکارڈ کرتا ہے، اور اگلی start پر مینو کو اس وقت تک کھلا رکھ سکتا ہے جب تک کوئی key نہ دبائے۔ ایسی machine پر جس کے ساتھ keyboard نہ ہو، یہ انتظار کبھی ختم نہیں ہوتا۔ اگر آپ کے console پر مینو دکھائی دے اور کچھ آگے نہ بڑھے تو یہی وجہ ہے۔ کوئی entry منتخب کریں اور جاری رکھیں۔

Machine کے درست حالت میں ہونے کے دوران دونوں مسائل حل کریں۔ /etc/default/grub میں ترمیم کریں:

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 کے بعد پڑھی جاتی ہیں اور آپ کی setting کو override کر سکتی ہیں۔

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" مینو کو graphical console اور serial port دونوں پر بھیجتا ہے، اس لیے یہ اس viewer میں دکھائی دے گا جو آپ کا panel فراہم کرتا ہے۔ console= kernel arguments اس کے بعد آنے والے boot messages کے لیے بھی یہی کام کرتے ہیں۔ ہر boot پر 10 seconds کی تاخیر اس مینو تک 2am پر بھی رسائی حاصل کرنے کے لیے معمولی قیمت ہے۔

میں کس نوعیت کی خرابی دیکھ رہا ہوں؟

کنسول کا output رکنے سے پہلے کی آخری 20 سطریں پڑھیں۔ kernel update کے بعد ہونے والی زیادہ تر خرابیوں کو 4 نمونے بیان کرتے ہیں۔

GRUB اپنی فائلیں تلاش نہیں کر سکتا۔ آپ کو grub rescue> prompt ملتا ہے، یا کسی ایسی partition یا file کے بارے میں error دکھائی دیتا ہے جو موجود نہیں، اور kernel کا کوئی message ظاہر نہیں ہوتا۔ اس مرحلے پر kernel ابھی شامل نہیں ہوا۔ یہ عموماً disk یا partition میں تبدیلی، یا bootloader کے غلط device پر لکھے جانے کے بعد ہوتا ہے، نہ کہ صرف kernel package کی وجہ سے۔

Kernel شروع ہو جاتا ہے، لیکن root mount نہیں کر پاتا۔ Kernel messages scroll ہوتے ہیں، پھر آپ busybox shell میں پہنچتے ہیں جس کا prompt (initramfs) ہوتا ہے، یا boot اس panic پر ختم ہوتا ہے کہ root filesystem mount نہیں کیا جا سکتا۔ Kernel load ہو چکا ہے۔ initramfs، جو عارضی چھوٹا root filesystem ہوتا ہے اور حقیقی root filesystem کو تلاش کرکے mount کرتا ہے، disk تلاش نہیں کر سکا۔ Ubuntu پر اس shell سے پہلے عموماً root device کے لیے انتظار ختم ہونے کا message آتا ہے، جس میں مطلوبہ UUID درج ہوتا ہے۔ اس UUID کو copy کریں اور بعد میں 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 کا استعمال control واپس initramfs script کو دیتا ہے، جو mount کی دوبارہ کوشش کرتی ہے۔ اگر اس کے بعد system boot ہو جائے، تو نئے initramfs میں LVM کے اجزا موجود نہیں ہیں۔ ایسی صورت میں kernel کو تبدیل کرنے کے بجائے اس image کو دوبارہ بنائیں۔

Linux کی طرف سے کچھ بھی ظاہر نہیں ہوتا۔ Console پر firmware text، UEFI (unified extensible firmware interface) shell، kernel output کے بغیر خالی screen، یا reset loop دکھائی دیتا ہے۔ خرابی Linux کے چلنے سے پہلے پیش آ رہی ہے۔ دوبارہ system دستیاب ہونے کے بعد دیکھیں کہ 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 کا mounted نہ ہونا UEFI machines پر عام وجہ ہے، کیونکہ EFI system partition کو maintain کرنے والے packages اس کے بجائے ایک عام خالی directory میں لکھ دیتے ہیں۔ Firmware پرانی boot entry کو اس وقت تک شروع کرتا رہتا ہے جب تک وہ entry disk پر موجود چیزوں سے مطابقت رکھنا بند نہ کر دے۔

ایک اور pattern دراصل boot failure نہیں ہوتا۔ اگر آپ root shell تک پہنچ جائیں اور اس میں بتایا جائے کہ system emergency mode میں ہے، تو kernel boot ہو چکا ہے اور userspace رک گیا ہے۔ عموماً اس کی وجہ /etc/fstab میں غلط line یا وہ filesystem ہوتی ہے جو check میں ناکام ہو گیا ہو۔ اس shell میں journalctl -xb چلائیں اور اس unit کا نام پڑھیں جو failed ہوئی ہے۔

کیا kernel package خراب ہے یا initramfs؟

یہ دونوں console پر ایک جیسے دکھائی دیتے ہیں، لیکن ان کی مرمت کے طریقے مختلف ہیں۔ پرانا kernel boot کریں، پھر files کا موازنہ کریں۔

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

ہر installed version کے لیے ایک vmlinuz- اور اس سے مطابقت رکھنے والا ایک initrd.img- ہونا چاہیے، اور دونوں کا size قابلِ اعتبار ہونا چاہیے۔ initrd کا غائب ہونا، یا اس کا size ساتھ والی files کے مقابلے میں بہت کم ہونا، ظاہر کرتا ہے کہ 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

history.log یہ بھی عین بتاتا ہے کہ آخری runs نے کون سے packages کب install کیے، جس سے تبدیلی کے بارے میں کوئی ابہام نہیں رہتا۔

اگر /boot بھرا ہوا ہے تو پہلے space خالی کریں، پھر مطلوبہ version کے لیے image دوبارہ بنائیں اور menu refresh کریں۔ version string اپنے ls کے output سے لیں، کیونکہ نیچے دیا گیا 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 کے علاوہ کسی بھی state میں دکھائے، تو package دوبارہ install کریں:

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

rescue mode سے مرمت، جب کوئی kernel boot نہ ہو

اگر menu میں موجود ہر entry ناکام ہو جائے تو provider کی rescue image سے boot کریں اور disk کی بیرونی ماحول سے مرمت کریں۔ آپ کی disk unmounted device کے طور پر ظاہر ہوگی، اس لیے اس پر کچھ بھی چل نہیں رہا ہوگا اور کوئی process آپ کی مرمت میں رکاوٹ نہیں ڈالے گا۔

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 کرنے پر آپ دوبارہ درست kernel میں آ جائیں گے، اور console میں بروقت کارروائی کرنے کی ضرورت نہیں ہوگی۔

/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 اس بات کا ثبوت ہے کہ طریقۂ کار کام کرتا ہے، کیونکہ save کرنے کے لیے قابلِ تحریر /boot/grub/grubenv درکار ہوتا ہے، اور بعض layouts میں یہ خاموشی سے قابلِ تحریر نہیں ہوتا۔ Entry 0 مینو کے اوپر موجود entry ہے، یعنی جدید ترین kernel۔ یہاں numbers کے بجائے titles زیادہ محفوظ ہیں، کیونکہ ہر kernel کے install یا remove ہونے پر numbers تبدیل ہو جاتے ہیں۔

ہیڈ لیس سرور پر autoremove خطرناک کیوں ہے

APT ان kernel packages کی فہرست برقرار رکھتا ہے جنہیں اسے خود سے remove نہیں کرنا چاہیے۔ اپنی فہرست دیکھیں:

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

یہ فائل kernel packages میں تبدیلی کے وقت دوبارہ generate ہوتی ہے، اور یہ جاری kernel اور حالیہ kernels کو محفوظ رکھتی ہے۔ اصل خطرہ وقت کا ہے۔ نئے kernel میں reboot کرنے کے فوراً بعد sudo apt autoremove --purge چلائیں تو protected list پہلے ہی آگے منتقل ہو چکی ہوتی ہے۔ اس لیے وہ پرانا kernel محفوظ نہیں رہتا جس پر آپ انحصار کر رہے تھے۔ keyboard والے machine پر یہ صرف ایک زحمت ہے۔ headless server پر یہ menu entry منتخب کرنے اور rescue image سے اپنی disk mount کرنے کے درمیان فرق ہے۔

کم از کم دو kernels رکھیں، اور جب /boot میں گنجائش ہو تو تین رکھیں۔ uname -r چیک کرنے کے بعد پرانے kernels کو نام سے remove کریں، تاکہ آپ کبھی جاری kernel delete نہ کر سکیں:

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 وہ واحد recovery path ہے جس کے لیے کسی چیز کو boot کرنا ضروری نہیں ہوتا۔ اسے restore کرنے سے disk اسی حالت میں واپس آ جاتی ہے جس میں پرانا kernel default تھا، اور آپ console پہلے سے کھلی ہونے کی صورت میں اپ گریڈ دوبارہ آزما سکتے ہیں۔ چلتی ہوئی machine کے snapshots crash consistent ہوتے ہیں۔ اس کا مطلب ہے کہ وہ disk کو اس طرح capture کرتے ہیں جیسے بجلی منقطع ہو گئی ہو۔ اس لیے اگر آپ کا provider offline snapshot کی سہولت دیتا ہے تو پہلے server shut down کریں۔ snapshot backup بھی نہیں ہوتا، کیونکہ عموماً یہ اسی infrastructure پر موجود ہوتا ہے جس پر اس کا copy کیا گیا volume موجود ہے۔ VPS snapshots اور حقیقی backups کے درمیان فرق سمجھنے سے یہ طے ہوتا ہے کہ kernel سے بڑا failure ہونے پر آپ کو کون سا طریقہ بچائے گا۔

یہ بات release upgrade کے دوران سب سے زیادہ اہم ہوتی ہے، کیونکہ kernel، initramfs tools، bootloader اور GRUB config ایک ہی run میں تبدیل ہوتے ہیں۔ snapshot اسی وقت لیں جب آپ Ubuntu 24.04 سے 26.04 کا upgrade شروع کرنے والے ہوں، نہ کہ ایک رات پہلے، تاکہ restore point اسی machine کی حالت سے مطابقت رکھے جسے آپ تبدیل کرنے والے ہیں۔ اگر یہ upgrade ابھی آپ کے server پر پیش نہیں کیا گیا تو وجہ broken setup نہیں بلکہ scheduling ہے، کیونکہ LTS سے LTS upgrade صرف پہلی point release، 26.04.1 پر دستیاب ہوتا ہے۔

unattended-upgrades kernel packages کے ساتھ کیسے برتاؤ کرتا ہے

Ubuntu کا unattended-upgrades بغیر پوچھے security updates انسٹال کرتا ہے، اور kernel packages بھی دیگر packages کی طرح security pocket کے ذریعے آتے ہیں۔ اس کے دو نتائج نکلتے ہیں۔

اول، نیا kernel انسٹال ہو جاتا ہے لیکن چل نہیں رہا ہوتا۔ kernel صرف boot کے وقت مؤثر ہوتا ہے۔ /var/run/reboot-required فائل ظاہر ہوتی ہے، اور /var/run/reboot-required.pkgs یہ بتاتا ہے کہ reboot کی درخواست کس نے کی، لیکن کوئی چیز restart نہیں ہوتی جب تک آپ /etc/apt/apt.conf.d/50unattended-upgrades میں Unattended-Upgrade::Automatic-Reboot فعال نہ کریں۔

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

دوم، یہ وقفہ اصل وجہ چھپا دیتا ہے۔ کوئی server March میں kernel انسٹال کر سکتا ہے اور June میں کسی بالکل غیر متعلق وجہ سے reboot ہو کر start ہونے میں ناکام ہو سکتا ہے۔ boot کو خراب کرنے والی تبدیلی تین ماہ پرانی ہوتی ہے، اس لیے اس دن کیا گیا کوئی کام وجہ کی وضاحت نہیں کرتا۔ /var/log/apt/history.log میں وہ run ملتا ہے جس نے وہ kernel انسٹال کیا تھا جس پر اب server start ہونے میں ناکام ہو رہا ہے۔

اپنی مرضی سے، پہلے سے منتخب کیے گئے دن reboot کریں اور console window پہلے ہی کھلی رکھیں۔ یہ ایک عادت پراسرار outage کو دو منٹ کے menu selection میں بدل دیتی ہے۔ اگر آپ automation چاہتے ہیں لیکن اچانک reboot نہیں چاہتے تو automatic installs فعال اور automatic reboots غیر فعال رکھیں، اور درست settings کے لیے Ubuntu پر unattended-upgrades configure کرنے کا طریقہ دیکھیں۔ sudo apt-mark hold linux-image-generic کے ذریعے kernel packages کو hold کرنے سے وہ مکمل طور پر رک جاتے ہیں، اور اسی وقت kernel security fixes بھی رک جاتی ہیں۔ اس لیے اسے safety measure نہیں بلکہ ایک طے شدہ trade-off سمجھیں۔

FAQ

بغیر keyboard والے VPS پر پرانا kernel کیسے boot کروں؟

Provider کا console (VNC یا serial) کھولیں اور control panel سے hard reset شروع کریں، کیونکہ clean reboot کے لیے login کرنا ممکن نہیں۔ Machine کے restart ہوتے ہی Esc کو بار بار دبائیں، یا legacy BIOS boot پر Shift کو دبائے رکھیں، تاکہ GRUB menu کھلا رہے۔ "Advanced options for Ubuntu" منتخب کریں، پھر newest kernel کے نیچے موجود entry منتخب کریں۔ Login prompt آنے کے بعد uname -r چلائیں تاکہ معلوم ہو سکے کہ اس وقت کون سا kernel چل رہا ہے، اور dpkg -l 'linux-image-*' چلائیں تاکہ نصب شدہ دیگر kernels دیکھ سکیں۔ System کے دوبارہ چلنے کے بعد ہی diagnosis کریں۔

میرے VPS میں GRUB menu بالکل کیوں نہیں دکھتا؟

Cloud images عموماً /etc/default/grub.d/ کے اندر موجود file میں GRUB timeout کو 0 مقرر کرتی ہیں، اس لیے newest kernel بغیر کسی key press کے شروع ہو جاتا ہے۔ /etc/default/grub میں GRUB_TIMEOUT=10 اور GRUB_TIMEOUT_STYLE=menu مقرر کریں، اور GRUB_TERMINAL="console serial" شامل کریں تاکہ menu serial console پر بھی دستیاب ہو، پھر sudo update-grub چلائیں۔ grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ سے تصدیق کریں، کیونکہ اس directory کی files main file کے بعد پڑھی جاتی ہیں اور آپ کی تبدیلی کو override کر سکتی ہیں۔

کیا /boot میں جگہ خالی کرنے کے لیے پرانے kernels ہٹا دوں؟

سب سے پرانے kernels ہٹائیں اور کم از کم دو kernels رکھیں۔ مکمل /boot ایک الگ failure mode ہے، کیونکہ اس کے بعد initramfs generation ناکام ہو جاتی ہے اور آپ کے پاس ایسا kernel رہ جاتا ہے جس کی working image موجود نہیں ہوتی۔ uname -r چیک کرنے کے بعد exact package name کے ذریعے purge کریں، تاکہ running kernel کبھی candidate نہ بنے۔ Headless machine پر blanket sudo apt autoremove --purge سے گریز کریں، کیونکہ protected-kernel list ہر kernel change پر دوبارہ generate ہوتی ہے، اور غلط وقت پر چلنے والا command آپ کے پاس صرف ایک kernel چھوڑ سکتا ہے، جبکہ menu میں fallback entry موجود نہ ہو۔

کیا unattended-upgrades میرا boot خراب کر سکتا ہے؟

یہ ایسا kernel install کر سکتا ہے جو بعد میں boot ہونے میں ناکام ہو، لیکن machine کو restart نہیں کرتا، جب تک /etc/apt/apt.conf.d/50unattended-upgrades میں Unattended-Upgrade::Automatic-Reboot کو true مقرر نہ کیا گیا ہو۔ عام صورت حال میں failure تاخیر سے ظاہر ہوتی ہے: automatic run کے دوران kernel install ہوتا ہے، /var/run/reboot-required ظاہر ہوتا ہے، اور مسئلہ کئی ہفتوں بعد اگلے reboot پر سامنے آتا ہے۔ Console پہلے سے کھول کر سوچ سمجھ کر reboot کریں، اور /var/log/apt/history.log پڑھیں تاکہ معلوم ہو سکے کہ آپ کے boot ہونے والے kernel کو کس run نے install کیا تھا۔