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

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

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

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

حقیقی خرابی کی صورت

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

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 name /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 کرنے کی کوشش کرتا ہے، اسی طرح fail ہوتا ہے، اور E: Sub-process /usr/bin/dpkg returned an error code (1) پر ختم ہو جاتا ہے۔ Disk space کے علاوہ اہم بات یہ ہے کہ unattended-upgrades اپنے مقررہ timer پر چلتا ہے، اسی error کا سامنا کرتا ہے، اور رک جاتا ہے۔ Server بظاہر درست رہتا ہے، مگر security patches خاموشی سے apply ہونا بند ہو جاتے ہیں۔ اس کا مطلب یہ بھی ہے کہ آپ کی جانے والی کوئی غیر متعلقہ install اسی line کے ساتھ fail ہو سکتی ہے، اور الزام اس package پر آتا ہے جسے آپ اس وقت add کر رہے ہوں۔ اسی لیے Ubuntu پر fail ہونے والی Tailscale install کو پہلے apt error کے طور پر پڑھنا مفید ہے۔ اگر apt update اس مرحلے تک پہنچنے سے پہلے fail ہو جائے تو یہ الگ مسئلہ ہے، جو اکثر deb822 sources migration کے بعد duplicate entry کی وجہ سے ہوتا ہے۔

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

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

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

پہلی کمانڈ صرف اسی وقت ایک سطر دکھاتی ہے جب /boot اپنا الگ mount point ہو۔ دوسری کمانڈ ہمیشہ output دیتی ہے اور اس filesystem کا نام بتاتی ہے جو حقیقت میں /boot کو رکھتا ہے۔ اگر دونوں کمانڈز اسی filesystem کا نام دیں جو / کے لیے ہے، تو /boot صرف root filesystem میں موجود ایک directory ہے اور یہ خود سے بھر نہیں سکتی۔ اس کا مطلب ہے کہ root filesystem بھر چکا ہے، اور پرانے kernels اس کی متعدد وجوہات میں سے صرف ایک ہیں۔ ایسی صورت میں sudo apt clean، جو /var/cache/apt/archives کے تحت download کی گئی .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 کے ایک اور جوڑے کی جگہ درکار ہوگی۔ اس لیے اگر 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 اور newest 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 انسٹال اور configured ہے۔ iF کا مطلب ہے کہ package انسٹال ہے، لیکن half-configured ہے۔ ناکام 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 پر dependency رکھنا ہے، تاکہ apt upgrade نئے kernels انسٹال کرے۔ Meta package کو remove کرنے سے machine کو kernel updates ملنا بند ہو جاتے ہیں، اور اس کے بعد کوئی warning ظاہر نہیں ہوتی۔

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

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

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

یہ طے کرنا کہ apt کون سے kernels برقرار رکھتا ہے

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

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 کو دوبارہ لکھتا ہے۔ اس لیے اسے manually edit کرنے کا کوئی فائدہ نہیں: اگلا kernel install آپ کی تبدیلی overwrite کر دے گا۔ جن releases میں یہ file موجود نہیں ہوتی، وہاں apt یہی protection internally نافذ کرتا ہے۔ دونوں صورتوں میں apt-config dump آپ کے box پر نافذ rules دکھاتا ہے، اور آپ کی release کے لیے درست جواب یہی output ہے۔

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

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

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

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

sudo apt autoremove --purge
df -h /boot

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

اس کے بعد تصدیق کریں کہ boot menu دوبارہ بنایا گیا ہے۔ 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 میں تبدیل کر سکتی ہے۔ یہی ایک وجہ ہے کہ kernel update کے بعد VPS 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 کے لیے نظر انداز ہوتا ہے۔ اپنی listing میں موجود 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 ہی ہونا چاہیے، کیونکہ یہی وہ packages ہیں جنہیں آپ نے خود 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 پہلے ہی memory میں load ہے، اس کی files حذف ہونے کے بعد بھی چلتا رہتا ہے، اس لیے ابتدا میں کچھ خراب ہوتا دکھائی نہیں دیتا۔ خرابی ان تمام چیزوں میں آتی ہے جنہیں 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 پر ہوتا ہے۔ machine network traffic فراہم کرتی رہتی ہے، لیکن پہلے ہی boot نہیں ہو سکتی۔ ہر بار uname -r کو removal list کے ساتھ ضرور چیک کریں۔

جب apt چلنے کے لیے /boot بالکل بھر جائے

یہ وہ صورت حال ہے جس میں لوگ اس صفحے کو تلاش کرتے ہیں۔ apt autoremove کو پہلے سے نصف configured 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 موجود ہے، حالانکہ وہ موجود نہیں ہوتی۔ اب، initramfs کے لیے جگہ بن جانے کے بعد، apt --fix-broken install اس configuration کو مکمل کرتا ہے جو ناکام ہوئی تھی۔ اس کے بعد autoremove --purge اس package کو، جس کی file آپ نے delete کی ہے، دیگر پرانے versions کے ساتھ remove کرتا ہے۔ اس سے dpkg disk کی موجودہ حالت کے مطابق ہو جاتا ہے۔ update-grub ان files سے menu دوبارہ بناتا ہے جو حقیقت میں موجود ہیں۔ rm اور update-grub کے درمیان reboot نہ کریں، کیونکہ اس وقفے میں menu اب بھی اس file کی طرف اشارہ کر سکتا ہے جسے آپ نے ابھی delete کیا ہے۔ اگر dpkg شکایت کرے کہ یہ interrupted ہے تو sudo dpkg --configure -a وہی repair کرتا ہے جو apt --fix-broken install کرتا ہے۔

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

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

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

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

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

ان کے سامنے موجود comment ختم کریں۔ آخر میں دوسری 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 درج ہوتا ہے۔ اس لیے space نہ ہونے کی وجہ سے ناکام ہونے والا upgrade، machine کے patches سے پیچھے رہ جانے کا پتا چلنے سے بہت پہلے log میں نظر آ جاتا ہے۔ اس configuration کے باقی حصے کی تفصیل Ubuntu پر خودکار security updates میں ہے۔

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

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

اگر Avail اس file سے واضح طور پر بڑا نہیں ہے تو اگلا kernel اوپر بیان کیے گئے طریقے سے ناکام ہو جائے گا۔ اس لیے upgrade کے دوران نہیں، ابھی اسے درست کریں۔ یہ check VPS پر اپنے دیگر disk health checks کے ساتھ کرنے میں صرف ایک منٹ لیتا ہے۔ release upgrade سے فوراً پہلے یہ خاص طور پر اہم ہے، کیونکہ Ubuntu 24.04 کو 26.04 پر منتقل کرنا عمل کے آغاز میں نیا kernel انسٹال کرتا ہے، اور do-release-upgrade اس وقت آگے بڑھنے سے انکار کر دے گا جب /boot میں کافی space نہ ہو۔ اگر آپ کے LTS server کو ابھی یہ upgrade پیش نہیں کیا گیا تو وجہ کوئی fault نہیں بلکہ timing ہے۔ Ubuntu LTS سے LTS upgrades کو 26.04.1 point release کے جاری ہونے تک روک کر رکھتا ہے۔ اس سے آپ کو /boot پہلے درست کرنے کے لیے ایک معلوم window مل جاتی ہے۔

FAQ

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

کیونکہ اگر کوئی kernel boot ہونے میں ناکام ہو جائے تو منتخب کرنے کے لیے آپ کے پاس کوئی دوسرا kernel نہیں رہتا۔ پچھلا version برقرار رکھنے سے خراب update کو provider rescue console کے بجائے GRUB menu سے بحال کیا جا سکتا ہے۔ apt اس لیے kernel packages کے ایک مجموعے کو automatic removal سے محفوظ رکھتا ہے، جس میں ہمیشہ وہ kernel شامل ہوتا ہے جس پر آپ اس وقت چل رہے ہیں۔ اپنے release کے محفوظ کردہ عین 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 شامل ہو تو عمل روک دیں، کیونکہ ان میں سے کسی ایک کو حذف کرنے سے آئندہ kernel updates ختم ہو جاتے ہیں۔ اگر اس میں وہ version string شامل ہو جو uname -r print کرتا ہے تو بھی عمل روک دیں۔ اگر دونوں میں سے کوئی بھی موجود نہ ہو تو حذف ہونے والی چیزیں پرانے kernels اور orphaned dependencies ہیں۔

apt autoremove نے کچھ حذف نہیں کیا اور /boot اب بھی بھرا ہوا ہے۔ اب کیا کریں؟

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

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

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