Ubuntu-তে পুরোনো kernel সরিয়ে /boot খালি করার নিয়ম

পুরোনো kernel-এ /boot ভরে গেলে apt কেন কাজ করা বন্ধ করে

Ubuntu-তে প্রতিটি kernel update /boot-এ নতুন ফাইলের একটি সেট লেখে এবং আগের ফাইলগুলো রেখে দেয়। তাই ছোট /boot partition ভরে যায় এবং apt আর install শেষ করতে পারে না। মেরামতের কাজ দুই ধাপে করতে হয়। সিস্টেমে কোন package-গুলো kernel এবং বর্তমানে কোন kernel দিয়ে boot করা হয়েছে তা নির্ধারণ করুন। এরপর apt autoremove --purge ব্যবহার করে বাকি package-গুলো সরিয়ে ফেলুন।

ক্রমটি গুরুত্বপূর্ণ। বর্তমানে চলমান kernel-টির package কোনোভাবেই সরানো যাবে না। এমনও হতে পারে যে সিস্টেম ইতিমধ্যে এমন অবস্থায় আছে যেখানে apt একেবারেই চালানো যায় না। আগে diagnosis করুন।

ব্যর্থতাটি আসলে যে রকম দেখা যায়

একটি kernel version /boot-এ দুটি বড় file install করে: compressed kernel (vmlinuz-<version>) এবং initramfs (initial RAM filesystem, initrd.img-<version>; এটি একটি ছোট archive, যেটি real root mount করার আগে kernel unpack করে)। Install-এর সময় আপনার machine-এ initramfs তৈরি হয়। তাই install-এর জন্য শুধু download bandwidth নয়, free 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 আপনার system-এর হবে। Compressor-এর নাম /etc/initramfs-tools/initramfs.conf-এর COMPRESS= থেকে আসে। তাই সাম্প্রতিক image-এ zstd এবং পুরোনো image-এ gzip দেখা যেতে পারে। এই সমস্যাটি শনাক্ত করে এমন দুটি line হলো 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 নির্ধারিত সময়ে run করে, একই error পায় এবং থেমে যায়। Server স্বাভাবিক দেখায়, কিন্তু নীরবে security patch প্রয়োগ করা বন্ধ করে দেয়। এর অর্থ, আপনি কোনো unrelated install করার চেষ্টা করলেও সেটি একই line-এ ব্যর্থ হয় এবং দোষটি সেই সময়ে যে package যোগ করছিলেন তার ওপর পড়ে। তাই Ubuntu-তে ব্যর্থ হওয়া Tailscale install-কে প্রথমে apt error হিসেবে বিশ্লেষণ করা উপযোগী। আপনি এই অবস্থায় পৌঁছানোর আগেই যদি apt update ব্যর্থ হয়, তাহলে সেটি আলাদা সমস্যা। এর একটি সাধারণ কারণ হলো deb822 sources migration-এর পরে duplicate entry।

/boot আলাদা পার্টিশন কি না পরীক্ষা করুন

কিছু মুছে ফেলার আগে জেনে নিন, আসলে কোন জায়গা খালি করছেন।

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

প্রথম কমান্ডটি কেবল তখনই একটি লাইন দেখায়, যখন /boot নিজস্ব mount point হয়। দ্বিতীয় কমান্ডটি সব সময় ফলাফল দেখায় এবং /boot ধারণ করা প্রকৃত filesystem-এর নাম দেয়। যদি উভয় কমান্ডের ফলাফল /-এর মতো একই filesystem নির্দেশ করে, তাহলে /boot আসলে root filesystem-এর একটি directory এবং এটি নিজে থেকে পূর্ণ হতে পারে না: আপনার root filesystem পূর্ণ, আর পুরোনো kernel-গুলো তার অনেকগুলোর মধ্যে একটি কারণ। সে ক্ষেত্রে sudo apt clean চালালে জায়গা খালি হবে। এটি /var/cache/apt/archives-এর অধীনে ডাউনলোড করা .deb ফাইল মুছে দেয়। বাস্তব /boot partition থাকা মেশিনে apt clean সেখানে কোনো জায়গা খালি করে না, কারণ cache অন্য filesystem-এ থাকে।

এখন যে সংখ্যার ভিত্তিতে কাজ করবেন, সেটি সংগ্রহ করুন।

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

Avail column-এর মান ওই দুটি ফাইলের আকারের সঙ্গে তুলনা করুন। initrd ফাইলটি বড়। পরবর্তী kernel update-এর জন্য প্রায় ওই আকারের আরও একটি জোড়ার জায়গা প্রয়োজন হবে। তাই Avail বর্তমান initrd-এর চেয়ে ছোট হলে পরবর্তী update ইতিমধ্যেই ব্যর্থ হবে।

চলমান kernel শনাক্ত করুন

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

uname -r বর্তমানে memory-তে থাকা kernel-এর release string দেখায়। এই string কোথাও কপি করে রাখুন। এটিই সেই version, যেটি কোনোভাবেই সরানো যাবে না।

কোনো package reboot-এর অনুরোধ করলেই কেবল দ্বিতীয় file-টি তৈরি হয়। এতে linux-image line থাকলে disk-এ একটি নতুন kernel installed আছে, কিন্তু সেটি ব্যবহৃত হচ্ছে না, কারণ সেটি installed হওয়ার পর machine reboot করা হয়নি। সম্ভব হলে cleanup করার আগে reboot করুন। apt চলমান kernel এবং সর্বশেষ kernel-কে সুরক্ষিত রাখে। তাই পুরোনো kernel চালু থাকা অবস্থায় cleanup করলে প্রয়োজনের চেয়ে আরও একটি version pinned থাকে।

কার্নেল প্যাকেজের তালিকা দেখুন এবং তাদের অবস্থা পরীক্ষা করুন

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

প্রথম ফিল্ডটি dpkg-এর state code। ii মানে প্যাকেজটি ইনস্টল ও কনফিগার করা আছে। iF মানে প্যাকেজটি ইনস্টল করা হলেও আংশিকভাবে কনফিগার করা হয়েছে। উপরের ব্যর্থ upgrade-এর পরে ঠিক এই অবস্থাই থেকে যায়। rc মানে প্যাকেজটি অপসারণ করা হয়েছে, কিন্তু এর configuration এখনও disk-এ আছে। এটি /boot-এ কোনো জায়গা দখল করে না এবং নিরাপদে purge করা যায়।

দ্বিতীয় ফিল্ডটি প্যাকেজটির ধরন জানায়। linux-image-6.8.0-64-generic-এর মতো version-সহ নাম একটি নির্দিষ্ট kernel নির্দেশ করে। linux-image-generic, linux-headers-generic বা linux-generic-এর মতো version ছাড়া নাম একটি meta package নির্দেশ করে। এতে কোনো kernel থাকে না। এর একমাত্র কাজ হলো সর্বশেষ version-যুক্ত kernel-এর ওপর নির্ভর করা, যাতে apt upgrade নতুন kernel ইনস্টল করে। Meta package সরিয়ে দিলে মেশিনে আর kernel update পৌঁছাবে না, এবং পরে এ বিষয়ে কোনো সতর্কতা দেখানো হবে না।

পরিবারগুলো এভাবে ভাগ করা হয়। linux-image-*-এ /boot-এর compressed kernel থাকে। linux-modules-* এবং linux-modules-extra-*-এ /lib/modules-এর অধীনে থাকা driver থাকে। linux-headers-*-এ /usr/src-এর অধীনে build header থাকে। তাই header purge করলে root filesystem-এর জায়গা খালি হয়, /boot-এর জায়গা নয়। আপনার সমস্যা যদি পূর্ণ /boot partition হয়, তাহলে যে image package-গুলো খুঁজছেন সেগুলোই এখানে রয়েছে।

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

এই দুটি তালিকার তথ্য একে অপরের সঙ্গে এবং dpkg --list output-এর সঙ্গে মিল থাকা উচিত। /lib/modules-এর কোনো directory-র সঙ্গে matching installed package না থাকলে সেটি সাধারণত কেউ হাতে file মুছে ফেলার পরে পড়ে থাকা অবশিষ্টাংশ।

apt কোন kernel রেখে দেবে তা কীভাবে নির্ধারণ করে

apt autoremove যে kernel-কে সুরক্ষিত মনে করে, সেটি সরাবে না। সুরক্ষিত সেটে বর্তমানে যে kernel চালু আছে, সেটিও অন্তর্ভুক্ত থাকে। Ubuntu release-গুলোর মধ্যে retention policy পরিবর্তিত হয়েছে। তাই কোথাও লেখা কোনো সংখ্যার ওপর নির্ভর না করে নিজের মেশিন থেকেই policy দেখে নিন।

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 pattern-গুলোর তালিকা, যেগুলোতে apt autoremove কোনো পরিবর্তন করে না। APT::VersionedKernelPackages হলো name prefix-গুলোর তালিকা, যেগুলোকে apt প্রথমে versioned kernel package হিসেবে বিবেচনা করে। যেসব release-এ /etc/apt/apt.conf.d/01autoremove-kernels তৈরি হয়, সেসব release-এ প্রতিবার কোনো kernel package install হলে /etc/kernel/postinst.d/apt-auto-removal ফাইলটি নতুন করে লেখে। তাই ফাইলটি হাতে সম্পাদনা করে কোনো লাভ নেই: পরবর্তী kernel install আপনার পরিবর্তনটি overwrite করবে। যেসব release-এ ফাইলটি অনুপস্থিত, সেসব ক্ষেত্রে apt একই protection অভ্যন্তরীণভাবে প্রয়োগ করে। যেকোনো অবস্থায় apt-config dump আপনার সিস্টেমে কার্যকর rules দেখায়। আপনার release-এর জন্য সঠিক উত্তর হলো ওই output।

যে cleanup নিরাপদে চালানো যায়

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

--dry-run ডিস্কে কোনো পরিবর্তন করে না এবং প্রকৃত run-এ যা remove করা হতো, ঠিক সেই তালিকা দেখায়। তালিকাটি পড়ুন। দুটি বিষয় দেখলে থামুন। removal list-এ linux-generic বা linux-image-generic-এর মতো কোনো meta package থাকলে বুঝতে হবে, কোনো কিছু সেটিকে automatic হিসেবে চিহ্নিত করেছে। সেটি remove করলে kernel update বন্ধ হয়ে যাবে। removal list-এ uname -r-এর string থাকলে বুঝতে হবে চলমান kernel সুরক্ষিত নয়। এটি হওয়ার কথা নয়। পরবর্তী ধাপে যাওয়ার আগে বিষয়টি তদন্ত করুন।

তালিকাটি সঠিক মনে হলে এবার প্রকৃত run চালান।

sudo apt autoremove --purge
df -h /boot

--purge অংশটি package-এর পাশাপাশি অবশিষ্ট configuration-ও delete করে। এতে সামান্য অতিরিক্ত জায়গা খালি হয়। একই সঙ্গে dpkg --list-এ অতিরিক্ত rc line জমে না, ফলে পরবর্তী audit পড়া সহজ থাকে।

এরপর নিশ্চিত করুন যে boot menu পুনর্নির্মাণ করা হয়েছে। কোনো kernel package remove করলে update-grub নিজে থেকেই চালানো হয়। তাই menu-তে শুধু বর্তমানে বিদ্যমান file-গুলোর reference থাকার কথা।

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

প্রথম output-এ থাকা প্রতিটি version দ্বিতীয় output-এও থাকতে হবে। মুছে যাওয়া কোনো file-এর দিকে নির্দেশ করা menu entry-র কারণেই সচল server GRUB prompt-এ থেমে যেতে পারে। এটি kernel update-এর পরে boot না করা VPS-এর একটি কারণ। এখানে সমস্যাটি এড়ানো, rescue console থেকে পরে ঠিক করার চেয়ে অনেক সহজ।

apt autoremove কখনো কিছু সরায় না কেন

apt autoremove শুধু automatic হিসেবে চিহ্নিত package সরায়। অর্থাৎ, এগুলো অন্য কোনো package-এর dependency হিসেবে install করা হয়েছিল। আপনি apt install linux-image-6.8.0-40-generic দিয়ে নিজে install করা কোনো kernel manual হিসেবে চিহ্নিত থাকে। সেটি যত পুরোনোই হোক, autoremove কখনো সেটি সরাবে না।

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

ওই output-এ থাকা যেকোনো versioned kernel autoremove-এর কাছে অদৃশ্য থাকে। আপনার নিজের তালিকা থেকে version string ব্যবহার করে সেটিকে আবার 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 package-গুলো manual হিসেবে চিহ্নিত রাখুন। এগুলো manual হওয়ারই কথা, কারণ এগুলো আপনি নিজে install করার জন্য নির্বাচন করেছেন।

নির্দিষ্ট একটি kernel ইচ্ছাকৃতভাবে সরান

কখনও policy অনুমতি দেওয়ার সময় পর্যন্ত অপেক্ষা না করে নির্দিষ্ট একটি version এখনই সরাতে হতে পারে। image package-এর নাম দিন এবং বাকি কাজ apt-কে করতে দিন।

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

কোনো কাজ করার আগে apt অপসারণের তালিকা দেখায়, কারণ linux-modules-extra-* image package-এর ওপর নির্ভর করে এবং একই transaction-এ এটিকেও সরাতে হয়। এই প্রদর্শিত তালিকাই আপনার প্রকৃত safety check। এখানেই বোঝা যায়, যে version সরাতে চেয়েছিলেন তার সঙ্গে কোনো meta package-ও সরানোর তালিকায় এসেছে কি না। তালিকায় অপ্রত্যাশিত কিছু থাকলে n-এর উত্তর দিন। এরপর sudo apt autoremove --purge চালিয়ে এমন module এবং header package সংগ্রহ করুন, যেগুলোর এখন আর থাকার প্রয়োজন নেই।

কেন চলমান kernel কখনো অপসারণ করবেন না

মেমরিতে আগে থেকেই থাকা kernel-এর ফাইল মুছে ফেললেও সেটি চলতে থাকে। তাই শুরুতে কিছু নষ্ট হয়েছে বলে মনে হয় না। নষ্ট হয় kernel যে উপাদানগুলো এখনো লোড করেনি, সেগুলো। 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 ব্যর্থ হয়। boot-এর পর এই kernel যে filesystem type কখনো ব্যবহার করেনি, সেটি mount করাও ব্যর্থ হয়। এদিকে /boot/vmlinuz-$(uname -r) আর থাকে না। তাই boot menu-তে আপনি যে kernel চালাচ্ছেন, সেটি আর দেখায় না। পরবর্তী reboot অন্য kernel-এ হয়। মেশিন network traffic পরিবেশন করতে থাকে, কিন্তু ইতিমধ্যে boot করা যায় না। প্রতিবার uname -r-কে removal list-এর সঙ্গে মিলিয়ে দেখুন।

/boot এতটাই পূর্ণ হলে apt একেবারেই চলতে পারে না

এটাই সেই অবস্থা, যার কারণে মানুষ এই পৃষ্ঠাটি খুঁজে আসে। অর্ধেক কনফিগার হওয়া kernel package-এর configuration সম্পন্ন করতে apt autoremove-এর প্রথমে dpkg প্রয়োজন। ওই ধাপে একটি initramfs পুনর্নির্মাণ করা হয়, যার জন্য এমন একটি /boot-এ জায়গা দরকার যেখানে কোনো জায়গাই অবশিষ্ট নেই। একবার হাতে করে এই চক্রটি ভেঙে দিন।

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

যে initrd-এর version uname -r প্রদত্ত string নয়, সেটির মধ্যে একটি বেছে নিয়ে ওই একটিমাত্র file মুছে দিন।

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

প্রতিটি লাইনের একটি নির্দিষ্ট কারণ আছে। rm একটি ইচ্ছাকৃত ব্যতিক্রম, যা dpkg-কে এমন বিশ্বাস করায় যে একটি file আছে, যদিও সেটি নেই। এখন initramfs-এর জন্য জায়গা তৈরি হওয়ায় apt --fix-broken install ব্যর্থ হওয়া configuration সম্পন্ন করে। এরপর autoremove --purge আপনি মুছে ফেলা file-সহ অন্যান্য পুরোনো version-এর package সরিয়ে দেয়। এতে dpkg disk-এর প্রকৃত অবস্থার সঙ্গে আবার সামঞ্জস্যপূর্ণ হয়। বিদ্যমান file-গুলোর ভিত্তিতে update-grub menu পুনর্নির্মাণ করে। rm এবং update-grub-এর মাঝখানে reboot করবেন না, কারণ ওই সময়ে menu এখনও আপনি মুছে ফেলা file-টির দিকে নির্দেশ করতে পারে। dpkg যদি জানায় যে এটি interrupted হয়েছে, তাহলে sudo dpkg --configure -a, apt --fix-broken install-এর মতো একই repair সম্পন্ন করে।

dnf সিস্টেমে একই কাজ

আপনার VPS যদি Fedora অথবা Rocky Linux-এর মতো RHEL rebuild-গুলোর কোনো একটি চালায়, তাহলে প্রক্রিয়াটি উল্টো। Debian এবং Ubuntu apt autoremove rule ব্যবহার করে kernel সুরক্ষিত রাখে এবং cleanup আপনার বা unattended-upgrades-এর মাধ্যমে চালানোর জন্য রেখে দেয়। অন্যদিকে dnf installonly_limit নামে একটি count কার্যকর করে এবং নতুন installation-এর ফলে সেই সীমা অতিক্রম করার সঙ্গে সঙ্গে স্বয়ংক্রিয়ভাবে সবচেয়ে পুরোনো kernel সরিয়ে দেয়। বর্তমানে কার্যকর value দেখতে grep installonly_limit /etc/dnf/dnf.conf এবং man 5 dnf.conf ব্যবহার করুন। বিদ্যমান backlog পরিষ্কার করতে sudo dnf remove --oldinstallonly চালান। এখানেও চলমান kernel সুরক্ষিত থাকে। দুই package manager-এর বিস্তৃত তুলনার জন্য dnf ও apt command-এর সমতুল্যতা দেখুন।

আবার যেন না ঘটে

আপনার মনে রাখার ওপর নির্ভর করা cleanup শেষ পর্যন্ত ব্যর্থ হবে। তাই এটি kernel install করার প্রক্রিয়াতেই যুক্ত করুন। /etc/apt/apt.conf.d/50unattended-upgrades খুলে নিচের key-গুলো খুঁজুন। shipped file-এ এগুলো commented line হিসেবে আগে থেকেই থাকে:

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

ফাইলের শেষে দ্বিতীয় copy যোগ না করে সেগুলো uncomment করুন। apt configuration-এ কোনো key-এর সর্বশেষ assignment কার্যকর হয়। তাই duplicate থাকলে ফাইলটি নিজের সঙ্গেই অসঙ্গত হয়ে যায় এবং কোন 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-টি patch থেকে পিছিয়ে পড়েছে বুঝতে পারার অনেক আগেই log-এ দেখা যায়। এই configuration-এর বাকি অংশ Ubuntu-তে automatic security updates-এ ব্যাখ্যা করা হয়েছে।

পরবর্তী kernel আসার আগে একটি সংখ্যা পরীক্ষা করতে হবে। শুরুতে এই guide-এ ব্যবহৃত একই জোড়া command চালান:

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

Avail যদি ওই file-এর চেয়ে যথেষ্ট বড় না হয়, তাহলে পরবর্তী kernel উপরে বর্ণিতভাবেই ব্যর্থ হবে। তাই upgrade চলার সময় নয়, এখনই সমস্যা ঠিক করুন। VPS-এ আপনার অন্যান্য disk health checks-এর সঙ্গে এই পরীক্ষা করতে এক মিনিটের বেশি লাগবে না। Release upgrade-এর ঠিক আগে এটি সবচেয়ে গুরুত্বপূর্ণ। কারণ Ubuntu 24.04-কে 26.04-এ upgrade করা প্রক্রিয়ার শুরুতেই একটি নতুন kernel install করে, এবং do-release-upgrade-এ পর্যাপ্ত space না থাকলে /boot কাজ চালিয়ে যেতে অস্বীকার করে। আপনার LTS server-এ এখনো ওই upgrade-এর প্রস্তাব না এলে সেটি কোনো fault নয়, timing-এর বিষয়। Ubuntu 26.04.1 point release প্রকাশ না হওয়া পর্যন্ত LTS থেকে LTS upgrade আটকে রাখে। ফলে আগে /boot প্রস্তুত করার জন্য আপনার হাতে একটি নির্দিষ্ট সময় থাকে।

FAQ

Ubuntu পুরোনো kernel মুছে না ফেলে রেখে দেয় কেন?

কারণ কোনো kernel boot হতে ব্যর্থ হলে নির্বাচন করার মতো অন্য কিছু নাও থাকতে পারে। আগের version রেখে দিলে খারাপ update থেকে provider rescue console নয়, GRUB menu ব্যবহার করে পুনরুদ্ধার করা যায়। apt তাই কিছু kernel package-কে automatic removal থেকে সুরক্ষিত রাখে এবং আপনি বর্তমানে যে kernel ব্যবহার করছেন, সেটিকে সব সময় অন্তর্ভুক্ত করে। আপনার release কোন exact pattern সুরক্ষিত রাখে তা দেখতে apt-config dump | grep -i neverautoremove চালান, কারণ release ভেদে policy পরিবর্তিত হয়েছে।

Production server-এ apt autoremove --purge চালানো কি নিরাপদ?

হ্যাঁ, তবে আগে dry run পড়ে দেখুন। sudo apt autoremove --purge --dry-run চালান; এটি কোনো কিছু লিখবে না। এরপর প্রদর্শিত তালিকা পরীক্ষা করুন। তালিকায় linux-generic বা linux-image-generic-এর মতো meta package থাকলে থামুন, কারণ এগুলোর কোনোটি সরিয়ে ফেললে ভবিষ্যতের kernel update বন্ধ হয়ে যায়। তালিকায় uname -r প্রদর্শিত version string থাকলেও থামুন। এগুলোর কোনোটিই না থাকলে, সরানোর জন্য চিহ্নিত package-গুলো পুরোনো kernel এবং orphaned dependency।

apt autoremove কিছু সরায়নি এবং /boot এখনও পূর্ণ। এখন কী করব?

পুরোনো kernel-গুলো প্রায় নিশ্চিতভাবে manual হিসেবে চিহ্নিত আছে, আর autoremove শুধু automatic হিসেবে চিহ্নিত package-এ কাজ করে। apt-mark showmanual | grep -E '^linux-' চালান। সেখানে তালিকাভুক্ত version-যুক্ত যেকোনো kernel কোনো সময় হাতে install করা হয়েছিল। sudo apt-mark auto linux-image-<version> ব্যবহার করে সেটিকে automatic হিসেবে চিহ্নিত করুন এবং আবার dry run চালান, অথবা sudo apt purge linux-image-<version> ব্যবহার করে সরাসরি সেই version purge করুন।

আমি কি হাতে /boot-এর file মুছে ফেলতে পারি?

শুধু ইচ্ছাকৃত এককালীন ব্যবস্থা হিসেবে, যখন /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 ধাপগুলো ছাড়া file মুছে ফেললে dpkg এমন package record করে যেগুলোর file আর নেই এবং GRUB menu-তে অনুপস্থিত file-এর দিকে নির্দেশ করা entry রেখে দেয়। ফলে ভুলটি করার মুহূর্তে নয়, পরবর্তী reboot-এর সময় machine ব্যর্থ হয়।