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

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

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

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

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

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

/boot আলাদা partition কি না যাচাই করুন

কিছু মুছে ফেলার আগে, আসলে কোন স্থান খালি করছেন তা নির্ধারণ করুন।

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

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

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

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

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

চলমান kernel-এর সংস্করণ খুঁজে দেখুন

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

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

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

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

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

প্রথম field-টি dpkg-এর state code। ii মানে package ইনস্টল ও configured। iF মানে package ইনস্টল হয়েছে, কিন্তু configuration সম্পূর্ণ হয়নি। উপরের ব্যর্থ upgrade-এর পরে ঠিক এই অবস্থাই তৈরি হয়। rc মানে package remove করা হয়েছে, কিন্তু তার configuration disk-এ রয়ে গেছে। এটি /boot-এ কোনো স্থান দখল করে না এবং নিরাপদে purge করা যায়।

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

Family-গুলো এভাবে ভাগ করা থাকে। 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/

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

apt কোন kernel সংরক্ষণ করবে তা কীভাবে নির্ধারণ করে

apt autoremove যে kernel-কে protected হিসেবে বিবেচনা করে, সেটি সরাবে না। protected সেটের মধ্যে বর্তমানে চালু থাকা kernel-টিও থাকে। Ubuntu release-গুলোর মধ্যে retention policy পরিবর্তিত হয়েছে। তাই কোথাও লেখা কোনো সংখ্যার ওপর নির্ভর না করে নিজের machine-এ 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 ওই file-টি নতুন করে লেখে। তাই এটি হাতে সম্পাদনা করে লাভ নেই: পরবর্তী kernel install আপনার পরিবর্তনটি মুছে দিয়ে file-টি overwrite করবে। যেসব release-এ file-টি নেই, সেসব ক্ষেত্রে apt একই protection internally প্রয়োগ করে। উভয় ক্ষেত্রেই apt-config dump আপনার system-এ কার্যকর rules দেখায়। আপনার release-এর জন্য সেটিই সঠিক উত্তর।

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

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

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

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

sudo apt autoremove --purge
df -h /boot

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

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

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 হিসেবে যেসব package install করা হয়েছিল, সেগুলোই সরায়। আপনি apt install linux-image-6.8.0-40-generic ব্যবহার করে নিজে install করা কোনো kernel manual হিসেবে চিহ্নিত থাকে। সেটি যত পুরোনোই হোক, autoremove কখনো সেটিকে সরাবে না।

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

ওই output-এ থাকা version-সহ যেকোনো kernel autoremove-এর কাছে অদৃশ্য থাকে। নিজের listing থেকে পাওয়া version string ব্যবহার করে সেটিকে আবার manual হিসেবে চিহ্নিত করুন:

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 চলতে থাকে। তাই শুরুতে কোনো সমস্যা দেখা যায় না। সমস্যা হয় এমন সব উপাদানে, যেগুলো kernel এখনও লোড করেনি। Purging linux-modules-$(uname -r), /lib/modules/$(uname -r)/ মুছে দেয়। ফলে পরবর্তী module load ব্যর্থ হয়:

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

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

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

এই অবস্থার কারণেই মানুষ এই পৃষ্ঠাটি খুঁজে আসে। অর্ধেক-configure হওয়া 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 বিদ্যমান বলে বিশ্বাস করায়, যা বাস্তবে নেই। স্থান খালি হওয়ার পর apt --fix-broken install ব্যর্থ হওয়া configuration সম্পূর্ণ করে। এরপর autoremove --purge আপনি মুছে ফেলা file-সহ অন্যান্য পুরোনো version-এর package সরিয়ে দেয়। এতে dpkg আবার disk-এর প্রকৃত অবস্থার সঙ্গে সামঞ্জস্যপূর্ণ হয়। update-grub বাস্তবে বিদ্যমান file-গুলোর ভিত্তিতে 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 কার্যকর করে এবং নতুন কোনো install-এর ফলে সেই সীমা অতিক্রম করলে সঙ্গে সঙ্গে সবচেয়ে পুরোনো 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 ইনস্টল করার প্রক্রিয়াতেই এটি যুক্ত করুন। /etc/apt/apt.conf.d/50unattended-upgrades খুলে এই key-গুলো খুঁজুন। shipped file-এ এগুলো ইতিমধ্যে comment করা line হিসেবে রয়েছে:

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

শেষে দ্বিতীয় একটি copy যোগ না করে comment সরিয়ে এগুলো সক্রিয় করুন। apt configuration-এ কোনো key-এর সর্বশেষ assignment কার্যকর হয়। তাই duplicate থাকলে file-এর ভেতরেই পরস্পরবিরোধী মান থাকে এবং আসল মানটি কোনটি তা বোঝা যায় না। parser শেষ পর্যন্ত কী মান গ্রহণ করেছে তা যাচাই করুন। কোনো পরিবর্তন না করা একটি 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-এ 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-এর সঙ্গে এই check করতে এক মিনিটই যথেষ্ট। release upgrade-এর ঠিক আগে এটি সবচেয়ে গুরুত্বপূর্ণ। কারণ Ubuntu 24.04-কে 26.04-এ উন্নীত করা প্রক্রিয়ার শুরুতেই একটি নতুন kernel ইনস্টল করে, এবং do-release-upgrade-এ পর্যাপ্ত space না থাকলে /boot কাজ চালিয়ে যেতে অস্বীকার করবে।

FAQ

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

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