پاکسازی هسته‌های قدیمی در 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) است و نمی‌تواند به‌تنهایی پر شود: در این حالت فایل‌سیستم ریشه شما پر شده است و کرنل‌های قدیمی تنها یکی از عوامل دخیل هستند. در چنین شرایطی، اجرای 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 نشده است. اگر می‌توانید، پیش از پاکسازی، سیستم را 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 در لیست حذف، به این معنی است که چیزی آن را به عنوان خودکار (automatic) علامت‌گذاری کرده است و حذف آن، به‌روزرسانی‌های هسته (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 باقی بگذارید. این بسته‌ها باید به صورت دستی علامت‌گذاری شده باشند، زیرا همان مواردی هستند که خودتان درخواست نصب آن‌ها را داده‌اید.

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

گاهی اوقات می‌خواهید یک نسخه خاص از هسته را بلافاصله حذف کنید، نه اینکه منتظر بمانید تا سیاست‌های سیستم آن را پاکسازی کنند. نام بسته 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) که اکنون دلیلی برای وجود ندارند را پاکسازی کنید.

چرا هرگز نباید هسته (kernel) در حال اجرا را حذف کنید

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

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

از آن لحظه به بعد، بازنشانی فایروال (firewall reload) با خطا مواجه می‌شود و همچنین mount کردن هر نوع سیستم‌فایلی که این هسته از زمان بوت تا آن لحظه با آن تعامل نداشته است، غیرممکن خواهد بود. در همین حین، /boot/vmlinuz-$(uname -r) نیز حذف شده است، بنابراین منوی بوت دیگر هسته‌ای را که در حال اجرای آن هستید نمایش نمی‌دهد و راه‌اندازی مجدد (reboot) بعدی، سیستم را به وضعیت نامشخصی می‌برد. ماشین همچنان به ترافیک شبکه پاسخ می‌دهد، اما در واقع غیرقابل‌بوت (unbootable) شده است. همیشه پیش از حذف، لیست بسته‌ها را با 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 سیستم را reboot نکنید، زیرا در این فاصله ممکن است منو همچنان به فایلی اشاره کند که به‌تازگی حذف کرده‌اید. اگر 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 یک کرنل جدید را در مراحل اولیه فرآیند نصب می‌کند و اگر /boot فضای کافی نداشته باشد، do-release-upgrade از ادامه کار خودداری خواهد کرد.

FAQ

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

زیرا اگر کرنل جدید بوت نشود، شما گزینه‌ای برای انتخاب نخواهید داشت. نگهداری نسخه قبلی به این معناست که یک به‌روزرسانی ناموفق از طریق منوی GRUB قابل بازیابی است و نیازی به استفاده از کنسول نجات (rescue console) ارائه‌دهنده سرویس نیست. 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 به فایل‌های ناموجود اشاره کند؛ در نتیجه، سیستم به جای لحظه وقوع اشتباه، در بوت بعدی با شکست مواجه خواهد شد.