কার্নেল আপডেটের পর VPS boot না হলে কী করবেন

কার্নেল আপডেটের পরে VPS boot না হলে প্রথমে কী করবেন

কার্নেল আপডেটের পরে VPS boot না হলেও সাধারণত কয়েক মিনিটের মধ্যে এটি পুনরুদ্ধার করা যায়, কারণ আপডেটের সময় আগের দিন কাজ করা কার্নেলটি মুছে যায় না। Ubuntu পুরোনো কার্নেলের পাশে নতুন কার্নেল ইনস্টল করে এবং শুধু GRUB ডিফল্টভাবে কোন entry চালু করবে, তা পরিবর্তন করে। তাই প্রথম পদক্ষেপ repair করা নয়। boot menu-তে আগের কার্নেল নির্বাচন করুন, আবার login prompt পান, তারপর চালু থাকা সিস্টেম থেকে সমস্যার কারণ নির্ণয় করুন।

সার্ভারে এটি ঠিক করার পদ্ধতি laptop-এর মতো নয়, কারণ সার্ভারের সঙ্গে কোনো keyboard সংযুক্ত থাকে না এবং panic দেখার জন্য কোনো monitor-ও থাকে না। মেশিন sshd চালু হওয়ার পর্যায়ে পৌঁছায়নি, তাই SSH-ও সাড়া দেবে না। নিচের সব কাজ আপনার provider-এর console-এর মাধ্যমে করতে হবে।

কোনো পরিবর্তন করার আগে আপনার নিজের console-এর লেখা পড়ুন। ওই screen-এর বার্তা থেকেই বোঝা যায় আপনি কোন ধরনের ব্যর্থতার মুখোমুখি হয়েছেন। একইভাবে “boot হবে না” এমন দুটি server-এর জন্য সম্পূর্ণ বিপরীত সমাধান প্রয়োজন হতে পারে।

SSH কাজ না করলে আমি কীভাবে console-এ পৌঁছাব?

আপনার provider-এর control panel খুলে console খুঁজুন। প্রচলিত নাম হলো VNC console, web console, noVNC এবং serial console। দুটিই থাকলে serial console ব্যবহার করুন। এতে প্রকৃত text দেখা যায়, যা scroll ও copy করা যায়। VNC view শুধু screen-এর ছবি দেখায়। মেশিন সুস্থ থাকা অবস্থাতেই এই control খুঁজে রাখুন এবং এটি খুলছে কি না যাচাই করুন। outage চলাকালে এটি খুঁজতে গেলে প্রয়োজনীয় স্থিরতা নষ্ট হয়। এই যাচাইটি নতুন VPS-এ প্রথম দশ মিনিটের কাজের অংশ হওয়া উচিত। Firewall rules এবং SSH keys-এর পাশেই এটি রাখুন।

বেশিরভাগ panel-এ rescue mode বা recovery image-ও থাকে। এটি provider-এর network থেকে একটি ছোট system boot করে এবং আপনার disk-কে অতিরিক্ত device হিসেবে সংযুক্ত করে। ফলে disk-এর কোনো system চালু হয় না। GRUB নিজেই নষ্ট হলে rescue mode ব্যবহার করতে হয়। যে server আর পুনরুদ্ধার করবেন না বলে সিদ্ধান্ত নিয়েছেন, সেখান থেকে data copy করার উপায়ও এটি।

Boot menu-তে পৌঁছাতে সাধারণত panel থেকে hard reset করতে হবে। কারণ যে মেশিনে login করা যায় না, সেখানে sudo reboot চালানো সম্ভব নয়। Hard reset-এর ফল power কেটে দেওয়ার মতোই। Filesystem-এ unclean shutdown ঘটে। তাই পরবর্তী boot-এ filesystem check হওয়ার জন্য প্রস্তুত থাকুন।

GRUB মেনুতে কীভাবে পুরোনো kernel বেছে নেব?

reset চাপার মুহূর্ত থেকে console নজরে রাখুন। প্রথম কয়েক সেকেন্ডে বারবার Esc চাপুন। Legacy BIOS mode-এ boot করা মেশিনে Shift চেপে ধরে রাখুন। এই সময়সীমা খুব ছোট। Console viewer সংযোগ করতে প্রায়ই এক সেকেন্ড সময় নেয়। তাই আগে থেকেই চাপা শুরু করুন এবং বারবার চাপতে থাকুন।

মেনু দেখা গেলে "Advanced options for Ubuntu" বেছে নিন। ওই submenu-তে ইনস্টল করা প্রতিটি kernel থাকে। সবচেয়ে নতুন kernel সবার উপরে থাকে। প্রতিটির জন্য একটি recovery mode entry-ও থাকে। দ্বিতীয় normal entry বেছে নিন। এটি সবচেয়ে নতুন kernel-এর নিচের kernel। এরপর Enter চাপুন। Recovery mode আলাদা বিষয়। এটি একটি ন্যূনতম single user system-এ boot করে। এটি repair কাজের জন্য, service আবার online করার জন্য নয়।

পুরোনো kernel boot হলে সার্ভার আবার চালু অবস্থায় পাবেন। কোন kernel-এ চলছে তা নিশ্চিত করুন এবং সংখ্যাগুলো লিখে রাখুন।

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

dpkg-এর output হলো ইনস্টল করা kernel-গুলোর তালিকা। এতে যদি মাত্র একটি line থাকে, তাহলে আপনার কোনো fallback নেই। এটিই প্রথমে ঠিক করতে হবে।

GRUB মেনু কখনো দেখা যায় না। এখন কী করবেন?

Cloud image-এ সাধারণত এমন configuration থাকে, যা মেনু লুকিয়ে রাখে। Ubuntu image-গুলোতে প্রায়ই /etc/default/grub.d/-এর অধীনে থাকা একটি file-এ timeout 0 সেট করা থাকে। তাই সর্বশেষ kernel সঙ্গে সঙ্গে চালু হয় এবং চাপার মতো কোনো key থাকে না।

এর বিপরীত ঘটনাও ঘটতে পারে। মেনু screen-এ দেখা যায় এবং অপেক্ষা করতে থাকে, ফলে system hang করেছে বলে মনে হয়। GRUB একটি failed boot নথিভুক্ত করে। পরবর্তী start-এর সময় এটি কোনো ব্যক্তি key না চাপা পর্যন্ত মেনু খোলা রাখতে পারে। Keyboard না থাকা server-এ এই অপেক্ষা কখনো শেষ হয় না। আপনার console-এ মেনু দেখা গেলেও কিছু না এগোলে এটাই ঘটেছে। একটি entry নির্বাচন করে boot চালিয়ে যান।

Machine সুস্থ থাকা অবস্থায় উভয় সমস্যা ঠিক করুন। /etc/default/grub edit করুন:

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"

এরপর এটি apply করুন এবং আপনার edit টিকে আছে কি না পরীক্ষা করুন। কারণ /etc/default/grub.d/-এর file-গুলো /etc/default/grub-এর পরে read হয় এবং আপনার সেটিং override করতে পারে।

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

GRUB_TERMINAL="console serial" মেনু graphical console এবং serial port—উভয় জায়গায় পাঠায়। তাই panel যে viewer দেয়, সেখানে এটি দেখা যাবে। পরবর্তী boot message-গুলোর ক্ষেত্রেও console= kernel argument একই কাজ করে। প্রতি boot-এ 10 সেকেন্ড delay এমন একটি মেনু পাওয়ার জন্য সামান্য মূল্য, যেটিতে রাত 2টার সময়ও আপনি বাস্তবে পৌঁছাতে পারবেন।

আমি কোন ধরনের ব্যর্থতা দেখছি?

কনসোলে লেখা থেমে যাওয়ার আগে শেষ বিশটি লাইন পড়ুন। Kernel update-এর পরে সাধারণত চারটি pattern দেখা যায়।

GRUB নিজের file খুঁজে পায় না। আপনি একটি grub rescue> prompt দেখতে পারেন, অথবা এমন কোনো partition বা file না থাকার error পেতে পারেন, এবং kernel-এর কোনো message দেখা যায় না। এখনো kernel কাজ শুরু করেনি। সাধারণত disk বা partition পরিবর্তন, অথবা ভুল device-এ bootloader লেখার কারণে এটি ঘটে; শুধু kernel package-এর কারণে নয়।

Kernel শুরু হয়, কিন্তু root mount করতে পারে না। Kernel message দেখা যেতে থাকে, তারপর (initramfs) prompt-সহ একটি busybox shell আসে, অথবা root filesystem mount করা যাচ্ছে না—এমন panic-এ boot শেষ হয়। Kernel load হয়েছে। initramfs, অর্থাৎ আপনার প্রকৃত root filesystem খুঁজে mount করার জন্য ব্যবহৃত ছোট অস্থায়ী root environment, disk খুঁজে পায়নি। Ubuntu-তে সাধারণত এই shell আসার আগে root device-এর জন্য অপেক্ষা ছেড়ে দেওয়ার message দেখা যায় এবং সেখানে প্রত্যাশিত UUID উল্লেখ থাকে। সেই UUID কপি করে পরে blkid output-এর সঙ্গে মিলিয়ে দেখুন।

Logical volume কখনো উপস্থিত হয় না। এটি আগের ব্যর্থতারই একটি নির্দিষ্ট কারণযুক্ত ধরন। (initramfs) prompt-এ ls /dev/mapper চালান। যদি একমাত্র entry control হয়, তাহলে কোনো LVM (logical volume manager) volume সক্রিয় হয়নি। তাই root device এখনো উপস্থিত নয়। হাতে করে volume group চালু করুন:

lvm vgchange -ay
ls /dev/mapper
exit

exit initramfs script-এ control ফিরিয়ে দেয় এবং সেটি আবার mount করার চেষ্টা করে। এরপর system boot হলে বুঝবেন নতুন initramfs-এ LVM উপাদানগুলো নেই। এ ক্ষেত্রে kernel পরিবর্তন না করে initramfs image rebuild করতে হবে।

Linux থেকে কোনো output-ই আসে না। Console-এ firmware text, একটি UEFI (unified extensible firmware interface) shell, kernel output ছাড়া blank screen, অথবা reset loop দেখা যায়। Linux চালু হওয়ার আগেই failure ঘটছে। Server চালু হওয়ার পরে সেটি কোন boot mode ব্যবহার করছে যাচাই করুন। কারণ অনেক VPS instance legacy BIOS mode-এ boot করে এবং EFI path কখনো ব্যবহার করে না:

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

Upgrade-এর সময় /boot/efi mount না করা UEFI machine-এ একটি সাধারণ কারণ। এর ফলে EFI system partition রক্ষণাবেক্ষণকারী package-গুলো প্রকৃত partition-এর বদলে একটি সাধারণ empty directory-তে লিখে ফেলে। Disk-এর বর্তমান অবস্থার সঙ্গে boot entry-র তথ্য না মেলা পর্যন্ত firmware পুরোনো boot entry-টি চালু করতে থাকে।

আরেকটি pattern আসলে boot failure নয়। যদি এমন একটি root shell পান যেখানে system emergency mode-এ আছে বলা হয়, তাহলে kernel boot করেছে এবং userspace থেমে গেছে। সাধারণত /etc/fstab-এর ভুল line অথবা check-এ ব্যর্থ হওয়া filesystem এর কারণ। সেই shell-এ journalctl -xb চালিয়ে কোন unit ব্যর্থ হয়েছে তার নাম পড়ুন।

কার্নেল প্যাকেজ নষ্ট, নাকি initramfs?

কনসোলে এই দুটি সমস্যা একই রকম দেখায়, কিন্তু মেরামতের পদ্ধতি আলাদা। পুরোনো কার্নেল boot করুন, তারপর ফাইলগুলো তুলনা করুন।

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

প্রতিটি ইনস্টল করা version-এর জন্য একটি vmlinuz- এবং তার সঙ্গে মিলে এমন একটি initrd.img- থাকা উচিত। দুটির আকারও স্বাভাবিক হওয়া উচিত। কোনো initrd না থাকা, অথবা পাশের ফাইলগুলোর তুলনায় অস্বাভাবিকভাবে ছোট হওয়া, initramfs তৈরির ব্যর্থতা নির্দেশ করে। সাধারণ কারণ হলো /boot পূর্ণ হয়ে যাওয়া। এর প্রমাণ package log-এ থাকে:

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

শেষবার চলার সময় কোন package ইনস্টল হয়েছে এবং কখন হয়েছে, history.log সেটিও নির্দিষ্টভাবে দেখায়। এতে কী পরিবর্তন হয়েছে, তা নিয়ে অনিশ্চয়তা থাকে না।

/boot পূর্ণ থাকলে আগে খালি জায়গা তৈরি করুন। এরপর প্রয়োজনীয় version-এর জন্য image পুনর্নির্মাণ করুন এবং boot menu refresh করুন। নিজের ls output থেকে version string নিন। নিচের placeholder কোনো বাস্তব release নয়:

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

শেষের ls-ই যাচাইয়ের ধাপ। স্বাভাবিক আকারের file থাকলে বোঝা যাবে যে image এখন তৈরি হয়েছে। কিন্তু kernel image নিজেই ক্ষতিগ্রস্ত হলে, অথবা dpkg -l package-টিকে ii ছাড়া অন্য কোনো অবস্থায় দেখালে, package-টি পুনরায় ইনস্টল করুন:

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

rescue mode থেকে মেরামত: কোনো kernel boot না হলে

মেনুর প্রতিটি entry ব্যর্থ হলে provider-এর rescue image boot করুন এবং বাইরে থেকে disk মেরামত করুন। আপনার disk unmounted device হিসেবে দেখা যাবে। তাই এর ওপর কিছু চলছে না এবং কোনো process আপনার কাজ বাধাগ্রস্ত করতে পারবে না।

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

নতুন kernel পরীক্ষা করুন, পরবর্তী boot ঝুঁকিতে না ফেলে

GRUB একটি entry একবারের জন্য চালু করতে পারে, তারপর আপনার নির্ধারিত default entry-তে ফিরে যায়। Default হিসেবে এমন একটি kernel নির্ধারণ করুন যেটিকে আপনি বিশ্বাস করেন। এরপর নতুন kernel-টি শুধু একটি boot-এর জন্য চালু করুন। এটি ব্যর্থ হলে panel থেকে hard reset করলে console-এ সঠিক সময়ে কোনো কমান্ড দেওয়ার প্রয়োজন ছাড়াই আপনি কার্যকর kernel-এ ফিরে যাবেন।

GRUB_DEFAULT=saved-এ /etc/default/grub নির্ধারণ করুন, sudo update-grub চালান, তারপর entry-গুলোর title তালিকাভুক্ত করুন, যাতে একটি title হুবহু ব্যবহার করতে পারেন:

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-এর output-এ আপনার নির্ধারিত title saved_entry হিসেবে দেখা উচিত। এই output প্রমাণ করে যে প্রক্রিয়াটি কাজ করছে। কারণ সংরক্ষণ করতে একটি writable /boot/grub/grubenv প্রয়োজন, কিন্তু কিছু layout-এ এটি নীরবে writable থাকে না। Entry 0 menu-এর শীর্ষে থাকে, অর্থাৎ এটিই newest kernel। এখানে সংখ্যার চেয়ে title ব্যবহার করা নিরাপদ, কারণ kernel install বা remove হলেই সংখ্যাগুলো পরিবর্তিত হয়।

headless সার্ভারে autoremove কেন ঝুঁকিপূর্ণ

APT এমন kernel package-এর একটি তালিকা রাখে, যেগুলো নিজে থেকে সরানো যাবে না। আপনার তালিকাটি দেখুন:

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

Kernel package পরিবর্তিত হলে এই ফাইলটি পুনরায় তৈরি হয়। এটি চলমান kernel এবং সাম্প্রতিক kernel-গুলোকে সুরক্ষিত রাখে। ঝুঁকিটি timing-এ। নতুন kernel-এ reboot করার পরপরই sudo apt autoremove --purge চালালে protected list ইতিমধ্যে হালনাগাদ হয়ে যায়। ফলে আপনি যে পুরোনো kernel-এর ওপর নির্ভর করছিলেন, সেটি আর protected থাকে না। Keyboard-সহ কোনো মেশিনে এটি অসুবিধার বিষয়। কিন্তু headless server-এ এটি menu entry বেছে নেওয়া এবং rescue image থেকে disk mount করার মধ্যে পার্থক্য তৈরি করে।

কমপক্ষে দুটি kernel রাখুন। /boot-এ পর্যাপ্ত জায়গা থাকলে তিনটি রাখুন। uname -r পরীক্ষা করার পর নাম ধরে পুরোনো kernel সরান। এতে চলমান kernel কখনো মুছে ফেলতে পারবেন না:

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

এরপর শেষ command-টি আবার চালান। সংখ্যা তিন থেকে দুই হলে সেটি cleanup। সংখ্যা এক হলে পরবর্তী reboot-এ outage হওয়া শুধু সময়ের অপেক্ষা।

আপগ্রেডের আগে একটি snapshot নিন

apt upgrade-এর আগে নেওয়া snapshot-ই এমন একমাত্র recovery path, যা কোনো কিছু boot করার ওপর নির্ভর করে না। এটি restore করলে disk সেই অবস্থায় ফিরে যায়, যখন পুরোনো kernel default ছিল। এরপর console খোলা রেখেই আপগ্রেডের চেষ্টা করতে পারবেন। চলমান machine-এর snapshot crash consistent হয়। এর অর্থ, power কেটে গেলে disk যেমন অবস্থায় থাকত, snapshot-এও disk সেই অবস্থায় ধরা পড়ে। তাই আপনার provider offline snapshot সমর্থন করলে আগে server shutdown করুন। Snapshot backup নয়, কারণ এটি সাধারণত যে volume-এর copy তৈরি করে, সেই একই infrastructure-এ থাকে। VPS snapshot এবং প্রকৃত backup-এর পার্থক্য বোঝা জরুরি, কারণ kernel-এর সমস্যার চেয়ে বড় failure হলে কোনটি আপনাকে recovery করতে সাহায্য করবে, তা এর ওপর নির্ভর করে।

Release upgrade-এর ক্ষেত্রে এটি সবচেয়ে গুরুত্বপূর্ণ। কারণ একটি run-এ kernel, initramfs tools, bootloader এবং GRUB config—সবই পরিবর্তিত হয়। Ubuntu 24.04 থেকে 26.04-এ upgrade শুরু করার ঠিক আগে snapshot নিন, আগের রাতে নয়। এতে restore point সেই machine-এর বর্তমান অবস্থার সঙ্গে মিলে থাকবে, যেটি আপনি পরিবর্তন করতে যাচ্ছেন। আপনার server-এ যদি এখনো ওই upgrade প্রস্তাব করা না হয়ে থাকে, তার কারণ broken setup নয়, scheduling। কারণ LTS থেকে LTS upgrade কেবল প্রথম point release, 26.04.1 প্রকাশের পর চালু হয়।

Kernel package-কে unattended-upgrades কীভাবে পরিচালনা করে

Ubuntu-এর unattended-upgrades কোনো অনুমতি না চেয়েই security update ইনস্টল করে। Kernel package-ও অন্য সব package-এর মতো security pocket-এর মাধ্যমে আসে। এর দুটি ফল আছে।

প্রথমত, নতুন kernel ইনস্টল হলেও সেটি চালু থাকে না। Kernel কেবল boot-এর সময় কার্যকর হয়। /var/run/reboot-required ফাইলটি তৈরি হয়, এবং /var/run/reboot-required.pkgs-এ reboot-এর অনুরোধকারী কারণটি লেখা থাকে। তবে /etc/apt/apt.conf.d/50unattended-upgrades-এ Unattended-Upgrade::Automatic-Reboot সক্রিয় না করলে কোনো কিছুই নিজে থেকে restart হয় না।

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

দ্বিতীয়ত, এই বিলম্বের কারণে সমস্যার কারণ আড়ালে থাকতে পারে। কোনো server March মাসে একটি kernel ইনস্টল করতে পারে, তারপর সম্পূর্ণ ভিন্ন কারণে June মাসে reboot হয়ে আর চালু নাও হতে পারে। যে পরিবর্তনের কারণে boot ব্যর্থ হয়েছে, সেটি তিন মাস আগের। তাই সেই দিনের কাজের মধ্যে সমস্যার ব্যাখ্যা পাওয়া যায় না। আপনি যে kernel ব্যবহার করে এখন ব্যর্থ হচ্ছেন, সেটি ইনস্টল করা run কোথায় হয়েছে তা /var/log/apt/history.log-এ খুঁজে পাবেন।

নিজের নির্ধারিত দিনে, console window আগে থেকেই খোলা রেখে, ইচ্ছাকৃতভাবে reboot করুন। এই একটি অভ্যাস রহস্যময় outage-কে দুই মিনিটের menu selection-এ পরিণত করে। বিস্ময়কর reboot ছাড়াই automation চাইলে automatic install চালু রাখুন এবং automatic reboot বন্ধ রাখুন। সঠিক settings-এর জন্য দেখুন Ubuntu-তে unattended-upgrades কীভাবে configure করবেন। sudo apt-mark hold linux-image-generic দিয়ে kernel package hold করলে সেগুলো সম্পূর্ণভাবে আটকে যায়। একই সঙ্গে kernel security fix-ও বন্ধ হয়ে যায়। তাই এটিকে নিরাপত্তার ব্যবস্থা না ভেবে, সচেতনভাবে নেওয়া একটি trade-off হিসেবে বিবেচনা করুন।

FAQ

কীবোর্ড ছাড়া VPS-এ পুরোনো kernel কীভাবে boot করব?

provider-এর console (VNC বা serial) খুলুন এবং control panel থেকে hard reset শুরু করুন, কারণ clean reboot করার জন্য আপনি login করতে পারবেন না। মেশিনটি restart হওয়ার সময় বারবার Esc চাপুন, অথবা legacy BIOS boot হলে Shift ধরে রাখুন, যাতে GRUB menu খোলা থাকে। "Advanced options for Ubuntu" নির্বাচন করুন এবং সর্বশেষ kernel-এর নিচের entry বেছে নিন। login prompt পেলে আপনি কোন kernel-এ আছেন তা নিশ্চিত করতে uname -r চালান এবং আর কী কী install করা আছে দেখতে dpkg -l 'linux-image-*' চালান। সিস্টেম আবার চলার পরেই diagnosis করুন।

আমার VPS-এ কোনো GRUB menu-ই দেখায় না কেন?

Cloud image-গুলোতে সাধারণত /etc/default/grub.d/-এর অধীন কোনো file-এ GRUB timeout 0 সেট করা থাকে। তাই চাপ দেওয়ার সুযোগ ছাড়াই সর্বশেষ kernel start হয়। /etc/default/grub-এ GRUB_TIMEOUT=10 এবং GRUB_TIMEOUT_STYLE=menu সেট করুন। Menu যাতে serial console-এও পৌঁছায়, সে জন্য GRUB_TERMINAL="console serial" যোগ করুন। এরপর sudo update-grub চালান। grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ দিয়ে যাচাই করুন, কারণ ওই directory-এর file-গুলো মূল file-এর পরে read হয় এবং আপনার edit override করতে পারে।

/boot-এ স্থান খালি করতে কি পুরোনো kernel সরানো উচিত?

সবচেয়ে পুরোনো kernel-গুলো সরান এবং অন্তত দুইটি রেখে দিন। /boot পূর্ণ হয়ে যাওয়া নিজেই একটি failure mode, কারণ তখন initramfs তৈরি ব্যর্থ হয় এবং কার্যকর image ছাড়া একটি kernel থেকে যায়। uname -r পরীক্ষা করার পর exact package name ব্যবহার করে purge করুন, যাতে বর্তমানে চলমান kernel কখনো candidate না হয়। Headless machine-এ blanket sudo apt autoremove --purge ব্যবহার এড়িয়ে চলুন। কারণ প্রতিটি kernel পরিবর্তনের সময় protected-kernel list আবার তৈরি হয়, এবং ভুল সময়ে চালালে menu-তে একটি kernel ও কোনো fallback entry না-ও থাকতে পারে।

unattended-upgrades কি আমার boot নষ্ট করতে পারে?

এটি এমন একটি kernel install করতে পারে যা পরে boot করতে ব্যর্থ হয়। তবে /etc/apt/apt.conf.d/50unattended-upgrades-এ Unattended-Upgrade::Automatic-Reboot true হিসেবে সেট না থাকলে এটি machine restart করে না। সাধারণত ব্যর্থতা দেরিতে দেখা যায়: automatic run-এর সময় kernel install হয়, /var/run/reboot-required দেখা দেয়, এবং কয়েক সপ্তাহ পরে পরবর্তী reboot-এর সময় সমস্যাটি প্রকাশ পায়। Console আগে থেকেই খোলা রেখে ইচ্ছাকৃতভাবে reboot করুন এবং কোন run আপনি যে kernel boot করছেন সেটি install করেছে তা জানতে /var/log/apt/history.log পড়ুন।