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

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

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

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

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

جب SSH کام نہ کر رہا ہو تو console تک کیسے پہنچیں؟

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

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

Boot menu تک پہنچنے کے لیے عموماً panel سے hard reset کرنا ہوگا، کیونکہ جس machine میں آپ login نہیں کر سکتے اس پر sudo reboot نہیں چلا سکتے۔ Hard reset بجلی منقطع کرنے کے برابر ہے۔ Filesystems کو unclean shutdown کا سامنا ہوگا، اس لیے اگلے boot پر filesystem check کی توقع رکھیں۔

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

reset دبانے کے لمحے سے console کو دیکھتے رہیں۔ ابتدائی سیکنڈز میں بار بار Esc دبائیں، یا legacy BIOS mode میں boot ہونے والی مشین پر Shift کو دبا کر رکھیں۔ یہ موقع بہت مختصر ہوتا ہے، اور 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 work کے لیے ہے، services کو دوبارہ online لانے کے لیے نہیں۔

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

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

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

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

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

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

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

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 کریں اور تصدیق کریں کہ آپ کی edit برقرار رہی ہے، کیونکہ /etc/default/grub.d/ میں موجود files کو /etc/default/grub کے بعد پڑھا جاتا ہے اور وہ آپ کی settings کو override کر سکتی ہیں۔

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

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

میں کس قسم کی خرابی دیکھ رہا ہوں؟

کنسول کا output رکنے سے پہلے کی آخری twenty lines پڑھیں۔ kernel update کے بعد پیش آنے والی زیادہ تر صورتوں کا احاطہ چار patterns کرتے ہیں۔

GRUB کو اپنی files نہیں مل رہیں۔ آپ کو 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 سے پہلے عموماً ایک message آتا ہے کہ root device کے انتظار سے دست بردار ہوا جا رہا ہے، اور اس میں مطلوبہ UUID دیا جاتا ہے۔ اس UUID کو copy کریں اور بعد میں blkid کے output سے اس کا موازنہ کریں۔

logical volume ظاہر نہیں ہوتا۔ یہ پچھلی class ہی ہے، لیکن اس کی ایک مخصوص وجہ ہے۔ (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 کو دوبارہ build کرنا ہے۔

Linux کی طرف سے بالکل کوئی output نہیں۔ کنسول پر firmware text، UEFI (unified extensible firmware interface) shell، kernel output کے بغیر blank screen، یا reset loop نظر آتا ہے۔ خرابی Linux کے چلنے سے پہلے واقع ہو رہی ہے۔ دوبارہ server کے up ہونے کے بعد دیکھیں کہ وہ حقیقت میں کون سا 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 کا unmounted رہ جانا 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 میں fail ہو گیا ہو۔ اس shell میں journalctl -xb چلائیں اور اس unit کا نام پڑھیں جو fail ہوئی ہے۔

کیا 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 بھرا ہوا ہو تو پہلے free 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

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

اگر menu میں موجود ہر entry ناکام ہو جائے تو provider کی rescue image سے boot کریں اور disk کو بیرونی ماحول سے repair کریں۔ آپ کی 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

نئے kernel کی جانچ اگلے boot کو خطرے میں ڈالے بغیر کریں

GRUB ایک entry کو صرف ایک بار start کر سکتا ہے، پھر آپ کے منتخب کردہ default پر واپس آ جاتا ہے۔ default کو قابلِ اعتماد kernel پر مقرر کریں، پھر نئے kernel کو صرف ایک boot کے لیے launch کریں۔ اگر یہ ناکام ہو جائے تو panel سے hard reset کرنے پر console میں وقت پر درست انتخاب کرنے کی ضرورت کے بغیر آپ اچھے kernel پر واپس آ جائیں گے۔

/etc/default/grub میں GRUB_DEFAULT=saved مقرر کریں، sudo update-grub چلائیں، پھر entry کے titles کی فہرست بنائیں تاکہ آپ ایک title کو عین مطابق نام دے سکیں:

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

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

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

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

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

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

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

اس آخری command کو بعد میں دوبارہ چلائیں۔ count کا three سے two ہونا cleanup ہے۔ count کا one تک پہنچنا اس outage کا انتظار ہے جو اگلے reboot پر پیش آئے گا۔

اپ گریڈ سے پہلے snapshot لیں

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

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

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 کس نے طلب کیا، لیکن جب تک آپ نے Unattended-Upgrade::Automatic-Reboot کو /etc/apt/apt.conf.d/50unattended-upgrades میں enable نہ کیا ہو، کچھ بھی restart نہیں ہوتا۔

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 انسٹال کیا تھا جس پر اب system fail ہو رہا ہے۔

اپنی مرضی سے، اپنے منتخب کردہ دن reboot کریں، اور console window پہلے سے کھلی رکھیں۔ یہ ایک عادت پراسرار outage کو دو منٹ کے menu selection میں بدل دیتی ہے۔ اگر آپ surprise کے بغیر automation چاہتے ہیں تو 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 نہیں کر سکتے۔ مشین کے 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 installed ہیں۔ diagnosis صرف اس وقت کریں جب system دوبارہ چل رہا ہو۔

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

Cloud images اکثر /etc/default/grub.d/ کے تحت موجود file میں GRUB timeout کو 0 مقرر کرتی ہیں، اس لیے newest kernel بغیر کسی key press کے start ہو جاتا ہے۔ /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 کے بعد پڑھی جاتی ہیں اور آپ کی edit کو override کر سکتی ہیں۔

کیا /boot میں جگہ خالی کرنے کے لیے پرانے kernels remove کرنے چاہییں؟

سب سے پرانے kernels remove کریں اور کم از کم دو 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 نہیں کرتے جب تک Unattended-Upgrade::Automatic-Reboot کو /etc/apt/apt.conf.d/50unattended-upgrades میں true مقرر نہ کیا گیا ہو۔ عام صورت delayed failure کی ہوتی ہے: automatic run کے دوران kernel install ہوتا ہے، /var/run/reboot-required ظاہر ہوتا ہے، اور مسئلہ کئی ہفتوں بعد اگلے reboot پر سامنے آتا ہے۔ Console پہلے سے کھلا رکھ کر سوچ سمجھ کر reboot کریں، اور یہ معلوم کرنے کے لیے /var/log/apt/history.log پڑھیں کہ جس kernel سے آپ boot کر رہے ہیں اسے کس run نے install کیا تھا۔