رفع مشکل بوت نشدن VPS پس از آپدیت هسته (Kernel)

اقدامات اولیه در صورت بوت نشدن VPS پس از به‌روزرسانی هسته (kernel)

اگر یک VPS پس از به‌روزرسانی هسته بوت نمی‌شود، معمولاً در عرض چند دقیقه قابل بازیابی است؛ زیرا فرآیند به‌روزرسانی، هسته‌ای که تا دیروز به‌درستی کار می‌کرد را حذف نکرده است. سیستم‌عامل Ubuntu هسته جدید را در کنار هسته قدیمی نصب می‌کند و تنها ورودی پیش‌فرض GRUB را برای بوت تغییر می‌دهد. بنابراین، اولین قدم تعمیر سیستم نیست. کافی است هسته قبلی را از منوی بوت انتخاب کنید، به محیط لاگین دسترسی پیدا کنید و سپس از داخل یک سیستم در حال اجرا، عیب‌یابی را انجام دهید.

رفع این مشکل در سرور با لپ‌تاپ متفاوت است، زیرا هیچ کیبوردی متصل نیست و مانیتوری برای نمایش پیام‌های panic وجود ندارد. سرویس SSH نیز پاسخگو نخواهد بود، چرا که ماشین هرگز به مرحله‌ای نرسیده است که sshd اجرا شود. تمام مراحل زیر باید از طریق کنسول ارائه‌دهنده خدمات شما انجام شود.

پیش از هر تغییری، متن کنسول خود را بخوانید. متنی که روی آن صفحه نمایش داده می‌شود، تعیین‌کننده نوع خرابی است؛ دو سروری که هر دو "بوت نمی‌شوند" ممکن است به راه‌حل‌های کاملاً متفاوتی نیاز داشته باشند.

چگونه در صورت قطع دسترسی SSH به کنسول متصل شوم؟

پنل کنترل ارائه‌دهندهٔ خود را باز کرده و به دنبال کنسول بگردید. نام‌های رایج برای این قابلیت VNC console، web console، noVNC و serial console هستند. اگر هر دو گزینه موجود است، کنسول سریال (serial console) را ترجیح دهید؛ زیرا متن واقعی را در اختیار شما می‌گذارد که می‌توانید آن را اسکرول کرده و کپی کنید، در حالی که نمای VNC تنها تصویری از صفحه نمایش است. همین حالا و در حالی که سرور سالم است، این کنترل را پیدا کرده و از باز شدن آن اطمینان حاصل کنید. جستجو برای آن در زمان بروز قطعی، آرامشی را که به آن نیاز دارید از بین می‌برد. این بررسی باید در ده دقیقه اول راه‌اندازی یک VPS جدید، در کنار تنظیمات فایروال و کلیدهای SSH انجام شود.

بیشتر پنل‌ها یک حالت نجات (rescue mode) یا ایمیج بازیابی نیز ارائه می‌دهند. این حالت یک سیستم‌عامل کوچک را از شبکهٔ ارائه‌دهنده بوت کرده و دیسک شما را به عنوان یک دستگاه جانبی متصل می‌کند، بنابراین هیچ‌چیز از روی دیسک شما اجرا نمی‌شود. حالت نجات، راهکار نهایی برای زمانی است که خود GRUB دچار مشکل شده است؛ همچنین این روشی است که برای کپی کردن داده‌ها از سروری که تصمیم به حذف آن گرفته‌اید، استفاده می‌شود.

برای دسترسی به منوی بوت معمولاً به یک hard reset از طریق پنل نیاز دارید، زیرا نمی‌توانید دستور sudo reboot را روی ماشینی که امکان ورود به آن را ندارید، اجرا کنید. hard reset معادل قطع فیزیکی برق است. فایل‌سیستم‌ها در این حالت به صورت غیرایمن خاموش می‌شوند، بنابراین انتظار داشته باشید که در بوت بعدی، بررسی فایل‌سیستم (filesystem check) انجام شود.

چگونه می‌توانم یک هسته قدیمی‌تر را در منوی GRUB انتخاب کنم؟

از لحظه‌ای که دکمه ریست را فشار می‌دهید، کنسول را زیر نظر بگیرید. در همان ثانیه‌های اول، کلید Esc را به‌طور مکرر فشار دهید، یا اگر دستگاه در حالت legacy BIOS بوت می‌شود، کلید Shift را نگه دارید. این بازه زمانی کوتاه است و نمایشگر کنسول اغلب برای اتصال به یک ثانیه زمان نیاز دارد، بنابراین فشار دادن کلیدها را زود شروع کنید و ادامه دهید.

وقتی منو ظاهر شد، گزینه "Advanced options for Ubuntu" را انتخاب کنید. آن زیرمنو تمام هسته‌های نصب‌شده را فهرست می‌کند که جدیدترین آن‌ها در ابتدا قرار دارد و برای هر کدام یک ورودی recovery mode نیز وجود دارد. دومین ورودی عادی را انتخاب کنید که همان هسته قبل از جدیدترین نسخه است و Enter را بزنید. حالت recovery mode موضوع متفاوتی است: این حالت یک سیستم حداقلی تک‌کاربره را بوت می‌کند و برای کارهای تعمیراتی است، نه برای آنلاین کردن مجدد سرویس‌های شما.

اگر هسته قدیمی‌تر بوت شد، دوباره یک سرور فعال دارید. تأیید کنید که روی چه نسخه‌ای هستید و شماره‌های آن را یادداشت کنید.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

خروجی dpkg فهرست هسته‌های نصب‌شده شماست. اگر این خروجی فقط شامل یک خط باشد، شما هیچ نسخه پشتیبانی ندارید و این اولین چیزی است که باید اصلاح شود.

منوی GRUB هرگز نمایش داده نمی‌شود. چه باید کرد؟

ایمیج‌های ابری (Cloud images) با پیکربندی خاصی عرضه می‌شوند که منو را مخفی می‌کند. ایمیج‌های Ubuntu معمولاً مقدار timeout را در فایلی در مسیر /etc/default/grub.d/ روی 0 تنظیم می‌کنند، بنابراین جدیدترین هسته بلافاصله بارگذاری می‌شود و فرصتی برای فشردن کلید وجود ندارد.

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

هر دو مورد را زمانی که ماشین سالم است اصلاح کنید. فایل /etc/default/grub را ویرایش کنید:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

سپس تغییرات را اعمال کنید و بررسی کنید که ویرایش شما باقی مانده باشد، زیرا فایل‌های موجود در /etc/default/grub.d/ پس از /etc/default/grub خوانده می‌شوند و می‌توانند تنظیمات شما را بازنویسی کنند.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" منو را به کنسول گرافیکی و پورت سریال می‌فرستد، بنابراین در هر نمایشگری که پنل شما ارائه می‌دهد، ظاهر خواهد شد. آرگومان‌های هسته console= نیز همین کار را برای پیام‌های بوت بعدی انجام می‌دهند. ده ثانیه تأخیر در هر بوت، بهای ناچیزی برای داشتن منویی است که واقعاً می‌توانید ساعت 2 بامداد به آن دسترسی داشته باشید.

با کدام کلاس از خرابی مواجه هستم؟

بیست خط آخر پیش از توقف کنسول را بخوانید. چهار الگو، اکثر اتفاقاتی که پس از به‌روزرسانی هسته (kernel) رخ می‌دهد را پوشش می‌دهند.

GRUB نمی‌تواند فایل‌های خود را پیدا کند. شما با یک پرامپت grub rescue> یا خطایی درباره پارتیشن یا فایلی که وجود ندارد مواجه می‌شوید و هیچ پیام هسته‌ای نمایش داده نمی‌شود. هسته هنوز درگیر نشده است. این وضعیت معمولاً پس از تغییر دیسک یا پارتیشن، یا نوشتن bootloader روی دستگاه اشتباه رخ می‌دهد، نه صرفاً به دلیل پکیج هسته.

هسته شروع به کار می‌کند اما نمی‌تواند root را mount کند. پیام‌های هسته اسکرول می‌شوند، سپس شما در یک shell از نوع busybox قرار می‌گیرید که پرامپت آن (initramfs) است، یا فرآیند بوت با یک panic مبنی بر عدم توانایی در mount کردن فایل‌سیستم root پایان می‌یابد. هسته بارگذاری شده است. initramfs، که همان root موقت و کوچک برای یافتن و mount کردن فایل‌سیستم اصلی شماست، دیسک را پیدا نکرده است. در Ubuntu، این shell معمولاً با پیامی درباره صرف‌نظر کردن از انتظار برای دستگاه root همراه است و UUID مورد نظر را اعلام می‌کند. آن UUID را کپی کرده و بعداً با خروجی blkid مقایسه کنید.

یک logical volume هرگز ظاهر نمی‌شود. این مورد همان کلاس قبلی با یک علت خاص است. در پرامپت (initramfs)، دستور ls /dev/mapper را اجرا کنید. اگر تنها ورودی control باشد، یعنی هیچ volume از نوع LVM (مدیریت حجم منطقی) فعال نشده است، بنابراین دستگاه root هنوز وجود ندارد. volume groupها را به‌صورت دستی بالا بیاورید:

lvm vgchange -ay
ls /dev/mapper
exit

دستور exit کنترل را به اسکریپت initramfs بازمی‌گرداند تا دوباره برای mount تلاش کند. اگر سیستم پس از آن بوت شد، یعنی initramfs جدید فاقد اجزای LVM بوده است و راه حل، بازسازی آن image است، نه دستکاری هسته.

هیچ چیزی از Linux نمایش داده نمی‌شود. کنسول متن firmware، یک shell از نوع UEFI (رابط میان‌افزار توسعه‌پذیر یکپارچه)، یک صفحه خالی بدون خروجی هسته یا یک حلقه ریست (reset loop) را نشان می‌دهد. خرابی پیش از اجرای Linux رخ می‌دهد. پس از آنکه سیستم بالا آمد، بررسی کنید سرور شما واقعاً از چه حالتی استفاده می‌کند، زیرا بسیاری از نمونه‌های VPS در حالت legacy BIOS بوت می‌شوند و هرگز به مسیر EFI دسترسی ندارند:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

یک /boot/efi که در حین ارتقا mount نشده باشد، علت رایجی در ماشین‌های UEFI است، زیرا پکیج‌هایی که پارتیشن سیستم EFI را مدیریت می‌کنند، در آن صورت در یک دایرکتوری خالی معمولی نوشته‌اند. firmware همچنان به اجرای ورودی بوت قدیمی ادامه می‌دهد تا زمانی که آن ورودی دیگر با آنچه روی دیسک است مطابقت نداشته باشد.

یک الگوی دیگر اصلاً خرابی بوت نیست. اگر به یک root shell رسیدید که می‌گوید سیستم در حالت emergency است، یعنی هسته بوت شده و فضای کاربری (userspace) متوقف شده است. این معمولاً به معنای وجود یک خط اشتباه در /etc/fstab یا فایل‌سیستمی است که در بررسی خود شکست خورده است. در آن shell دستور journalctl -xb را اجرا کنید و نام واحدی (unit) که با خطا مواجه شده را بخوانید.

آیا بسته kernel خراب است یا initramfs؟

این دو مورد از طریق کنسول یکسان به نظر می‌رسند اما نیاز به تعمیرات متفاوتی دارند. با kernel قدیمی بوت کنید و سپس فایل‌ها را مقایسه کنید.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

شما برای هر نسخه نصب‌شده به یک vmlinuz- و یک initrd.img- منطبق با آن، که هر کدام اندازه معقولی داشته باشند، نیاز دارید. نبود فایل initrd یا کوچک بودن بیش از حد آن نسبت به سایر فایل‌های مشابه، به معنای شکست در تولید initramfs است. دلیل معمول این اتفاق پر بودن /boot است و شواهد آن در لاگ‌های بسته موجود است:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log همچنین دقیقاً فهرست می‌کند که آخرین اجراها چه بسته‌هایی را و در چه زمانی نصب کرده‌اند، که این موضوع هرگونه بحث درباره تغییرات ایجاد شده را خاتمه می‌دهد.

اگر /boot پر است، ابتدا فضا آزاد کنید، سپس image را برای نسخه مورد نیاز بازسازی کرده و منو را به‌روزرسانی کنید. رشته نسخه را از خروجی ls خود بردارید، زیرا جای‌گذاری زیر یک نسخه واقعی نیست:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

آن ls آخر برای بررسی است. وجود فایلی با اندازه عادی به این معنی است که image اکنون در دسترس است. اگر به جای آن، خودِ kernel image آسیب دیده باشد یا dpkg -l وضعیت بسته را چیزی غیر از ii نشان دهد، بسته را دوباره نصب کنید:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

تعمیر از حالت rescue در صورت عدم بوت شدن کرنل

اگر تمام ورودی‌های منو با شکست مواجه شدند، image حالت rescue ارائه‌دهنده را بوت کنید و دیسک را از خارج سیستم تعمیر کنید. دیسک شما به عنوان یک دستگاه unmount شده ظاهر می‌شود، بنابراین هیچ‌چیز روی آن در حال اجرا نیست و تداخلی ایجاد نخواهد شد.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

تست یک هسته جدید بدون به خطر انداختن بوت بعدی

GRUB می‌تواند یک ورودی را فقط برای یک بار اجرا کند و سپس به پیش‌فرض انتخابی شما بازگردد. پیش‌فرض را روی هسته‌ای که به آن اطمینان دارید تنظیم کنید، سپس هسته جدید را فقط برای یک بوت راه‌اندازی کنید. اگر هسته جدید با شکست مواجه شد، یک ریست سخت‌افزاری از طریق پنل مدیریت، شما را به هسته سالم بازمی‌گرداند و نیازی به زمان‌بندی دقیق کنسول برای انتخاب هسته نخواهید داشت.

مقدار GRUB_DEFAULT=saved را در /etc/default/grub تنظیم کنید، sudo update-grub را اجرا کنید و سپس عناوین ورودی‌ها را لیست کنید تا بتوانید یکی از آن‌ها را دقیقاً نام‌گذاری کنید:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list باید عنوان انتخابی شما را به عنوان saved_entry چاپ کند. این خروجی گواهی بر کارکرد صحیح این مکانیزم است، زیرا ذخیره‌سازی نیازمند یک /boot/grub/grubenv با قابلیت نوشتن است و در برخی ساختارها، این عملیات بدون نمایش خطا انجام نمی‌شود. ورودی 0 بالاترین گزینه در منو است که همان جدیدترین هسته می‌باشد. استفاده از عناوین در اینجا امن‌تر از اعداد است، زیرا با هر بار نصب یا حذف هسته، شماره‌ها تغییر می‌کنند.

چرا دستور autoremove در سرورهای headless پرخطر است

APT فهرستی از بسته‌های هسته (kernel) را نگه می‌دارد که نباید به‌طور خودکار حذف شوند. فهرست خود را مشاهده کنید:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

این فایل هر زمان که بسته‌های هسته تغییر کنند بازسازی می‌شود و از هسته در حال اجرا و جدیدترین نسخه‌ها محافظت می‌کند. مشکل اصلی زمان‌بندی است. اگر دستور sudo apt autoremove --purge را بلافاصله پس از راه‌اندازی مجدد (reboot) با یک هسته جدید اجرا کنید، فهرست محافظت‌شده به‌روز شده است و هسته قدیمی که به آن نیاز داشتید دیگر محافظت نمی‌شود. در سیستمی که به کیبورد دسترسی دارید، این فقط یک دردسر است. در یک سرور headless، این تفاوت بین انتخاب یک گزینه از منوی بوت و نیاز به mount کردن دیسک از طریق یک image نجات (rescue) است.

همیشه حداقل دو هسته را نگه دارید و اگر فضای کافی در /boot دارید، سه هسته را حفظ کنید. هسته‌های قدیمی را پس از بررسی uname -r با نام حذف کنید تا هرگز هسته‌ای که در حال حاضر از آن استفاده می‌کنید پاک نشود:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

پس از آن، دستور آخر را دوباره اجرا کنید. اگر تعداد از سه به دو کاهش یابد، یعنی پاک‌سازی انجام شده است. اگر تعداد به یک برسد، یعنی در انتظار یک قطعی (outage) در راه‌اندازی مجدد بعدی هستید.

پیش از ارتقا، یک snapshot تهیه کنید

یک snapshot که پیش از apt upgrade گرفته شده باشد، تنها مسیر بازیابی است که به بوت شدن هیچ چیزی وابسته نیست. بازگردانی آن، دیسک را به وضعیتی برمی‌گرداند که در آن هسته قدیمی پیش‌فرض بود و شما می‌توانید با کنسولی که از قبل باز است، دوباره برای ارتقا تلاش کنید. snapshotهای یک ماشین در حال اجرا، crash consistent هستند؛ یعنی دیسک را دقیقاً همان‌طور ثبت می‌کنند که گویی برق قطع شده باشد. بنابراین، اگر ارائه‌دهنده سرویس شما از snapshot آفلاین پشتیبانی می‌کند، ابتدا سرور را خاموش کنید. snapshot یک نسخه پشتیبان (backup) نیست، زیرا معمولاً روی همان زیرساختی قرار دارد که حجم (volume) کپی‌شده از آن قرار دارد. درک تفاوت بین snapshotهای VPS و نسخه‌های پشتیبان واقعی تعیین می‌کند که در صورت بروز خرابی‌های بزرگ‌تر از یک هسته، کدام‌یک شما را نجات خواهد داد.

این موضوع در ارتقای نسخه (release upgrade) اهمیت حیاتی دارد؛ جایی که هسته، ابزارهای initramfs، بوت‌لودر و پیکربندی GRUB همگی در یک مرحله تغییر می‌کنند. snapshot را دقیقاً پیش از شروع ارتقای Ubuntu 24.04 به 26.04 تهیه کنید، نه شب قبل از آن؛ تا نقطه بازیابی دقیقاً با ماشینی که قصد تغییر آن را دارید مطابقت داشته باشد.

نحوه برخورد unattended-upgrades با بسته‌های هسته (kernel)

سرویس unattended-upgrades در اوبونتو، به‌روزرسانی‌های امنیتی را بدون پرسش نصب می‌کند و بسته‌های هسته نیز مانند سایر موارد از طریق مخزن امنیتی (security pocket) دریافت می‌شوند. این موضوع دو پیامد به همراه دارد.

نخست، هسته جدید نصب می‌شود اما در حال اجرا نیست. هسته تنها پس از بوت شدن سیستم اعمال می‌شود. فایل /var/run/reboot-required ظاهر می‌شود و /var/run/reboot-required.pkgs مشخص می‌کند که چه چیزی درخواست ریبوت کرده است، اما تا زمانی که Unattended-Upgrade::Automatic-Reboot را در /etc/apt/apt.conf.d/50unattended-upgrades فعال نکرده باشید، هیچ‌چیز به‌طور خودکار ری‌استارت نمی‌شود.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

دوم، این فاصله زمانی باعث پنهان ماندن علت بروز مشکل می‌شود. ممکن است سروری در ماه مارس هسته‌ای را نصب کند و در ماه ژوئن به دلیلی کاملاً بی‌ارتباط ریبوت شود و سپس بالا نیاید. تغییری که باعث خرابی بوت شده مربوط به سه ماه پیش است، بنابراین هیچ‌کدام از کارهایی که در آن روز انجام داده‌اید، دلیل خرابی را توضیح نمی‌دهد. /var/log/apt/history.log جایی است که می‌توانید اجرای نصب هسته‌ای را که اکنون باعث شکست بوت شده است، پیدا کنید.

ریبوت را به‌صورت عمدی و در روزی که خودتان انتخاب کرده‌اید، در حالی که پنجره کنسول باز است، انجام دهید. همین یک عادت ساده، یک قطعی مرموز را به یک انتخاب منوی دو دقیقه‌ای تبدیل می‌کند. اگر اتوماسیون را بدون غافلگیری می‌خواهید، نصب خودکار را روشن و ریبوت خودکار را خاموش نگه دارید و برای تنظیمات دقیق به نحوه پیکربندی unattended-upgrades در اوبونتو مراجعه کنید. نگه داشتن (hold) بسته‌های هسته با استفاده از sudo apt-mark hold linux-image-generic، نصب آن‌ها را به‌طور کامل متوقف می‌کند و در عین حال اصلاحات امنیتی هسته را نیز مسدود می‌سازد؛ بنابراین این کار را به عنوان یک معامله (trade-off) که آگاهانه انتخاب کرده‌اید در نظر بگیرید، نه به عنوان یک اقدام ایمنی.

FAQ

چگونه می‌توانم یک هسته قدیمی‌تر را روی VPS بدون دسترسی به کیبورد بوت کنم؟

کنسول ارائه‌دهنده (VNC یا سریال) را باز کنید و از طریق پنل کنترل، یک hard reset انجام دهید، زیرا امکان لاگین برای ریبوت تمیز وجود ندارد. همزمان با شروع مجدد دستگاه، کلید Esc را مکرراً فشار دهید یا در سیستم‌های دارای BIOS قدیمی، کلید Shift را نگه دارید تا منوی GRUB ظاهر شود. گزینه "Advanced options for Ubuntu" را انتخاب کرده و ورودی زیرِ جدیدترین هسته را برگزینید. پس از مشاهده اعلان لاگین، دستور uname -r را اجرا کنید تا تأیید شود روی کدام هسته هستید و از dpkg -l 'linux-image-*' برای مشاهده سایر هسته‌های نصب‌شده استفاده کنید. عیب‌یابی را تنها پس از بالا آمدن سیستم انجام دهید.

چرا VPS من اصلاً منوی GRUB را نشان نمی‌دهد؟

ایمیج‌های ابری معمولاً زمان انتظار GRUB را در فایلی در مسیر /etc/default/grub.d/ روی 0 تنظیم می‌کنند، بنابراین جدیدترین هسته بدون فرصتی برای تعامل کاربر بوت می‌شود. مقادیر GRUB_TIMEOUT=10 و GRUB_TIMEOUT_STYLE=menu را در /etc/default/grub تنظیم کنید، GRUB_TERMINAL="console serial" را اضافه کنید تا منو به کنسول سریال نیز ارسال شود، سپس sudo update-grub را اجرا کنید. با grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ بررسی نهایی را انجام دهید، زیرا فایل‌های موجود در آن دایرکتوری پس از فایل اصلی خوانده می‌شوند و می‌توانند تنظیمات شما را بازنویسی کنند.

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

قدیمی‌ترین‌ها را حذف کنید و حداقل دو هسته را نگه دارید. پر شدن /boot خود یک حالت شکست است، زیرا تولید initramfs با خطا مواجه می‌شود و شما با هسته‌ای می‌مانید که ایمیج کاری ندارد. پس از بررسی uname -r، بسته‌ها را با نام دقیق حذف (purge) کنید تا هسته در حال اجرا هرگز کاندید حذف نشود. از اجرای دستور کلی sudo apt autoremove --purge در ماشین‌های بدون مانیتور (headless) خودداری کنید، زیرا لیست هسته‌های محافظت‌شده در هر تغییر هسته بازسازی می‌شود و اجرای بی‌موقع این دستور می‌تواند شما را با یک هسته و بدون هیچ ورودی جایگزین در منو رها کند.

آیا unattended-upgrades می‌تواند باعث خرابی بوت شود؟

این ابزار می‌تواند هسته‌ای را نصب کند که بعداً در بوت شکست می‌خورد، اما تا زمانی که Unattended-Upgrade::Automatic-Reboot در /etc/apt/apt.conf.d/50unattended-upgrades روی true تنظیم نشده باشد، دستگاه را ریستارت نمی‌کند. الگوی معمول، یک شکست تأخیری است: هسته در طول یک اجرای خودکار نصب می‌شود، /var/run/reboot-required ظاهر می‌گردد و مشکل تنها در ریبوت بعدی شما که ممکن است هفته‌ها بعد باشد، نمایان می‌شود. ریبوت را به‌صورت آگاهانه و در حالی که کنسول باز است انجام دهید و /var/log/apt/history.log را بخوانید تا متوجه شوید کدام اجرا، هسته‌ای که اکنون با آن بوت می‌شوید را نصب کرده است.