پاکسازی هسته های قدیمی در Ubuntu برای خالی کردن /boot

چرا وقتی پارتیشن /boot با هسته‌های قدیمی پر می‌شود، apt از کار می‌افتد

در سیستم‌عامل Ubuntu، هر به‌روزرسانی هسته (kernel)، مجموعه‌ای از فایل‌های جدید را در /boot می‌نویسد و فایل‌های قبلی را حذف نمی‌کند. در نتیجه، پارتیشن کوچک /boot پر شده و apt دیگر نمی‌تواند عملیات نصب را به پایان برساند. برای رفع این مشکل باید دو مرحله را طی کنید: ابتدا مشخص کنید کدام بسته‌ها مربوط به هسته هستند و کدام‌یک در حال حاضر در حال اجراست، سپس بقیه موارد را با apt autoremove --purge حذف کنید.

ترتیب انجام کار اهمیت دارد. هسته در حال اجرا تنها بسته‌ای است که نباید حذف شود، و ممکن است سیستم در حال حاضر در وضعیتی باشد که apt اصلاً اجرا نشود. بنابراین ابتدا عیب‌یابی کنید.

ماهیت واقعی خطا

یک نسخه از هسته (kernel)، دو فایل حجیم را در /boot نصب می‌کند: هسته فشرده‌شده (vmlinuz-<version>) و initramfs (فایل‌سیستم اولیه RAM، initrd.img-<version>، که یک آرشیو کوچک است و هسته پیش از mount کردن ریشه اصلی، آن را استخراج می‌کند). فایل initramfs در زمان نصب روی سیستم شما ساخته می‌شود؛ به همین دلیل است که فرآیند نصب علاوه بر پهنای باند دانلود، به فضای خالی دیسک نیز نیاز دارد. با اتمام فضای دیسک، عملیات ساخت با شکست مواجه شده و بسته نرم‌افزاری نیز نصب نمی‌شود.

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) مختص سیستم شما خواهد بود. نام فشرده‌ساز از COMPRESS= در /etc/initramfs-tools/initramfs.conf گرفته می‌شود، بنابراین ممکن است در یک ایمیج جدید نام zstd و در یک ایمیج قدیمی‌تر نام gzip دیده شود. دو خطی که این مشکل را شناسایی می‌کنند، No space left on device و خط dpkg: error processing package در زیر آن هستند.

پس از آن، بسته در وضعیت نیمه‌پیکربندی‌شده باقی می‌ماند. هر اجرای بعدی apt تلاش می‌کند آن را دوباره پیکربندی کند، با همان خطا مواجه می‌شود و با E: Sub-process /usr/bin/dpkg returned an error code (1) پایان می‌یابد. این بخشی است که فراتر از فضای دیسک اهمیت دارد: unattended-upgrades طبق زمان‌بندی خود اجرا می‌شود، به همان خطا برمی‌خورد و متوقف می‌شود. سرور سالم به نظر می‌رسد اما بی‌سروصدا اعمال وصله‌های امنیتی را متوقف می‌کند. این همچنین به این معنی است که هر نصب نامرتبط دیگری که انجام دهید با همان خط مواجه می‌شود و تقصیر به گردن بسته‌ای می‌افتد که در آن لحظه در حال افزودن آن هستید؛ به همین دلیل است که خواندن نصب Tailscale که در اوبونتو با خطا مواجه می‌شود به عنوان اولین قدم برای بررسی خطای apt ارزشمند است. اگر apt update پیش از رسیدن به این مرحله با خطا مواجه شود، این یک مشکل جداگانه است که اغلب مربوط به ورودی تکراری پس از مهاجرت منابع به فرمت deb822 می‌باشد.

بررسی اینکه آیا /boot یک پارتیشن مجزا است یا خیر

پیش از حذف هر فایلی، مشخص کنید که دقیقاً چه مقدار فضا آزاد می‌کنید.

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

دستور اول تنها در صورتی خروجی می‌دهد که /boot نقطه اتصال (mount point) اختصاصی خودش باشد. دستور دوم همیشه خروجی می‌دهد و نام فایل‌سیستمی که واقعاً /boot را در خود جای داده است، نمایش می‌دهد. اگر هر دو دستور نام فایل‌سیستم یکسانی را با / نشان دهند، پس /boot صرفاً یک دایرکتوری روی فایل‌سیستم ریشه (root) است و نمی‌تواند به‌تنهایی پر شود؛ در این حالت فایل‌سیستم ریشه شما پر شده است و هسته‌های (kernel) قدیمی تنها یکی از عوامل دخیل هستند. در چنین شرایطی، اجرای sudo apt clean که فایل‌های دانلود شده .deb را در مسیر /var/cache/apt/archives پاکسازی می‌کند، برای شما فضا آزاد خواهد کرد. در سیستمی که دارای یک پارتیشن واقعی /boot است، دستور apt clean هیچ فضایی در آن پارتیشن آزاد نمی‌کند، زیرا کش (cache) روی فایل‌سیستم متفاوتی قرار دارد.

اکنون عددی را که باید بر اساس آن عمل کنید، به دست آورید.

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

ستون Avail را با اندازه آن دو فایل مقایسه کنید. فایل initrd بزرگ‌تر است. به‌روزرسانی بعدی هسته به فضایی برای یک جفت فایل با اندازه مشابه نیاز دارد؛ بنابراین اگر Avail کوچک‌تر از اندازه initrd فعلی باشد، به‌روزرسانی بعدی از همین حالا با شکست مواجه خواهد شد.

یافتن کرنلی که در حال اجراست

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

uname -r رشتهٔ نسخهٔ کرنلی که در حال حاضر در حافظه بارگذاری شده است را چاپ می‌کند. این رشته را در جایی یادداشت کنید. این تنها نسخه‌ای است که نباید آن را تغییر دهید.

فایل دوم تنها زمانی وجود دارد که یک بسته، درخواست راه‌اندازی مجدد (reboot) کرده باشد. وجود یک خط linux-image در آن به این معنی است که کرنل جدیدتری روی دیسک نصب شده اما استفاده نشده است، زیرا سیستم از زمان نصب آن راه‌اندازی مجدد نشده است. اگر امکان دارد، پیش از پاک‌سازی، سیستم را reboot کنید. apt از کرنل در حال اجرا و جدیدترین کرنل محافظت می‌کند، بنابراین پاک‌سازی در حالی که از یک کرنل قدیمی استفاده می‌کنید، باعث می‌شود یک نسخه بیشتر از آنچه نیاز دارید، در سیستم باقی بماند.

فهرست کردن بسته‌های هسته و خواندن وضعیت آن‌ها

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

فیلد اول، کد وضعیت dpkg است. ii به معنای نصب‌شده و پیکربندی‌شده است. iF به معنای نصب‌شده اما نیمه‌پیکربندی‌شده است؛ این دقیقاً همان وضعیتی است که ارتقای ناموفق در بالا باقی می‌گذارد. rc به معنای حذف‌شده است در حالی که فایل‌های پیکربندی آن همچنان روی دیسک باقی مانده‌اند؛ این وضعیت فضایی را در /boot اشغال نمی‌کند و پاک‌سازی (purge) آن ایمن است.

فیلد دوم نوع بسته را مشخص می‌کند. نامی که شامل نسخه باشد، مانند linux-image-6.8.0-64-generic، یک هسته خاص است. نامی بدون نسخه، مانند linux-image-generic، linux-headers-generic یا linux-generic، یک متا-بسته (meta package) است. این بسته‌ها حاوی هسته نیستند. وظیفه اصلی آن‌ها وابستگی به جدیدترین نسخه هسته است تا apt upgrade بتواند هسته‌های جدید را دریافت کند. حذف یک متا-بسته باعث می‌شود دستگاه دیگر به‌روزرسانی‌های هسته را دریافت نکند و پس از آن نیز هیچ هشداری دریافت نخواهید کرد.

خانواده‌ها به این صورت تقسیم می‌شوند: linux-image-* هسته فشرده‌شده را در /boot نگه می‌دارد. linux-modules-* و linux-modules-extra-* درایورها را در /lib/modules نگهداری می‌کنند. linux-headers-* هدرهای ساخت (build headers) را در /usr/src نگه می‌دارد؛ این یعنی پاک‌سازی هدرها فضای پارتیشن ریشه (root) را آزاد می‌کند و نه فضای /boot را. اگر مشکل شما پر شدن پارتیشن /boot است، بسته‌های image همان چیزی هستند که باید به دنبالشان باشید.

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

این دو فهرست باید با یکدیگر و با خروجی dpkg --list مطابقت داشته باشند. وجود دایرکتوری در /lib/modules که بسته نصب‌شده متناظری برای آن وجود ندارد، نشان‌دهنده باقی‌مانده‌ای از حذف دستی فایل‌ها توسط کاربر است.

نحوه تصمیم‌گیری apt برای نگهداری هسته‌ها

apt autoremove هسته‌ای را که محافظت‌شده تلقی می‌کند حذف نخواهد کرد و مجموعه محافظت‌شده شامل هسته‌ای است که در حال حاضر از آن استفاده می‌کنید. سیاست نگهداری هسته‌ها بین نسخه‌های مختلف Ubuntu تغییر کرده است، بنابراین به‌جای اعتماد به عددی که در جایی نوشته شده، آن را از روی سیستم خودتان بخوانید.

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 فهرستی از الگوهای نام بسته‌ها است که apt autoremove از تغییر آن‌ها خودداری می‌کند. APT::VersionedKernelPackages فهرستی از پیشوندهای نام است که apt آن‌ها را در وهله اول به عنوان بسته‌های هسته نسخه‌بندی‌شده در نظر می‌گیرد. در نسخه‌هایی که /etc/apt/apt.conf.d/01autoremove-kernels را تولید می‌کنند، این فایل هر بار که یک بسته هسته نصب می‌شود توسط /etc/kernel/postinst.d/apt-auto-removal بازنویسی می‌شود، بنابراین ویرایش دستی آن بی‌فایده است: نصب هسته بعدی، ویرایش شما را بازنویسی می‌کند. در نسخه‌هایی که این فایل وجود ندارد، apt همان محافظت را به‌صورت داخلی اعمال می‌کند. در هر صورت، apt-config dump قوانین فعال روی سیستم شما را نشان می‌دهد و آن خروجی، پاسخ صحیح برای نسخه سیستم‌عامل شماست.

پاک‌سازی ایمن

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

دستور --dry-run هیچ تغییری در دیسک ایجاد نمی‌کند و دقیقاً مواردی را که در اجرای واقعی حذف خواهند شد، نمایش می‌دهد. لیست را مطالعه کنید. دو مورد باید باعث توقف شما شود. وجود یک متا-پکیج مانند linux-generic یا linux-image-generic در لیست حذف، به این معنی است که چیزی آن را به عنوان خودکار علامت‌گذاری کرده است و حذف آن، به‌روزرسانی‌های هسته (kernel) شما را متوقف می‌کند. وجود رشته مربوط به uname -r در لیست حذف به این معنی است که هسته در حال اجرا محافظت نشده است؛ این وضعیت نباید رخ دهد و پیش از ادامه کار، نیاز به بررسی دارد.

اگر لیست صحیح به نظر می‌رسد، آن را به صورت واقعی اجرا کنید.

sudo apt autoremove --purge
df -h /boot

نیمه دوم دستور یعنی --purge، علاوه بر پکیج، فایل‌های پیکربندی باقی‌مانده را نیز حذف می‌کند. این کار فضای کمی آزاد می‌کند و باعث می‌شود dpkg --list از انباشته شدن خطوط rc پاک بماند که خواندن گزارش‌های بعدی را آسان‌تر می‌کند.

سپس تأیید کنید که منوی بوت بازسازی شده است. حذف یک پکیج هسته، دستور update-grub را برای شما اجرا می‌کند، بنابراین منو باید فقط به فایل‌هایی اشاره کند که هنوز وجود دارند.

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

هر نسخه‌ای که در خروجی اول مشاهده می‌شود، باید در خروجی دوم نیز ظاهر شود. وجود یک ورودی در منو که به فایلی اشاره می‌کند که دیگر وجود ندارد، دلیلی است که یک سرور سالم در خط فرمان GRUB متوقف می‌شود. این یکی از مسیرهای رسیدن به یک VPS که پس از به‌روزرسانی هسته بوت نمی‌شود است و رفع آن از طریق کنسول بازیابی (rescue console)، بسیار دشوارتر از پیشگیری در این مرحله است.

چرا دستور apt autoremove گاهی هیچ بسته‌ای را حذف نمی‌کند

apt autoremove فقط بسته‌هایی را حذف می‌کند که به عنوان automatic علامت‌گذاری شده‌اند؛ یعنی بسته‌هایی که به عنوان وابستگی (dependency) برای یک برنامه دیگر نصب شده‌اند. هسته‌ای که خودتان با استفاده از apt install linux-image-6.8.0-40-generic نصب کرده‌اید، به عنوان manual علامت‌گذاری می‌شود و دستور autoremove هرگز آن را حذف نخواهد کرد، فارغ از اینکه چقدر قدیمی باشد.

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

هر هسته نسخه‌دار در خروجی بالا، برای دستور autoremove نامرئی است. با استفاده از رشته‌های نسخه از لیست خودتان، وضعیت آن را تغییر دهید:

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 باشند، زیرا همان چیزی هستند که شما درخواست نصبشان را داده‌اید.

حذف هدفمند یک هسته خاص

گاهی اوقات می‌خواهید یک نسخه خاص از هسته، به‌جای انتظار برای اعمال سیاست‌های خودکار، همین حالا حذف شود. نام بسته image را مشخص کنید و اجازه دهید apt بقیه کارها را انجام دهد.

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

apt پیش از انجام هر کاری، لیستی از موارد حذفی را نمایش می‌دهد، زیرا linux-modules-extra-* به بسته image وابسته است و باید در همان تراکنش حذف شود. آن لیست چاپ‌شده، بررسی ایمنی واقعی شماست و جایی است که متوجه می‌شوید یک متا-بسته (meta package) همراه با نسخه‌ای که قصد حذف آن را داشتید، در حال حذف شدن است. اگر مورد غیرمنتظره‌ای در لیست وجود دارد، پاسخ n را انتخاب کنید. در نهایت، با استفاده از sudo apt autoremove --purge، بسته‌های ماژول و هدر (header) که اکنون دلیلی برای وجود ندارند را پاکسازی کنید.

چرا هرگز نباید کرنل در حال اجرا را حذف کنید

کرنلی که در حافظه بارگذاری شده است، پس از حذف فایل‌هایش همچنان به کار خود ادامه می‌دهد؛ بنابراین در ابتدا هیچ مشکلی مشاهده نمی‌شود. آنچه از کار می‌افتد، تمام بخش‌هایی است که کرنل هنوز بارگذاری نکرده است. اجرای دستور پاک‌سازی linux-modules-$(uname -r) باعث حذف /lib/modules/$(uname -r)/ می‌شود، در نتیجه بارگذاری ماژول‌های بعدی با خطا مواجه خواهد شد:

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

از آن لحظه به بعد، بارگذاری مجدد فایروال با شکست مواجه می‌شود و همچنین امکان mount کردن نوعی از فایل‌سیستم که این کرنل از زمان بوت تا به حال با آن تعامل نداشته، از بین می‌رود. در همین حین، چون /boot/vmlinuz-$(uname -r) حذف شده است، منوی بوت دیگر کرنلی که در حال اجرای آن هستید را نمایش نمی‌دهد و بوت بعدی شما را به محیطی متفاوت هدایت می‌کند. ماشین همچنان به سرویس‌دهی ترافیک ادامه می‌دهد، در حالی که از قبل غیرقابل‌بوت شده است. همیشه پیش از حذف، لیست را با uname -r تطبیق دهید.

زمانی که پارتیشن /boot برای اجرای apt بیش از حد پر است

این همان وضعیتی است که کاربران را به جستجوی این صفحه وامی‌دارد. apt autoremove برای تکمیل پیکربندی بسته هسته‌ای که نیمه‌کاره مانده، به dpkg نیاز دارد. این مرحله اقدام به بازسازی initramfs می‌کند که خود نیازمند فضای خالی در /boot است، اما فضایی وجود ندارد. این چرخه را یک‌بار به‌صورت دستی بشکنید.

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

یک فایل initrd را انتخاب کنید که نسخه آن با رشته‌ای که uname -r به شما داده است مطابقت ندارد، سپس همان یک فایل را حذف کنید.

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

هر خط دلیل خاص خود را دارد. دستور rm یک استثنای عمدی است که باعث می‌شود dpkg تصور کند فایلی وجود دارد، در حالی که چنین نیست. دستور apt --fix-broken install پیکربندی ناموفق را تکمیل می‌کند، چرا که اکنون فضای کافی برای initramfs فراهم شده است. سپس autoremove --purge بسته‌ای را که فایلش را حذف کردید به همراه سایر نسخه‌های قدیمی پاک می‌کند، که باعث می‌شود وضعیت dpkg با دیسک هماهنگ شود. دستور update-grub منو را بر اساس فایل‌هایی که واقعاً وجود دارند بازسازی می‌کند. بین اجرای rm و update-grub سیستم را ری‌بوت نکنید، زیرا در این بازه زمانی، منو ممکن است همچنان به فایلی اشاره کند که به‌تازگی حذف کرده‌اید. اگر dpkg خطایی مبنی بر قطع شدن عملیات گزارش داد، sudo dpkg --configure -a همان تعمیرات apt --fix-broken install را انجام می‌دهد.

همین کار در سیستم‌های مبتنی بر dnf

اگر VPS شما از Fedora یا یکی از توزیع‌های بازسازی‌شده RHEL مانند Rocky Linux استفاده می‌کند، سازوکار کارکرد معکوس است. Debian و Ubuntu هسته‌ها را با قوانین autoremove در apt محافظت می‌کنند و پاک‌سازی را به عهده شما یا unattended-upgrades می‌گذارند، در حالی که dnf یک شمارنده به نام installonly_limit را اعمال می‌کند و به محض اینکه نصب هسته جدید از این تعداد فراتر رود، قدیمی‌ترین هسته را به‌طور خودکار حذف می‌کند. مقدار فعلی را با grep installonly_limit /etc/dnf/dnf.conf و man 5 dnf.conf مشاهده کنید و موارد انباشته‌شده را با sudo dnf remove --oldinstallonly پاک‌سازی نمایید. هسته در حال اجرا در اینجا نیز محافظت می‌شود. برای مشاهده نگاشت جامع‌تر بین این دو مدیر بسته، به معادل‌های دستورات dnf و apt مراجعه کنید.

جلوگیری از تکرار مشکل

پاک‌سازی‌هایی که به یادآوری شما وابسته باشند، در نهایت شکست می‌خورند؛ بنابراین آن‌ها را در ابزاری که کرنل‌ها را نصب می‌کند، قرار دهید. فایل /etc/apt/apt.conf.d/50unattended-upgrades را باز کنید و به دنبال این کلیدها بگردید که در فایل پیش‌فرض نیز به‌صورت خطوط کامنت‌شده موجود هستند:

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

به‌جای افزودن یک کپی دوم در انتهای فایل، این خطوط را از حالت کامنت خارج کنید. در پیکربندی apt، آخرین مقدار اختصاص‌یافته به یک کلید معتبر است؛ بنابراین وجود نسخه تکراری باعث می‌شود فایل با خودش در تضاد باشد و مشخص نشود کدام مقدار در حال اجراست. بررسی کنید که پارسر در نهایت چه مقداری را در نظر گرفته است و یک اجرای آزمایشی که تغییری ایجاد نمی‌کند را مشاهده کنید:

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

لاگ، سند نهایی است. این فایل هر اجرا را ثبت می‌کند، بنابراین ارتقایی که به دلیل کمبود فضا شکست خورده باشد، بسیار زودتر از زمانی که متوجه شوید سیستم از وصله‌های امنیتی عقب مانده است، در آنجا نمایان می‌شود. باقی این پیکربندی در به‌روزرسانی‌های امنیتی خودکار در Ubuntu پوشش داده شده است.

پیش از آنکه کرنل بعدی ارائه شود، یک عدد وجود دارد که باید بررسی کنید؛ این همان جفت دستوری است که در ابتدای این راهنما ذکر شد:

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

اگر Avail به‌اندازه کافی از آن فایل بزرگ‌تر نباشد، کرنل بعدی دقیقاً با همان مشکلی که در بالا ذکر شد مواجه می‌شود؛ پس همین حالا و پیش از شروع ارتقا، آن را اصلاح کنید. این بررسی در کنار سایر بررسی‌های سلامت دیسک در VPS، ارزش یک دقیقه وقت گذاشتن را دارد. این موضوع درست پیش از ارتقای نسخه سیستم‌عامل اهمیت حیاتی پیدا می‌کند، زیرا انتقال Ubuntu 24.04 به 26.04 یک کرنل جدید را در ابتدای فرآیند نصب می‌کند و do-release-upgrade در صورتی که /boot فضای کافی نداشته باشد، از ادامه کار خودداری خواهد کرد. اگر هنوز پیشنهاد ارتقا برای سرور LTS شما ارائه نشده است، دلیل آن زمان‌بندی است و نه خطا؛ زیرا Ubuntu ارتقای LTS به LTS را تا زمان انتشار نسخه point release 26.04.1 متوقف نگه می‌دارد. این بازه زمانی به شما فرصت می‌دهد تا وضعیت /boot را مرتب کنید.

FAQ

چرا اوبونتو کرنل‌های قدیمی را به‌جای حذف کردن نگه می‌دارد؟

زیرا اگر کرنلی بوت نشود، شما گزینه دیگری برای انتخاب نخواهید داشت. نگهداری نسخه قبلی به این معناست که یک به‌روزرسانی ناموفق از طریق منوی GRUB قابل بازیابی است و نیازی به استفاده از کنسول نجات ارائه‌دهنده سرویس نیست. apt به همین دلیل مجموعه‌ای از بسته‌های کرنل را از حذف خودکار محافظت می‌کند و همیشه نسخه‌ای که در حال اجرای آن هستید را نگه می‌دارد. دستور apt-config dump | grep -i neverautoremove را اجرا کنید تا الگوهای دقیقی که نسخه توزیع شما از آن‌ها محافظت می‌کند را ببینید، چرا که این سیاست بین نسخه‌های مختلف تغییر کرده است.

آیا اجرای apt autoremove --purge روی سرور عملیاتی (Production) ایمن است؟

بله، به شرطی که ابتدا خروجی اجرای آزمایشی (dry run) را بررسی کنید. دستور sudo apt autoremove --purge --dry-run را اجرا کنید که هیچ تغییری اعمال نمی‌کند و لیست نمایش داده شده را چک کنید. اگر لیست شامل یک متا-بسته (meta package) مانند linux-generic یا linux-image-generic بود، متوقف شوید؛ زیرا حذف یکی از آن‌ها باعث توقف به‌روزرسانی‌های آتی کرنل می‌شود. همچنین اگر لیست شامل رشته نسخه‌ای بود که uname -r نمایش می‌دهد، متوقف شوید. اگر هیچ‌کدام از این موارد وجود نداشت، موارد حذف‌شده فقط کرنل‌های قدیمی و وابستگی‌های یتیم (orphaned) هستند.

دستور apt autoremove هیچ چیزی را حذف نکرد و پارتیشن /boot همچنان پر است. حالا چه کار کنم؟

کرنل‌های قدیمی به احتمال زیاد به عنوان نصب دستی (manual) علامت‌گذاری شده‌اند و دستور autoremove فقط بسته‌هایی را پاک می‌کند که به صورت خودکار (automatic) نصب شده باشند. دستور apt-mark showmanual | grep -E '^linux-' را اجرا کنید. هر کرنل نسخه‌بندی‌شده‌ای که در آن لیست ظاهر شود، در مقطعی به صورت دستی نصب شده است. آن را با دستور sudo apt-mark auto linux-image-<version> به حالت خودکار تغییر دهید و دوباره اجرای آزمایشی را انجام دهید، یا مستقیماً آن نسخه خاص را با sudo apt purge linux-image-<version> پاکسازی (purge) کنید.

آیا می‌توانم فایل‌ها را به صورت دستی از /boot حذف کنم؟

فقط به عنوان یک اقدام اضطراری و موردی، زمانی که /boot آنقدر پر است که apt نمی‌تواند بسته کرنل معیوب را پیکربندی کند. یک فایل initrd.img-<version> را که نسخه‌اش خروجی دستور uname -r نیست حذف کنید، سپس بلافاصله دستورات sudo apt --fix-broken install، sudo apt autoremove --purge و sudo update-grub را اجرا کنید. حذف فایل‌ها بدون انجام این مراحل تکمیلی باعث می‌شود dpkg بسته‌هایی را ثبت کند که فایل‌هایشان از بین رفته است و ورودی‌های منوی GRUB به فایل‌های ناموجود اشاره کنند؛ در نتیجه، سیستم در بوت بعدی دچار مشکل می‌شود، نه در لحظه‌ای که اشتباه را مرتکب شدید.