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

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

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

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

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

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

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

بیشتر پنل‌ها حالت rescue mode یا recovery image نیز ارائه می‌دهند. این حالت یک سیستم‌عامل کوچک را از شبکهٔ ارائه‌دهنده بوت کرده و دیسک شما را به عنوان یک دستگاه جانبی متصل می‌کند، بنابراین هیچ‌کدام از برنامه‌های روی دیسک شما اجرا نمی‌شوند. حالت rescue راهکار نهایی برای زمانی است که خود 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 کردن فایل‌سیستم root اصلی شماست، دیسک را پیدا نکرده است. در 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

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

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

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

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

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 خود بردارید، زیرا جای‌گیر (placeholder) زیر یک نسخه واقعی نیست:

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

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

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

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

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

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'

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

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

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

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

نحوه برخورد 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 در اوبونتو مراجعه کنید. متوقف کردن بسته‌های هسته با استفاده از sudo apt-mark hold linux-image-generic، آن‌ها را به‌طور کامل متوقف می‌کند و در عین حال اصلاحات امنیتی هسته را نیز از کار می‌اندازد؛ بنابراین با این کار به‌عنوان یک معامله آگاهانه برخورد کنید، نه یک اقدام ایمنی.

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