Kernel update-এর পরে VPS boot না করলে করণীয়

kernel update-এর পরে VPS boot না করলে প্রথমে যা করবেন

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

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

কোনো কিছু পরিবর্তন করার আগে আপনার console-এর লেখাগুলো পড়ুন। ওই screen-এর লেখাই নির্ধারণ করবে আপনি কোন ধরনের ব্যর্থতার সম্মুখীন হয়েছেন, এবং দুটি সার্ভারই "boot না করলে"-ও তাদের সমাধানের উপায় বিপরীত হতে পারে।

SSH অকেজো হয়ে পড়লে কনসোলে কীভাবে প্রবেশ করব?

আপনার প্রোভাইডারের কন্ট্রোল প্যানেল খুলুন এবং সেখানে কনসোল অপশনটি খুঁজুন। সাধারণত একে VNC console, web console, noVNC এবং serial console নামে ডাকা হয়। যদি উভয়ই থাকে, তবে serial console ব্যবহার করা শ্রেয়, কারণ এটি আপনাকে টেক্সট আকারে আউটপুট দেয় যা আপনি স্ক্রল এবং কপি করতে পারবেন; অন্যদিকে VNC ভিউ কেবল স্ক্রিনের একটি ছবি মাত্র। সার্ভার সচল থাকাকালীনই এই কন্ট্রোলটি খুঁজে বের করুন এবং এটি কাজ করছে কি না তা নিশ্চিত করুন। সার্ভার ডাউন হওয়ার পর এটি খুঁজতে গেলে আপনার প্রয়োজনীয় মানসিক স্থিরতা বজায় রাখা কঠিন হবে। এই চেকটি নতুন VPS সেটআপের প্রথম দশ মিনিটে সম্পন্ন করা উচিত, ঠিক যেমনটি ফায়ারওয়াল রুল এবং SSH কি-এর ক্ষেত্রে করা হয়।

অধিকাংশ প্যানেলে একটি rescue mode বা recovery image-এর সুবিধা থাকে। এটি প্রোভাইডারের নেটওয়ার্ক থেকে একটি ছোট সিস্টেম বুট করে এবং আপনার ডিস্কটিকে একটি অতিরিক্ত ডিভাইস হিসেবে মাউন্ট করে, ফলে আপনার ডিস্কের কোনো কিছুই রান করে না। GRUB নিজে ক্ষতিগ্রস্ত হলে rescue mode হলো শেষ ভরসা, এছাড়া সার্ভারটি আর ব্যবহার না করার সিদ্ধান্ত নিলে সেখান থেকে ডেটা কপি করার জন্যও এটি ব্যবহৃত হয়।

বুট মেনুতে যাওয়ার জন্য সাধারণত আপনাকে প্যানেল থেকে একটি hard reset দিতে হবে, কারণ আপনি যে মেশিনে লগইন করতে পারছেন না সেখানে sudo reboot কমান্ডটি চালানো সম্ভব নয়। একটি hard reset হলো বিদ্যুৎ সংযোগ বিচ্ছিন্ন করার সমতুল্য। এর ফলে ফাইলসিস্টেমগুলো সঠিকভাবে শাটডাউন হয় না, তাই পরবর্তী বুটের সময় একটি ফাইলসিস্টেম চেক হওয়ার সম্ভাবনা থাকে।

GRUB মেনু থেকে কীভাবে পুরোনো কার্নেল নির্বাচন করব?

রিসেট বোতাম চাপার মুহূর্ত থেকে কনসোলটি পর্যবেক্ষণ করুন। প্রথম কয়েক সেকেন্ডের মধ্যে বারবার Esc চাপুন, অথবা যদি মেশিনটি legacy BIOS মোডে বুট হয় তবে Shift চেপে ধরে রাখুন। এই সময়সীমাটি খুব সংক্ষিপ্ত এবং কনসোল ভিউয়ারের সংযোগ হতে সাধারণত এক সেকেন্ড সময় লাগে, তাই শুরু থেকেই চাপতে থাকুন।

মেনু দেখা দিলে "Advanced options for Ubuntu" নির্বাচন করুন। এই সাবমেনুতে প্রতিটি ইনস্টল করা কার্নেল নতুন থেকে পুরোনো ক্রমে তালিকাভুক্ত থাকে, যার সাথে প্রতিটি কার্নেলের জন্য একটি recovery mode এন্ট্রি থাকে। দ্বিতীয় সাধারণ এন্ট্রিটি বেছে নিন, যা নতুন কার্নেলের ঠিক আগের কার্নেল এবং Enter চাপুন। Recovery mode ভিন্ন একটি বিষয়: এটি একটি ন্যূনতম single user সিস্টেমে বুট করে এবং এটি মেরামতের কাজের জন্য, আপনার সার্ভিসগুলো পুনরায় অনলাইনে আনার জন্য নয়।

যদি পুরোনো কার্নেলটি বুট হয়, তবে আপনার সার্ভার আবার সচল হয়েছে। আপনি বর্তমানে কোন কার্নেলে আছেন তা নিশ্চিত করুন এবং নম্বরগুলো লিখে রাখুন।

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

dpkg আউটপুটটি আপনার ইনস্টল করা কার্নেলগুলোর তালিকা। যদি এতে মাত্র একটি লাইন থাকে, তবে আপনার কোনো fallback নেই এবং এটিই সবার আগে ঠিক করা প্রয়োজন।

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

ক্লাউড ইমেজগুলোতে এমন কনফিগারেশন থাকে যা মেনুটিকে লুকিয়ে রাখে। উবুন্টু ইমেজগুলোতে সাধারণত /etc/default/grub.d/-এর অধীনে থাকা একটি ফাইলে timeout 0 সেট করা থাকে, ফলে নতুন কার্নেল সাথে সাথে চালু হয়ে যায় এবং কোনো কি (key) চাপার সুযোগ থাকে না।

এর বিপরীত পরিস্থিতিও হতে পারে, যেখানে মেনু স্ক্রিনে আটকে থাকে এবং মনে হয় সিস্টেম হ্যাং হয়ে আছে। 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টার সময় মেনু অ্যাক্সেস করার জন্য প্রতি বুটে 10 সেকেন্ডের বিলম্ব খুব সামান্য একটি মূল্য।

আমি কোন ধরনের ব্যর্থতার সম্মুখীন হচ্ছি?

কনসোল থেমে যাওয়ার আগের শেষ বিশ লাইন পড়ুন। কার্নেল আপডেটের পর যা ঘটে তার বেশিরভাগই চারটি প্যাটার্নের অন্তর্ভুক্ত।

GRUB নিজের ফাইল খুঁজে পাচ্ছে না। আপনি একটি grub rescue> প্রম্পট পাবেন, অথবা এমন কোনো পার্টিশন বা ফাইল সম্পর্কে ত্রুটি বার্তা পাবেন যা অস্তিত্বহীন, এবং কোনো কার্নেল মেসেজ কখনোই দেখা যাবে না। কার্নেল তখনো কাজ শুরু করেনি। এটি কোনো ডিস্ক বা পার্টিশন পরিবর্তনের পর অথবা ভুল ডিভাইসে বুটলোডার লেখার কারণে ঘটে, কার্নেল প্যাকেজের নিজস্ব কোনো সমস্যার কারণে নয়।

কার্নেল শুরু হয় কিন্তু রুট মাউন্ট করতে পারে না। কার্নেল মেসেজগুলো স্ক্রল হতে থাকে, তারপর আপনি একটি busybox শেলে পৌঁছাবেন যার প্রম্পটটি (initramfs) দেখাবে, অথবা বুট প্রক্রিয়াটি রুট ফাইলসিস্টেম মাউন্ট করতে না পারার প্যানিক মেসেজ দিয়ে শেষ হবে। কার্নেল লোড হয়েছে। initramfs, যা ছোট একটি অস্থায়ী রুট হিসেবে আপনার আসল রুট ফাইলসিস্টেম খুঁজে বের করে এবং মাউন্ট করে, সেটি ডিস্কটি খুঁজে পায়নি। Ubuntu-তে এই শেলের আগে সাধারণত রুট ডিভাইসের জন্য অপেক্ষা করে হাল ছেড়ে দেওয়ার একটি বার্তা থাকে এবং সেখানে কাঙ্ক্ষিত UUID-টি উল্লেখ করা থাকে। সেই UUID-টি কপি করুন এবং পরবর্তীতে blkid আউটপুটের সাথে মিলিয়ে দেখুন।

লজিক্যাল ভলিউম কখনোই দেখা যায় না। এটি আগের শ্রেণিরই একটি নির্দিষ্ট কারণ। (initramfs) প্রম্পটে, ls /dev/mapper চালান। যদি একমাত্র এন্ট্রি control হয়, তবে কোনো LVM (logical volume manager) ভলিউম সক্রিয় হয়নি, তাই রুট ডিভাইসটির অস্তিত্ব নেই। ভলিউম গ্রুপগুলোকে ম্যানুয়ালি চালু করুন:

lvm vgchange -ay
ls /dev/mapper
exit

exit কমান্ডটি initramfs স্ক্রিপ্টের কাছে নিয়ন্ত্রণ ফিরিয়ে দেয়, যা মাউন্ট করার প্রক্রিয়াটি পুনরায় চেষ্টা করে। যদি সিস্টেমটি এরপর বুট হয়, তবে নতুন initramfs-এ LVM-এর অংশগুলো অনুপস্থিত ছিল। এক্ষেত্রে সমাধান হলো কার্নেল পরিবর্তন না করে সেই ইমেজটি পুনরায় তৈরি (rebuild) করা।

Linux থেকে কিছুই দেখা যাচ্ছে না। কনসোলে ফার্মওয়্যার টেক্সট, একটি UEFI (unified extensible firmware interface) শেল, কোনো কার্নেল আউটপুট ছাড়া একটি ফাঁকা স্ক্রিন অথবা রিসেট লুপ দেখা যায়। Linux চলার আগেই ব্যর্থতাটি ঘটছে। সিস্টেম চালু হওয়ার পর আপনার সার্ভার কোন মোড ব্যবহার করছে তা পরীক্ষা করুন, কারণ অনেক VPS ইনস্ট্যান্স legacy BIOS মোডে বুট হয় এবং কখনোই EFI পাথে যায় না:

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

আপগ্রেডের সময় /boot/efi মাউন্ট করা না থাকা UEFI মেশিনের ক্ষেত্রে একটি সাধারণ কারণ। কারণ EFI সিস্টেম পার্টিশন রক্ষণাবেক্ষণকারী প্যাকেজগুলো তখন সাধারণ একটি খালি ডিরেক্টরিতে লিখে ফেলে। ফার্মওয়্যারটি পুরনো বুট এন্ট্রি দিয়েই শুরু হতে থাকে যতক্ষণ না সেই এন্ট্রিটি ডিস্কের বর্তমান অবস্থার সাথে অমিল হয়।

আরও একটি প্যাটার্ন আছে যা আসলে বুট ব্যর্থতা নয়। যদি আপনি এমন একটি রুট শেলে পৌঁছান যেখানে বলা হয় সিস্টেমটি emergency mode-এ আছে, তবে বুঝতে হবে কার্নেল বুট হয়েছে কিন্তু ইউজারস্পেস থেমে গেছে। এর মানে সাধারণত /etc/fstab-এ কোনো ভুল লাইন আছে অথবা ফাইলসিস্টেম চেক করতে ব্যর্থ হয়েছে। সেই শেলে journalctl -xb চালান এবং যে ইউনিটটি ব্যর্থ হয়েছে তার নাম পড়ুন।

কার্নেল প্যাকেজটি কি নষ্ট, নাকি 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 পূর্ণ হয়ে থাকলে প্রথমে জায়গা খালি করুন, তারপর আপনার প্রয়োজনীয় ভার্সনের জন্য ইমেজটি পুনরায় তৈরি করুন এবং মেনু রিফ্রেশ করুন। আপনার নিজের ls আউটপুট থেকে ভার্সন স্ট্রিংটি নিন, কারণ নিচের প্লেসহোল্ডারটি কোনো প্রকৃত রিলিজ নয়:

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

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

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

যখন কোনো কার্নেল বুট হয় না তখন রেসকিউ মোড থেকে মেরামত

যদি বুট মেনুর প্রতিটি এন্ট্রি ব্যর্থ হয়, তবে প্রোভাইডারের রেসকিউ ইমেজ বুট করুন এবং বাইরে থেকে ডিস্কটি মেরামত করুন। আপনার ডিস্কটি একটি আনমাউন্ট করা ডিভাইস হিসেবে প্রদর্শিত হবে, তাই এতে কোনো কিছু চলমান থাকবে না এবং কোনো প্রসেস আপনার কাজে বাধা দিতে পারবে না।

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 কোনো এন্ট্রি একবার চালু করে পুনরায় আপনার নির্ধারিত ডিফল্ট এন্ট্রিতে ফিরে আসতে পারে। আপনার নির্ভরযোগ্য কার্নেলটিকে ডিফল্ট হিসেবে সেট করুন, তারপর নতুন কার্নেলটি শুধুমাত্র একবারের জন্য বুট করুন। যদি এটি ব্যর্থ হয়, তবে প্যানেল থেকে একটি হার্ড রিসেট দিলেই আপনি আগের সঠিক কার্নেলে ফিরে আসবেন, এক্ষেত্রে কনসোল টাইমিং নিয়ে কোনো দুশ্চিন্তা করতে হবে না।

/etc/default/grub-এ GRUB_DEFAULT=saved সেট করুন, 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 হিসেবে প্রিন্ট করবে। এই আউটপুটটিই প্রমাণ যে মেকানিজমটি কাজ করছে, কারণ এটি সেভ করার জন্য একটি রাইটেবল (writable) /boot/grub/grubenv প্রয়োজন, যা কিছু লেআউটে নীরবে কাজ করে না। এন্ট্রি 0 হলো মেনুর একদম উপরের অংশ, যা নতুন কার্নেল। এখানে সংখ্যার চেয়ে টাইটেল ব্যবহার করা বেশি নিরাপদ, কারণ কার্নেল ইনস্টল বা রিমুভ করার সাথে সাথে সংখ্যাগুলো পরিবর্তিত হতে পারে।

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

APT এমন কিছু kernel প্যাকেজের তালিকা রাখে যা এটি নিজে থেকে মুছে ফেলে না। আপনার তালিকাটি দেখুন:

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

kernel প্যাকেজ পরিবর্তিত হলে এই ফাইলটি পুনরায় তৈরি হয় এবং এটি চলমান kernel ও সাম্প্রতিকতম kernel-গুলোকে সুরক্ষিত রাখে। বিপত্তিটি ঘটে সময়ের পার্থক্যের কারণে। একটি নতুন kernel-এ reboot করার পরপরই যদি আপনি sudo apt autoremove --purge চালান, তবে সুরক্ষিত তালিকাটি এগিয়ে যায়। ফলে যে পুরনো kernel-টির ওপর আপনি নির্ভর করছিলেন, সেটি আর সুরক্ষিত থাকে না। কীবোর্ডযুক্ত মেশিনে এটি কেবল একটি অসুবিধা, কিন্তু headless সার্ভারের ক্ষেত্রে এটি এমন একটি পরিস্থিতি তৈরি করে যেখানে আপনাকে 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'

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

আপগ্রেডের আগে একটি স্ন্যাপশট নিন

apt upgrade-এর আগে নেওয়া একটি স্ন্যাপশট হলো পুনরুদ্ধারের একমাত্র পথ যা কোনো কিছু বুট করার ওপর নির্ভর করে না। এটি রিস্টোর করলে ডিস্কটি এমন অবস্থায় ফিরে যায় যেখানে পুরনো কার্নেলটি ডিফল্ট ছিল এবং আপনি কনসোল খোলা রেখেই আপগ্রেডটি পুনরায় চেষ্টা করতে পারেন। চলমান মেশিনের স্ন্যাপশটগুলো 'ক্র্যাশ কনসিস্টেন্ট' হয়, যার অর্থ হলো এগুলো ডিস্কটিকে এমনভাবে ক্যাপচার করে যেন বিদ্যুৎ সংযোগ বিচ্ছিন্ন করা হয়েছে। তাই আপনার প্রোভাইডার যদি অফলাইন স্ন্যাপশট সমর্থন করে, তবে আগে সার্ভারটি শাটডাউন করে নিন। স্ন্যাপশট কোনো ব্যাকআপ নয়, কারণ এটি সাধারণত সেই একই ইনফ্রাস্ট্রাকচারে থাকে যেটির ভলিউম এটি কপি করে। VPS স্ন্যাপশট এবং প্রকৃত ব্যাকআপের মধ্যে পার্থক্য বোঝা জরুরি, কারণ যখন ব্যর্থতা কার্নেলের চেয়ে বড় হয়, তখন কোনটি আপনাকে রক্ষা করবে তা এর ওপরই নির্ভর করে।

রিলিজ আপগ্রেডের ক্ষেত্রে এটি সবচেয়ে বেশি গুরুত্বপূর্ণ, যেখানে কার্নেল, initramfs টুলস, বুটলোডার এবং GRUB কনফিগারেশন—সবই একবারে পরিবর্তিত হয়। আপগ্রেড শুরু করার ঠিক আগে স্ন্যাপশটটি নিন, আগের রাতে নয়। এতে রিস্টোর পয়েন্টটি সেই মেশিনের সাথে হুবহু মিলে যাবে যেটিতে আপনি Ubuntu 24.04 থেকে 26.04 আপগ্রেড করতে যাচ্ছেন।

কিভাবে unattended-upgrades কার্নেল প্যাকেজগুলো পরিচালনা করে

Ubuntu-এর unattended-upgrades কোনো অনুমতি ছাড়াই নিরাপত্তা আপডেট ইনস্টল করে এবং অন্যান্য সবকিছুর মতোই কার্নেল প্যাকেজগুলো security pocket-এর মাধ্যমে আসে। এর ফলে দুটি বিষয় ঘটে।

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

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

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

আপনার নিজের বেছে নেওয়া দিনে এবং কনসোল উইন্ডো খোলা রেখে ইচ্ছাকৃতভাবে রিবুট করুন। এই একটি অভ্যাস রহস্যময় বিভ্রাটকে দুই মিনিটের একটি সাধারণ কাজে পরিণত করে। আপনি যদি চমক ছাড়াই অটোমেশন চান, তবে স্বয়ংক্রিয় ইনস্টল চালু রাখুন কিন্তু স্বয়ংক্রিয় রিবুট বন্ধ রাখুন। সঠিক সেটিংসের জন্য Ubuntu-তে unattended-upgrades কনফিগার করার নিয়ম দেখুন। sudo apt-mark hold linux-image-generic ব্যবহার করে কার্নেল প্যাকেজ আটকে রাখলে সেগুলো পুরোপুরি বন্ধ হয়ে যায়, কিন্তু একই সাথে কার্নেলের নিরাপত্তা আপডেটগুলোও বন্ধ হয়ে যায়। তাই এটিকে একটি নিরাপত্তা ব্যবস্থা হিসেবে না দেখে, আপনার নেওয়া একটি সিদ্ধান্ত বা আপস হিসেবে বিবেচনা করুন।

FAQ

কীবোর্ড নেই এমন VPS-এ কীভাবে পুরোনো কার্নেল বুট করব?

প্রোভাইডারের কনসোল (VNC বা সিরিয়াল) খুলুন এবং কন্ট্রোল প্যানেল থেকে একটি হার্ড রিসেট ট্রিগার করুন, কারণ আপনি স্বাভাবিকভাবে লগইন করে রিবুট করতে পারবেন না। মেশিনটি রিস্টার্ট হওয়ার সময় GRUB মেনু ধরে রাখার জন্য বারবার Esc চাপুন, অথবা লিগ্যাসি BIOS বুটের ক্ষেত্রে Shift চেপে ধরে রাখুন। "Advanced options for Ubuntu" বেছে নিন এবং নতুন কার্নেলের নিচের এন্ট্রিটি নির্বাচন করুন। লগইন প্রম্পট আসার পর, আপনি কোন কার্নেলে আছেন তা নিশ্চিত করতে uname -r চালান এবং আর কী কী ইনস্টল করা আছে তা দেখতে dpkg -l 'linux-image-*' ব্যবহার করুন। সিস্টেম আবার সচল হওয়ার পরেই কেবল রোগ নির্ণয় করুন।

আমার VPS-এ কেন কোনো GRUB মেনু দেখা যাচ্ছে না?

ক্লাউড ইমেজগুলোতে সাধারণত /etc/default/grub.d/-এর অধীনে থাকা ফাইলে GRUB টাইমআউট 0 সেট করা থাকে, তাই কোনো কিছু চাপার সুযোগ ছাড়াই নতুন কার্নেল চালু হয়ে যায়। /etc/default/grub-এ GRUB_TIMEOUT=10 এবং GRUB_TIMEOUT_STYLE=menu সেট করুন, মেনু যেন সিরিয়াল কনসোলেও পৌঁছায় সেজন্য 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 চালানো এড়িয়ে চলুন, কারণ প্রতিবার কার্নেল পরিবর্তনের সময় প্রোটেক্টেড-কার্নেল তালিকা পুনরায় তৈরি হয় এবং ভুল সময়ে কমান্ডটি চালালে আপনি একটি মাত্র কার্নেল নিয়ে আটকে যেতে পারেন, যার কোনো ফলব্যাক এন্ট্রি মেনুতে থাকবে না।

unattended-upgrades কি আমার বুট প্রক্রিয়া নষ্ট করতে পারে?

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