Ubuntu میں پرانے kernels ہٹا کر /boot خالی کریں

جب پرانے kernels سے /boot بھر جائے تو apt کیوں کام کرنا بند کر دیتا ہے

Ubuntu میں ہر kernel update، /boot میں فائلوں کا نیا مجموعہ لکھتا ہے اور پچھلی فائلیں وہیں رہنے دیتا ہے۔ اس طرح چھوٹا /boot partition بھر جاتا ہے اور apt install مکمل نہیں کر پاتا۔ مرمت کے دو مراحل ہیں۔ معلوم کریں کہ سسٹم پر کون سے packages kernels ہیں اور آپ نے کون سا kernel boot کیا ہے، پھر باقی packages کو apt autoremove --purge سے ہٹا دیں۔

ترتیب اہم ہے۔ running kernel وہ package ہے جسے آپ کو ہرگز remove نہیں کرنا چاہیے۔ ممکن ہے سسٹم پہلے ہی ایسی حالت میں ہو کہ apt بالکل نہ چل سکے۔ پہلے تشخیص کریں۔

اصل ناکامی کی صورتِ حال

ایک kernel version، /boot میں دو بڑی files انسٹال کرتا ہے: compressed kernel (vmlinuz-<version>) اور initramfs (initial RAM filesystem، initrd.img-<version>؛ یہ وہ چھوٹا archive ہے جسے kernel حقیقی root کو mount کرنے سے پہلے unpack کرتا ہے)۔ initramfs انسٹالیشن کے وقت آپ کی machine پر build ہوتا ہے۔ اسی لیے انسٹالیشن کے لیے صرف download bandwidth نہیں بلکہ خالی disk space بھی درکار ہوتی ہے۔ جب space ختم ہو جائے تو build ناکام ہو جاتا ہے، اور package بھی اسی کے ساتھ ناکام ہو جاتا ہے۔

update-initramfs: Generating /boot/initrd.img-6.8.0-64-generic
gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-6.8.0-64-generic with 1.
dpkg: error processing package linux-image-6.8.0-64-generic (--configure):
 installed linux-image-6.8.0-64-generic package post-installation script subprocess returned error exit status 1

version string آپ کی اپنی ہو گی۔ compressor کا نام /etc/initramfs-tools/initramfs.conf میں موجود COMPRESS= سے آتا ہے۔ اسی لیے نئی image میں zstd جبکہ پرانی image میں gzip نام آ سکتا ہے۔ اس مسئلے کی نشان دہی کرنے والی دو lines No space left on device اور اس کے نیچے موجود dpkg: error processing package line ہیں۔

اس کے بعد package half-configured حالت میں رہتا ہے۔ ہر بعد کی apt run اسے دوبارہ configure کرنے کی کوشش کرتی ہے، اسی طرح ناکام ہوتی ہے، اور E: Sub-process /usr/bin/dpkg returned an error code (1) پر ختم ہو جاتی ہے۔ Disk space سے آگے اہم بات یہ ہے: unattended-upgrades اپنے timer پر چلتا ہے، اسی error کا سامنا کرتا ہے، اور رک جاتا ہے۔ Server بظاہر درست حالت میں رہتا ہے، مگر خاموشی سے security patches لاگو کرنا بند کر دیتا ہے۔ اس کا مطلب یہ بھی ہے کہ آپ جس بھی غیر متعلقہ install کی کوشش کریں گے، وہ اسی line کے ساتھ ناکام ہو گی، اور ذمہ داری اس package پر عائد ہو گی جسے آپ اس وقت شامل کر رہے تھے۔ اسی لیے Ubuntu پر ناکام ہونے والی Tailscale installation کو پہلے apt error کے طور پر پڑھنا مفید ہے۔ اگر apt update اس مرحلے تک پہنچنے سے پہلے ناکام ہو جائے تو یہ الگ مسئلہ ہے، جو اکثر deb822 sources migration کے بعد duplicate entry کی وجہ سے ہوتا ہے۔

چیک کریں کہ آیا /boot الگ partition ہے

کچھ بھی delete کرنے سے پہلے معلوم کریں کہ حقیقت میں آپ کتنی جگہ خالی کر رہے ہیں۔

findmnt /boot
findmnt -T /boot
df -h /boot /

پہلی command صرف اسی وقت ایک line دکھاتی ہے جب /boot اپنا الگ mount point ہو۔ دوسری command ہمیشہ output دیتی ہے اور اس filesystem کا نام بتاتی ہے جو حقیقت میں /boot کو رکھتا ہے۔ اگر دونوں commands اسی filesystem کا نام دیں جو / کا ہے، تو /boot root filesystem میں موجود صرف ایک directory ہے اور یہ الگ سے full نہیں ہو سکتی: آپ کا root filesystem full ہے، اور پرانے kernels اس کی کئی وجوہات میں سے صرف ایک ہیں۔ ایسی صورت میں sudo apt clean، جو /var/cache/apt/archives کے اندر موجود downloaded .deb files کو خالی کرتا ہے، کچھ جگہ فراہم کرتا ہے۔ جس machine پر حقیقی /boot partition موجود ہو، وہاں apt clean اس partition میں کوئی جگہ خالی نہیں کرتا، کیونکہ cache مختلف filesystem پر موجود ہے۔

اب وہ number حاصل کریں جس کے مقابلے میں آپ کام کریں گے۔

df -h /boot
ls -lh /boot/vmlinuz-$(uname -r) /boot/initrd.img-$(uname -r)

Avail column کا ان دونوں files کے size کے ساتھ موازنہ کریں۔ initrd بڑی file ہے۔ اگلی kernel update کے لیے تقریباً اسی size کے ایک اور pair کو رکھنے کی جگہ درکار ہوگی، لہذا اگر Avail موجودہ initrd سے چھوٹا ہے تو اگلی update پہلے ہی fail ہونے والی ہے۔

چل رہے kernel کا تعین کریں

uname -r
cat /var/run/reboot-required.pkgs

uname -r اس وقت memory میں موجود kernel کی release string دکھاتا ہے۔ اس string کو کہیں محفوظ کر لیں۔ یہ وہ واحد version ہے جسے آپ کو ہرگز نہیں ہٹانا چاہیے۔

دوسری file صرف اس وقت موجود ہوتی ہے جب کسی package نے reboot کی درخواست کی ہو۔ اس میں موجود linux-image line کا مطلب ہے کہ disk پر نیا kernel installed ہے لیکن استعمال نہیں ہو رہا، کیونکہ اس کے install ہونے کے بعد machine reboot نہیں ہوئی۔ اگر ممکن ہو تو cleanup سے پہلے reboot کریں۔ apt چل رہے kernel اور جدید ترین kernel کو محفوظ رکھتا ہے، اس لیے پرانا kernel چلاتے ہوئے cleanup کرنے سے ضرورت سے ایک version زیادہ pinned رہتا ہے۔

kernel packages کی فہرست بنائیں اور ان کی حالت دیکھیں

dpkg --list | grep -E 'linux-(image|modules|headers|tools)' | awk '{print $1, $2}'

پہلا field، dpkg کا state code ہے۔ ii کا مطلب ہے کہ package install اور configure ہو چکا ہے۔ iF کا مطلب ہے کہ package install ہے، لیکن اس کی configuration نامکمل ہے۔ ناکام upgrade کے بعد یہی حالت باقی رہتی ہے۔ rc کا مطلب ہے کہ package remove ہو چکا ہے، لیکن اس کی configuration disk پر موجود ہے۔ یہ /boot میں کوئی جگہ استعمال نہیں کرتا اور اسے purge کرنا محفوظ ہے۔

دوسرا field بتاتا ہے کہ package کس نوعیت کا ہے۔ جس نام میں version شامل ہو، مثلاً linux-image-6.8.0-64-generic، وہ ایک مخصوص kernel ہے۔ جس نام میں version شامل نہ ہو، مثلاً linux-image-generic، linux-headers-generic یا linux-generic، وہ meta package ہے۔ اس میں kernel شامل نہیں ہوتا۔ اس کا کام صرف یہ ہے کہ newest versioned kernel پر depend کرے، تاکہ apt upgrade نئے kernels install کرے۔ meta package remove کرنے سے machine کو kernel updates ملنا بند ہو جاتے ہیں، اور اس کے بعد کوئی warning نہیں دکھائی جاتی۔

یہ families اس طرح تقسیم ہوتی ہیں۔ linux-image-* میں compressed kernel، /boot میں موجود ہوتا ہے۔ linux-modules-* اور linux-modules-extra-*، /lib/modules کے تحت drivers رکھتے ہیں۔ linux-headers-*، /usr/src کے تحت build headers رکھتا ہے۔ اس لیے headers کو purge کرنے سے root filesystem کی جگہ خالی ہوتی ہے، /boot کی جگہ نہیں۔ اگر مسئلہ full /boot partition کا ہے تو آپ کو image packages تلاش کرنے چاہییں۔

ls -1 /boot/vmlinuz-*
ls -1 /lib/modules/

یہ دونوں listings ایک دوسرے اور dpkg --list output کے ساتھ مطابقت رکھنی چاہییں۔ /lib/modules میں ایسی directory جس کا کوئی matching installed package نہ ہو، اس بات کی leftover ہے کہ کسی نے files دستی طور پر delete کی ہیں۔

apt یہ فیصلہ کیسے کرتا ہے کہ کون سے kernels برقرار رکھنے ہیں

apt autoremove ایسے kernel کو remove نہیں کرے گا جسے وہ protected سمجھتا ہو، اور اس protected set میں وہ kernel بھی شامل ہوتا ہے جو اس وقت چل رہا ہے۔ retention policy مختلف Ubuntu releases کے درمیان تبدیل ہوئی ہے، اس لیے کہیں درج کسی عدد پر بھروسا کرنے کے بجائے اسے اپنی مشین سے معلوم کریں۔

apt-config dump | grep -i -e neverautoremove -e versionedkernel
ls -l /etc/apt/apt.conf.d/01autoremove /etc/apt/apt.conf.d/01autoremove-kernels

APT::NeverAutoRemove ان package name patterns کی فہرست ہے جنہیں apt autoremove تبدیل کرنے سے انکار کرتا ہے۔ APT::VersionedKernelPackages ان name prefixes کی فہرست ہے جنہیں apt ابتدا ہی میں versioned kernel packages سمجھتا ہے۔ جن releases میں /etc/apt/apt.conf.d/01autoremove-kernels تیار ہوتا ہے، وہاں ہر kernel package install ہونے پر /etc/kernel/postinst.d/apt-auto-removal اس file کو دوبارہ لکھتا ہے۔ اس لیے اسے دستی طور پر edit کرنے کا کوئی فائدہ نہیں؛ اگلا kernel install آپ کی تبدیلی overwrite کر دے گا۔ جن releases میں یہ file موجود نہیں ہوتی، وہاں apt یہی protection اندرونی طور پر لاگو کرتا ہے۔ دونوں صورتوں میں apt-config dump آپ کے system پر نافذ rules دکھاتا ہے، اور آپ کے release کے لیے درست جواب وہی output ہے۔

محفوظ طریقے سے چلائی جانے والی صفائی

sudo apt update
sudo apt autoremove --purge --dry-run

--dry-run ڈسک پر کوئی تبدیلی نہیں کرتا اور بالکل وہی دکھاتا ہے جسے حقیقی run ہٹائے گا۔ فہرست پڑھیں۔ دو چیزیں آپ کو رکنے پر مجبور کرنی چاہییں۔ linux-generic یا linux-image-generic جیسا meta package اگر removal list میں ہو تو اس کا مطلب ہے کہ کسی عمل نے اسے automatic نشان زد کیا ہے، اور اسے ہٹانے سے kernel updates ختم ہو جائیں گی۔ uname -r کی string اگر removal list میں ہو تو اس کا مطلب ہے کہ چلتا ہوا kernel protected نہیں ہے۔ ایسا نہیں ہونا چاہیے، اس لیے آگے بڑھنے سے پہلے اس کی تحقیق ضروری ہے۔

اگر فہرست درست معلوم ہو تو اسے حقیقی طور پر چلائیں۔

sudo apt autoremove --purge
df -h /boot

--purge والا حصہ بچ جانے والی configuration کو package کے ساتھ ہٹا دیتا ہے۔ اس سے بہت کم اضافی جگہ خالی ہوتی ہے، لیکن dpkg --list میں rc lines جمع نہیں ہوتیں، جس سے اگلا audit پڑھنا آسان رہتا ہے۔

اس کے بعد تصدیق کریں کہ boot menu دوبارہ build ہو گیا ہے۔ kernel package ہٹانے سے update-grub خود بخود چلتا ہے، اس لیے menu میں صرف وہی files ہونی چاہییں جو اب بھی موجود ہیں۔

sudo grep -o 'vmlinuz-[^ ]*' /boot/grub/grub.cfg | sort -u
ls -1 /boot/vmlinuz-*

پہلے output میں موجود ہر version دوسرے output میں بھی ظاہر ہونا چاہیے۔ کسی ایسی file کی طرف اشارہ کرنے والی menu entry جو ختم ہو چکی ہو، working server کو GRUB prompt پر رکنے والے server میں بدل سکتی ہے۔ یہ ایسے VPS تک پہنچنے کا ایک راستہ ہے جو kernel update کے بعد boot نہیں ہوتا، اور اسے یہاں سے روکنے کے مقابلے میں rescue console سے درست کرنا کہیں زیادہ مشکل ہے۔

کیوں apt autoremove بعض اوقات کچھ بھی نہیں ہٹاتا

apt autoremove صرف ان packages کو ہٹاتا ہے جنہیں automatic کے طور پر نشان زد کیا گیا ہو۔ یعنی یہ وہ packages ہوتے ہیں جو کسی دوسری چیز کی dependency کے طور پر install کیے گئے ہوں۔ جس kernel کو آپ نے خود apt install linux-image-6.8.0-40-generic کے ذریعے install کیا ہو، اسے manual کے طور پر نشان زد کیا جاتا ہے، اور autoremove اسے کبھی نہیں ہٹاتا، چاہے وہ کتنا ہی پرانا کیوں نہ ہو۔

apt-mark showmanual | grep -E '^linux-'

اس output میں موجود versioned kernel autoremove کے لیے نظر نہیں آتے۔ اپنی فہرست میں موجود version strings استعمال کرتے ہوئے انہیں دوبارہ automatic کے طور پر نشان زد کریں:

sudo apt-mark auto linux-image-6.8.0-40-generic linux-modules-6.8.0-40-generic
sudo apt autoremove --purge --dry-run

meta packages کو manual کے طور پر نشان زد رہنے دیں۔ انہیں manual ہی ہونا چاہیے، کیونکہ آپ نے انہیں خود install کرنے کا کہا تھا۔

ایک مخصوص kernel کو جان بوجھ کر ہٹائیں

کبھی کبھی آپ چاہتے ہیں کہ کوئی مخصوص version فوراً ہٹا دیا جائے، نہ کہ policy کی اجازت ملنے تک انتظار کیا جائے۔ image package کا نام دیں اور apt کو باقی کام طے کرنے دیں۔

sudo apt purge linux-image-6.8.0-40-generic

apt کوئی کارروائی کرنے سے پہلے removal list دکھاتا ہے، کیونکہ linux-modules-extra-* image package پر منحصر ہے اور اسے اسی transaction میں ہٹانا ضروری ہے۔ یہ فہرست آپ کی اصل safety check ہے۔ اسی میں آپ دیکھ سکتے ہیں کہ مطلوبہ version کے ساتھ کوئی meta package بھی ہٹایا جا رہا ہے۔ اگر فہرست میں کوئی غیر متوقع چیز ہو تو n کا جواب دیں۔ اس کے بعد sudo apt autoremove --purge چلائیں تاکہ وہ module اور header packages جمع کیے جا سکیں جن کے موجود رہنے کی اب کوئی وجہ نہیں ہے۔

آپ چلتے ہوئے kernel کو کبھی کیوں حذف نہیں کرتے

میموری میں موجود kernel اپنی فائلیں حذف ہونے کے بعد بھی چلتا رہتا ہے، اس لیے ابتدا میں کچھ خراب دکھائی نہیں دیتا۔ خرابی ان چیزوں میں آتی ہے جنہیں kernel نے ابھی تک میموری میں load نہیں کیا۔ linux-modules-$(uname -r) کو purge کرنے سے /lib/modules/$(uname -r)/ حذف ہو جاتا ہے، اس لیے اگلی module load ناکام ہو جاتی ہے:

modprobe: FATAL: Module nf_tables not found in directory /lib/modules/6.8.0-64-generic

اس کے بعد firewall reload ناکام ہو جاتا ہے۔ ایسے filesystem type کو mount کرنا بھی ناکام ہو جاتا ہے جسے اس kernel نے boot کے بعد سے استعمال نہیں کیا۔ اسی دوران /boot/vmlinuz-$(uname -r) بھی حذف ہو جاتا ہے، اس لیے boot menu میں چلنے والا kernel دستیاب نہیں رہتا، اور اگلے reboot پر مشین کسی اور kernel سے boot ہوتی ہے۔ مشین network traffic فراہم کرتی رہتی ہے، لیکن پہلے ہی boot نہیں ہو سکتی۔ ہر بار uname -r کو removal list سے ضرور ملائیں۔

جب /boot اتنا بھر جائے کہ apt بالکل نہ چل سکے

یہ وہ صورتِ حال ہے جس میں لوگ اس صفحے کو تلاش کرتے ہوئے پہنچتے ہیں۔ apt autoremove کو پہلے سے جزوی طور پر configure شدہ kernel package کی configuration مکمل کرنے کے لیے dpkg درکار ہوتا ہے، اور یہ مرحلہ initramfs دوبارہ بناتا ہے۔ اس کے لیے /boot میں جگہ چاہیے، لیکن وہاں جگہ موجود نہیں ہوتی۔ اس چکر کو ایک مرتبہ دستی طور پر توڑیں۔

uname -r
ls -1 /boot/initrd.img-*

ایک ایسا initrd منتخب کریں جس کا version وہ string نہ ہو جو uname -r نے دی ہے، اور صرف وہ ایک file delete کریں۔

sudo rm /boot/initrd.img-6.8.0-40-generic
sudo apt --fix-broken install
sudo apt autoremove --purge
sudo update-grub

ہر line کی ایک وجہ ہے۔ rm ایک دانستہ exception ہے، جو dpkg کو یہ سمجھنے دیتا ہے کہ file موجود ہے، حالانکہ وہ موجود نہیں ہوتی۔ اب apt --fix-broken install اس configuration کو مکمل کرتا ہے جو پہلے ناکام ہوئی تھی، کیونکہ initramfs کے لیے جگہ دستیاب ہے۔ اس کے بعد autoremove --purge وہ package ہٹا دیتا ہے جس کی file آپ نے delete کی تھی، اور دیگر پرانے versions بھی ہٹا دیتا ہے۔ اس طرح dpkg دوبارہ disk کی اصل حالت کے مطابق ہو جاتا ہے۔ update-grub موجود files سے menu دوبارہ بناتا ہے۔ rm اور update-grub کے درمیان reboot نہ کریں، کیونکہ اس وقفے میں menu اب بھی اس file کی طرف اشارہ کر سکتا ہے جسے آپ نے ابھی delete کیا ہے۔ اگر dpkg یہ شکایت کرے کہ اس میں interruption ہوئی ہے تو sudo dpkg --configure -a وہی repair کرتا ہے جو apt --fix-broken install کرتا ہے۔

dnf سسٹمز پر یہی کام

اگر آپ کا VPS Fedora یا RHEL کی کسی rebuild، مثلاً Rocky Linux، پر چل رہا ہے تو طریقۂ کار مختلف ہے۔ Debian اور Ubuntu kernels کو apt autoremove قواعد کے ذریعے محفوظ رکھتے ہیں اور cleanup آپ یا unattended-upgrades کے شروع کرنے کے لیے چھوڑ دیتے ہیں، جبکہ dnf ایک تعداد نافذ کرتا ہے جسے installonly_limit کہا جاتا ہے، اور جیسے ہی نئی installation کے بعد یہ حد تجاوز ہونے لگے، سب سے پرانا kernel خودکار طور پر remove کر دیتا ہے۔ نافذ value کو grep installonly_limit /etc/dnf/dnf.conf اور man 5 dnf.conf سے دیکھیں، اور موجودہ backlog کو sudo dnf remove --oldinstallonly سے صاف کریں۔ وہاں بھی running kernel محفوظ رہتا ہے۔ دونوں package managers کے درمیان وسیع تر مطابقت کے لیے dnf اور apt کمانڈ کے متبادل دیکھیں۔

دوبارہ ایسا ہونے سے روکیں

ایسی صفائی جس کا انحصار آپ کے یاد رکھنے پر ہو، آخرکار ناکام ہو جائے گی۔ اس لیے اسے اسی configuration میں شامل کریں جو kernels install کرتی ہے۔ /etc/apt/apt.conf.d/50unattended-upgrades کھولیں اور ان keys کو تلاش کریں۔ فراہم کردہ file میں یہ پہلے ہی commented lines کے طور پر موجود ہوتی ہیں:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

ان lines کو uncomment کریں، آخر میں دوسری copy شامل نہ کریں۔ apt configuration میں کسی key کی آخری assignment مؤثر ہوتی ہے۔ اس لیے duplicate رکھنے سے file میں متضاد values آ جاتی ہیں اور یہ واضح نہیں رہتا کہ اصل value کون سی ہے۔ دیکھیں کہ parser نے آخرکار کیا value اختیار کی، اور ایسی run کو monitor کریں جو کچھ تبدیل نہ کرے:

apt-config dump | grep -i 'Unattended-Upgrade::Remove'
sudo unattended-upgrade --dry-run --debug
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Log اس کا ثبوت ہے۔ اس میں ہر run record ہوتی ہے۔ اس لیے space کم ہونے کی وجہ سے ناکام ہونے والا upgrade وہاں بہت پہلے نظر آ جاتا ہے، اس سے پہلے کہ کسی کو معلوم ہو کہ machine پر patches موجودہ نہیں ہیں۔ اس configuration کے باقی حصے کی وضاحت Ubuntu پر automatic security updates میں کی گئی ہے۔

اگلا kernel آنے سے پہلے ایک number چیک کریں۔ یہ وہی commands ہیں جو اس guide کے آغاز میں دی گئی تھیں:

df -h /boot
ls -lh /boot/initrd.img-$(uname -r)

اگر Avail اس file سے مناسب حد تک بڑا نہیں ہے تو اگلا kernel بالکل اوپر بیان کیے گئے طریقے سے fail ہو جائے گا۔ اس لیے upgrade کے دوران نہیں، ابھی اسے درست کریں۔ یہ check آپ کے دوسرے VPS پر disk health checks کے ساتھ ایک منٹ میں مکمل ہو جاتا ہے۔ یہ خاص طور پر release upgrade سے فوراً پہلے اہم ہے، کیونکہ Ubuntu 24.04 کو 26.04 پر منتقل کرنا process کے آغاز میں نیا kernel install کرتا ہے، اور space کم ہونے پر do-release-upgrade آگے بڑھنے سے انکار کر دے گا جب /boot دستیاب جگہ سے کم ہو۔

FAQ

Ubuntu پرانے kernels کو حذف کرنے کے بجائے کیوں محفوظ رکھتا ہے؟

کیونکہ اگر کوئی kernel boot ہونے میں ناکام ہو جائے تو انتخاب کے لیے آپ کے پاس کوئی دوسرا kernel نہیں رہتا۔ پچھلا version محفوظ رکھنے سے خراب update کو provider rescue console کے بجائے GRUB menu سے recover کیا جا سکتا ہے۔ apt اسی لیے kernel packages کے ایک set کو automatic removal سے محفوظ رکھتا ہے، اور اس set میں ہمیشہ وہ kernel شامل ہوتا ہے جس پر آپ اس وقت چل رہے ہیں۔ اپنی release کے محفوظ کردہ exact patterns دیکھنے کے لیے apt-config dump | grep -i neverautoremove چلائیں، کیونکہ releases کے درمیان یہ policy تبدیل ہو چکی ہے۔

کیا apt autoremove --purge کو production server پر چلانا محفوظ ہے؟

ہاں، بشرطیکہ آپ پہلے dry run پڑھ لیں۔ sudo apt autoremove --purge --dry-run چلائیں۔ یہ کچھ write نہیں کرتا، اور آپ printed list کی جانچ کر سکتے ہیں۔ اگر اس میں linux-generic یا linux-image-generic جیسا meta package شامل ہو تو رک جائیں، کیونکہ ان میں سے کسی ایک کو remove کرنے سے آئندہ kernel updates بند ہو جاتے ہیں۔ اگر اس میں وہ version string شامل ہو جو uname -r print کرتا ہے تو بھی رک جائیں۔ اگر ان دونوں میں سے کوئی بھی موجود نہ ہو تو removals پرانے kernels اور orphaned dependencies ہیں۔

apt autoremove نے کچھ remove نہیں کیا اور /boot اب بھی full ہے۔ اب کیا کریں؟

پرانے kernels تقریباً یقینی طور پر manual کے طور پر marked ہیں، جبکہ autoremove صرف ان packages کو ہٹاتا ہے جو automatic کے طور پر marked ہوں۔ apt-mark showmanual | grep -E '^linux-' چلائیں۔ وہاں درج ہر versioned kernel کسی وقت manually install کیا گیا تھا۔ اسے sudo apt-mark auto linux-image-<version> کے ذریعے automatic mark کریں اور dry run دوبارہ چلائیں، یا اس ایک version کو براہ راست sudo apt purge linux-image-<version> کے ذریعے purge کریں۔

کیا میں /boot سے files دستی طور پر delete کر سکتا ہوں؟

صرف ایک دانستہ one-off کارروائی کے طور پر، جب /boot اتنا full ہو کہ apt broken kernel package کو configure نہ کر سکے۔ ایک ایسی initrd.img-<version> file delete کریں جس کا version uname -r کے output میں موجود نہ ہو، پھر فوراً sudo apt --fix-broken install، sudo apt autoremove --purge اور sudo update-grub چلائیں۔ ان follow-up steps کے بغیر files delete کرنے سے dpkg ایسے packages record کرتا رہتا ہے جن کی files موجود نہیں، جبکہ GRUB menu entries missing files کی طرف اشارہ کرتی رہتی ہیں۔ نتیجتاً machine اس وقت fail نہیں ہوتی جب آپ یہ غلطی کرتے ہیں، بلکہ اگلے reboot پر fail ہوتی ہے۔