VPS-এ পরের boot-এর জন্য kernel pin করবেন কীভাবে

কোন বিষয় নির্ধারণ করে আপনার VPS কোন kernel দিয়ে boot হবে

আপনার VPS পরবর্তী boot-এ কোন kernel ব্যবহার করবে, তা একটি generated file দ্বারা নির্ধারিত হয়: /boot/grub/grub.cfg। এই file কখনো সরাসরি edit করবেন না। এর input পরিবর্তন করে file-টি regenerate করুন। Ubuntu cloud image-এ এই input-গুলোর একটি image vendor সরবরাহ করে। এটি menu selection অকার্যকর করে দিতে পারে। তাই rented server-এ GRUB_DEFAULT=1 চালানোর পর update-grub চালালেও কোনো পরিবর্তন হয় না, অথচ laptop install-এ একই দুটি ধাপ কাজ করে।

এই ক্রমে কাজ করুন। প্রথমে নিশ্চিত করুন, kernel বেছে নেওয়ার অধিকার আপনার আছে কি না। Vendor যোগ করা file-সহ প্রতিটি input file পড়ুন। Generated output পড়ে এতে বাস্তবে কতটি entry আছে, তা গণনা করুন। এরপর pinning method বেছে নিন। শুধুমাত্র SSH-এর মাধ্যমে যেটিতে সংযোগ করেন, এমন machine-এ এটি ভুলভাবে করলে rescue console প্রয়োজন হতে পারে। তাই সবচেয়ে নিরাপদ উত্তরগুলো এই page-এর শেষে দেওয়া আছে, এবং প্রায়ই সেগুলোই সঠিক পদ্ধতি।

প্রথমে যাচাই করুন, kernel-টি pin করার অধিকার আপনার আছে কি না

uname -r
systemd-detect-virt
ls -1 /boot/vmlinuz-*

systemd-detect-virt চালিয়ে kvm, qemu অথবা xen দেখালে বুঝবেন, আপনি নিজের kernel চালাচ্ছেন এবং নিচের সব নির্দেশ প্রযোজ্য। lxc অথবা openvz দেখালে বুঝবেন, আপনার server host-এর kernel ভাগ করে ব্যবহার করছে। তাই আপনার কোনো bootloader নেই এবং pin করার মতো কোনো kernel-ও নেই। এই ক্ষেত্রে uname -r এমন একটি version দেখায়, যা /boot/vmlinuz-*-এ একেবারেই নেই। কারণ চলমান kernel-টি host-এর এবং আপনার disk-এর কোনো setting তা পরিবর্তন করতে পারে না।

ls -1 /boot/vmlinuz-*-এ আপনি বেছে নিতে পারেন এমন kernel-গুলোর প্রকৃত তালিকা থাকে। এতে যদি একটি মাত্র line থাকে, তাহলে আগের kernel ইতিমধ্যে মুছে ফেলা হয়েছে। কোনো bootloader setting সেটি ফিরিয়ে আনতে পারবে না। সাধারণত autoremove চলার সময় এমন হয়। আপনি যে server-টি গুরুত্বপূর্ণ কাজে ব্যবহার করেন, সেখানে Ubuntu-তে পুরোনো kernel পরিষ্কার করার আগে বিষয়টি বোঝা উচিত।

আপনি যে ফাইল সম্পাদনা করেন, GRUB সেই ফাইল পড়ে না

/etc/default/grub ফাইলে সাধারণ shell variable assignment থাকে। এটি input। /boot/grub/grub.cfg হলো output। এটি # DO NOT EDIT THIS FILE দিয়ে শুরু হয় এবং কারণটিও সেখানে উল্লেখ থাকে। output-এ আপনি যা লিখবেন, পরের বার কোনো kernel package install বা remove হলে তা মুছে যাবে, কারণ সেই package script-গুলো ফাইলটি পুনরায় তৈরি করে।

cat /usr/sbin/update-grub

update-grub একটি wrapper। এটি grub-mkconfig -o /boot/grub/grub.cfg চালায়। grub-mkconfig -o /boot/grub/grub.cfg variable পড়ে, /etc/grub.d/-এর প্রতিটি script চালায় এবং ফলাফল লিখে। দুটি command, একটি দিক: input যায় ভেতরে, grub.cfg বেরিয়ে আসে।

আপনার সেটিং কী override করে: /etc/default/grub.d

grep -rn '^[^#]' /etc/default/grub /etc/default/grub.d/

দ্বিতীয় path-টিই সাধারণত বাদ পড়ে। grub-mkconfig প্রথমে /etc/default/grub source করে, তারপর glob order অনুযায়ী /etc/default/grub.d/-এর প্রতিটি *.cfg file source করে। এটি কীভাবে কাজ করে, সেই code দেখুন:

grep -n 'default/grub' /usr/sbin/grub-mkconfig

Sourcing সাধারণ shell প্রক্রিয়া। তাই সর্বশেষ assignment কার্যকর হয়। Ubuntu cloud image-গুলো ওই directory-তে file দেয় এবং আপনার file পড়ার পর timeout ও kernel command line-এর মতো setting নির্ধারণ করে। আপনার GRUB_TIMEOUT=10-এর /etc/default/grub কিছুক্ষণ পরেই একটি vendor file দ্বারা overwrite হয়, যেখানে এর মান 0 নির্ধারণ করা থাকে। উপরের grep command আপনার image-এ থাকা সঠিক assignment-গুলো দেখায়। তাই এই বাক্যের ওপর নির্ভর না করে সেগুলো পড়ুন।

এখান থেকে ব্যবহারিক নিয়মটি হলো: নিজের setting এমন একটি file-এ রাখুন, যেটির sort order সর্বশেষ হয়, যেমন /etc/default/grub.d/99-local.cfg। /etc/default/grub edit করবেন না। তাহলে image-এর কোনো shipped file আপনার file-এর পরে প্রয়োগ হতে পারবে না।

GRUB_FORCE_PARTUUID কেন মেনু নির্বাচনকে অপ্রাসঙ্গিক করে

grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/
grep -n GRUB_FORCE_PARTUUID /etc/grub.d/10_linux
sudo grep -n 'root=PARTUUID' /boot/grub/grub.cfg

GRUB_FORCE_PARTUUID generator-কে partition UUID ব্যবহার করে root filesystem খুঁজতে নির্দেশ দেয়। এটি সরাসরি kernel command line-এ root=PARTUUID=... হিসেবে লেখা হয়। ফলে boot-এর সময় filesystem UUID খোঁজা হয় না। image vendor এই variable সেট করে, কারণ এতে যে hardware-এ image তৈরি করা হয়নি, সেখানেও একই disk image নির্ভরযোগ্যভাবে boot করতে পারে। দ্বিতীয় grep কমান্ডটি /etc/grub.d/10_linux-এ এই variable নিয়ে কাজ করা code দেখায়। এই script আপনার নিজের disk-এ রয়েছে। আপনার image কীভাবে কাজ করে, সে বিষয়ে এটিই চূড়ান্ত উৎস।

এখানে গুরুত্বপূর্ণ বিষয় হলো ফলাফল: এই পথে generator ইনস্টল করা kernel-গুলোর পূর্ণ তালিকার বদলে সরাসরি একটি boot entry লেখে। শেষ পর্যন্ত কতটি entry তৈরি হয়েছে, তা গণনা করুন।

sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg
sudo grep -nE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg

গণনা 1 হলে নির্বাচন করার জন্য দ্বিতীয় কোনো entry নেই। তাই GRUB_DEFAULT=1 এমন একটি entry নির্দেশ করে, যার অস্তিত্ব নেই। GRUB সেটি নির্ধারণ করতে পারে না। ফলে এটি প্রথম entry boot করে, অর্থাৎ আপনি যে নতুন kernel এড়াতে চেয়েছিলেন সেটিই boot হয়। grub-set-default ব্যবহার করেও সমাধান হবে না, কারণ সমস্যা default-এ নয়। আপনি যে মেনু থেকে নির্বাচন করতে চাইছেন, সেটি তৈরি হয়ইনি।

পূর্ণ মেনু ফিরিয়ে আনতে vendor file-টি অন্যত্র সরিয়ে রাখুন। এরপর পরিবর্তন স্থায়ী করার আগে ফলাফল preview করুন। কোনো -o ছাড়া grub-mkconfig চালালে এটি standard output-এ ফলাফল লিখবে এবং disk-এ কোনো পরিবর্তন করবে না।

sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '
sudo mkdir -p /root/grub-backup
sudo mv /etc/default/grub.d/<the file your grep named> /root/grub-backup/
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '

গণনা 1 থেকে কয়েকটিতে বেড়ে গেলে বোঝা যায়, forcing সরানোর পর entry-গুলো দেখা যাচ্ছে। এখনো disk-এ কিছু লেখা হয়নি। দ্বিতীয় গণনার ফল সঠিক না হলে file-টি আগের জায়গায় ফিরিয়ে দিন। কারণ আপনার provider-এর image root filesystem খুঁজে পেতে forced PARTUUID ব্যবহার করে। এটি সরিয়ে দিলে machine search path ব্যবহার করবে। বাস্তবে update-grub চালানোর আগে snapshot নিন।

শুধু একটি ত্রুটিপূর্ণ kernel থেকে সাময়িকভাবে চালু থাকতে চাইলে এখানেই থামুন এবং নিচে দেওয়া নিরাপদ option ব্যবহার করুন। একটি upgrade-এর সমস্যা এড়াতে remote server-এ boot menu পুনর্নির্মাণ করা সমস্যাটির তুলনায় বেশি ঝুঁকিপূর্ণ।

কেন entry number ধরে রাখা ভুল পদ্ধতি

GRUB_DEFAULT একটি number, title অথবা identifier গ্রহণ করে। Number 0 থেকে শীর্ষস্তরের entry গণনা করে। Nested entry-তে > separator হিসেবে ব্যবহৃত হয়। তাই GRUB_DEFAULT="1>2" বলতে index 1-এর submenu-এর ভেতরের index 2-এর entry বোঝায়।

Index স্থির থাকে না। 10_linux kernel-গুলোকে newest first ক্রমে তালিকাভুক্ত করে। তাই একটি kernel install করলে প্রতিটি পুরোনো entry এক ধাপ নিচে সরে যায় এবং একটি kernel remove করলে সেগুলো এক ধাপ ওপরে উঠে আসে। আপনার সতর্কভাবে নির্ধারিত 1>2 তখনও resolve হবে। তবে এটি এখন অন্য একটি kernel নির্দেশ করবে। কোনো error হবে না, কোনো warning-ও দেখাবে না। reboot-এর পরে আপনি বিষয়টি জানতে পারবেন।

Identifier পরিবর্তিত হয় না, কারণ প্রতিটিতে kernel version অন্তর্ভুক্ত থাকে। আপনার identifier দেখুন:

sudo awk -F"'" '/menuentry_id_option/ {print $2, "==>", $4}' /boot/grub/grub.cfg

Output-এর প্রথম কয়েকটি line উপেক্ষা করুন। এগুলো header-এ সংজ্ঞায়িত variable দেখায়। এরপর বাম পাশের অংশটি হলো reader যে title দেখেন, আর ডান পাশের অংশটি হলো tools-এ দেওয়ার identifier। কোনো entry submenu-এর ভেতরে থাকলে numeric form-এর মতোই submenu identifier এবং entry identifier এই ক্রমে > দিয়ে যুক্ত করুন।

grub-reboot ব্যবহার করে একবারের জন্য আগের kernel-এ boot করুন

Remote server-এ একবারের জন্য নির্বাচন করাই সঠিক পদ্ধতি, কারণ এটি নিজে থেকেই আগের অবস্থায় ফিরে যায়। grub-reboot, /boot/grub/grubenv-এ next_entry লিখে। GRUB সেই variable পড়ে, এটি clear করে, এবং কোনো কিছু boot করার আগেই clear করা value সংরক্ষণ করে। তাই যে kernel panic করে, সেটি পরবর্তী boot-এ আবার চেষ্টা করা হয় না। আপনি একবার চেষ্টা করার সুযোগ পান, এরপর machine নিজে থেকেই স্বাভাবিক default-এ ফিরে যায়।

প্রথমে নিশ্চিত করুন যে generated config আদৌ সেই variable পড়ে কি না:

sudo grep -n -B2 -A5 'next_entry' /boot/grub/grub.cfg

আপনার একটি load_env line এবং এমন একটি block থাকা উচিত, যা next_entry থেকে default সেট করে। grep কোনো output না দিলে boot-এর সময় আপনার image grubenv পড়ে না। ফলে shell-এ grub-reboot গ্রহণ করা হলেও bootloader সেটি উপেক্ষা করবে। আগের section-এর forced direct boot path এখানেও দ্বিতীয় স্থানে দেখা যাচ্ছে।

sudo grub-reboot '<the identifier you copied>'
sudo grub-editenv list

এখন grub-editenv list-এর output-এ আপনি পাস করা value-টি হুবহু ধারণ করা একটি next_entry= line দেখা উচিত। আপনার provider-এর console browser tab-এ খুলুন। এরপর reboot করে ফলাফল পরীক্ষা করুন।

sudo reboot

uname -r

uname -r পুরোনো version দেখালে বুঝবেন pin কাজ করেছে। নতুন version দেখালে identifier resolve হয়নি, অথবা grubenv পড়া হচ্ছে না। উভয় ক্ষেত্রেই machine চালু আছে। একবারের জন্য ব্যবহৃত form-এর উদ্দেশ্য এটিই।

GRUB_DEFAULT=saved দিয়ে পছন্দ স্থায়ী করুন

GRUB_DEFAULT=saved ডিফল্ট মানটি grubenv-এর saved_entry থেকে নেয়, এবং grub-set-default দিয়ে সেই মান সেট করা হয়। এটি kernel install-এর পরেও কার্যকর থাকে, কারণ update-grub grub.cfg নতুন করে লেখে এবং grubenv-এ কখনও পরিবর্তন করে না।

echo 'GRUB_DEFAULT=saved' | sudo tee /etc/default/grub.d/99-local.cfg
sudo update-grub
sudo grub-set-default '<the identifier you copied>'
sudo grub-editenv list
sudo grep -n 'set default' /boot/grub/grub.cfg

শেষ command-টির আউটপুটে অবশ্যই set default="${saved_entry}" থাকতে হবে। যদি set default="0" দেখা যায়, তাহলে আপনার file-এর পরে source হওয়া কোনো configuration GRUB_DEFAULT-কে আবার literal value-তে সেট করেছে। তাই আবার /etc/default/grub.d/ তালিকাভুক্ত করুন এবং যাচাই করুন যে 99-local.cfg সত্যিই শেষে sort হয়।

GRUB_SAVEDEFAULT=true একটি ভিন্ন setting, এবং এটিকে এই setting-এর সঙ্গে গুলিয়ে ফেলা সহজ। এটি আপনি যে entry দিয়ে boot করেছেন, সেটিকেই নতুন default হিসেবে সংরক্ষণ করে। ফলে সর্বশেষ সফল boot অনুযায়ী default পরিবর্তিত হয়। server-এ এর অর্থ হলো unattended reboot নীরবে আপনার নির্ধারিত pin পরিবর্তন করতে পারে। আপনি যদি এটিই চান, শুধু তখন এটি চালু রাখুন।

identifier দিয়ে pin করলেও একটি ক্ষেত্রে সমস্যা থেকে যায়। যে kernel-এর নাম identifier-এ আছে, সেটি সরিয়ে ফেললে identifier আর resolve হয় না। তখন default হিসেবে প্রথম entry ব্যবহৃত হয়। তাই package-টিও hold করুন, অথবা সেই kernel-কে autoremove-এর আওতার বাইরে রাখুন।

Provider console-এ menu দেখানো

ইন্টার‌্যাক্টিভভাবে নির্বাচন করতে হলে screen-এ menu থাকতে হবে, কিন্তু cloud image-এ এটি আড়াল থাকে। এগুলো সর্বশেষ sort হওয়া file-এ রাখুন, তারপর sudo update-grub চালান।

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

GRUB_TIMEOUT_STYLE=hidden এবং GRUB_TIMEOUT=0 একসঙ্গে ব্যবহার করলে কিছুই দেখা যায় না। তাই console পর্যবেক্ষণকারী ব্যক্তি সঙ্গে সঙ্গে kernel message দেখা শুরু হতে দেখেন এবং ধরে নেন যে bootloader এড়িয়ে যাওয়া হয়েছে। boot সম্পূর্ণ না হলে পরে ব্যবহারের জন্য GRUB_RECORDFAIL_TIMEOUT আলাদা timeout নির্ধারণ করে। Cloud image-এ এটিও 0 সেট করা থাকে। তাই সদ্য boot করতে ব্যর্থ হওয়া server-ও থেমে আপনার অপেক্ষা করে না।

আপনার provider graphical console-এর বদলে serial console দিলে এবং তবুও কিছু না দেখলে, GRUB এমন terminal-এ লিখছে যা আপনি দেখতে পাচ্ছেন না। দুটি line একসঙ্গে যোগ করুন। প্রথমটি output নির্বাচন করে, আর দ্বিতীয়টি port configure করে:

GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

এখন থেকে প্রতিটি boot-এ 10 seconds যোগ হবে। কাজ শেষ হলে timeout আবার 0 সেট করুন।

বুটলোডার সম্পাদনার চেয়ে নিরাপদ বিকল্প

শুধু SSH-এর মাধ্যমে যে মেশিনে পৌঁছাতে পারেন, সেই মেশিনে bootloader-এর ইনপুট পরিবর্তন করা এই পৃষ্ঠার সবচেয়ে ঝুঁকিপূর্ণ বিকল্প। কম ঝুঁকির সমাধান আছে, এবং সেগুলো সাধারণত আসল সমস্যাটিই সমাধান করে।

Kernel package hold করুন। লক্ষ্য যদি হয় "আমাকে নতুন kernel দেবেন না", তাহলে bootloader-কে নয়, package manager-কে সেটি জানান।

apt list --installed 2>/dev/null | grep -E '^linux-(image|headers|generic|virtual|kvm|aws|azure|gcp|oracle)'
sudo apt-mark hold linux-image-virtual linux-headers-virtual
apt-mark showhold

প্রথম command যে নামগুলো দেখিয়েছে, সেগুলোই ব্যবহার করুন। কারণ cloud image-গুলোতে সাধারণত generic-এর পরিবর্তে virtual বা kvm flavour install করা থাকে। নতুন kernel যদি image refresh-এর সময় এসেছে এবং আপনার সন্দেহ হয় যে release-টি আপনার অজান্তে বদলে গেছে, তা হয়নি। কারণ point release হলো আপনার কাছে ইতিমধ্যে থাকা update-গুলো নতুন install media-তে একত্র করা সংস্করণ; তাই ইতিমধ্যে patch করা server-কে কয়েক সপ্তাহ আগে যেসব update দেওয়া হয়নি, point release সেটির বাইরে নতুন কিছু দেয় না। held package apt upgrade এড়িয়ে যায়, এবং The following packages have been kept back: দিয়ে সেটি এড়িয়ে যাওয়ার বিষয়টি জানায়। Ubuntu-র unattended upgrade-ও held package এড়িয়ে যায়। এর বাস্তব মূল্য আছে: held kernel security fix আর পায় না। তাই এটিকে নির্দিষ্ট তারিখসহ সাময়িক বিরতি হিসেবে বিবেচনা করুন এবং sudo apt-mark unhold দিয়ে hold তুলে দিন। একটি kernel খারাপ বলে নয়, reboot-এর কারণে downtime হয় বলে যদি kernel update এড়িয়ে চলেন, তাহলে VPS-এ live kernel patching তার সমাধান।

Upgrade-এর আগে snapshot নিন। Snapshot কয়েক মিনিটে restore করা যায়। এতে console-এ কিছু type করতে হয় না এবং bootloader-এর আংশিক প্রয়োগ করা পরিবর্তনের ঝুঁকিও থাকে না। Snapshot নিন, upgrade করুন, reboot করুন, তারপর যাচাই করুন। নতুন kernel ঠিকমতো কাজ না করলে rollback করুন। তখন boot path আগের মতোই থাকবে।

যে machine ইতিমধ্যে বন্ধ হয়ে গেছে, তার জন্য console বা rescue image ব্যবহার করুন। Server একবার boot না করলে bootloader configuration-এ সেটি ঠিক করবেন না। সেই recovery path-এর নিজস্ব procedure আছে: kernel update-এর পরে VPS boot না করলে কী করবেন।

কী নষ্ট হয় এবং আপনি কোন বার্তা দেখবেন

আপনার /boot/grub/grub.cfg-এ করা পরিবর্তনটি অদৃশ্য হয়ে গেছে। একটি kernel package ইনস্টল বা অপসারণ করা হয়েছে, তার maintainer script update-grub চালিয়েছে, এবং input থেকে file-টি পুনরায় তৈরি করেছে। # DO NOT EDIT THIS FILE header-এ দুটি input location-এর নাম থাকে। ওই location-গুলোতে পরিবর্তন করুন।

grub-editenv: error: environment block too small। /boot/grub/grubenv অনুপস্থিত বা অসম্পূর্ণ। sudo grub-editenv /boot/grub/grubenv create দিয়ে এটি পুনরায় তৈরি করুন। এরপর আপনার value আবার সেট করুন এবং sudo grub-editenv list দিয়ে নিশ্চিত করুন।

VFS: Unable to mount root fs on unknown-block(0,0) সহ pinned kernel panic করছে। আপনি যে entry pin করেছেন, সেটি এমন একটি kernel বা initrd নির্দেশ করছে যা আর disk-এ নেই। সাধারণত identifier-টি grubenv-এ থেকে গেলেও package অপসারণ করলে এমন হয়। Recovery হিসেবে console থেকে একটি কার্যকর entry boot করুন। এরপর পুরোনো value মুছে দিন।

পরিবর্তন হবে বলে আশা করা reboot-এর পরেও uname -r অপরিবর্তিত আছে। ক্রমানুসারে তিনটি বিষয় পরীক্ষা করুন: grub-editenv list-এ এখনও আপনার value দেখা যাচ্ছে, নাকি সেটি ব্যবহৃত হয়ে গেছে; আপনি যে identifier সেট করেছেন, সেটি বর্তমান grub.cfg-এ আছে কি না; grub.cfg-এ কি এমন একটি set default line আছে, যা আপনার সেট করা variable পড়ে। এই তিনটির একটিই প্রতিবার কারণটি ব্যাখ্যা করে।

Crash-এর পর menu নিজে থেকেই দেখা দিয়েছে। GRUB grubenv-এ ব্যর্থ boot-কে recordfail=1 হিসেবে record করে। এরপর পরবর্তী boot-এ menu দেখানো হয়, যাতে administrator হস্তক্ষেপ করতে পারেন। Machine স্বাভাবিক হলে sudo grub-editenv /boot/grub/grubenv unset recordfail দিয়ে এটি মুছে দিন।

মনে রাখার মতো মূল কথাটি হলো: আপনি যে file edit করেন, GRUB সেই file পড়ে না। Cloud image-এ এই দুই file-এর মধ্যকার পার্থক্যই বিভ্রান্তির মূল কারণ। প্রথমে generated config পড়ুন। এই পৃষ্ঠার প্রতিটি সিদ্ধান্ত config-এ বাস্তবে যা লেখা আছে, তার ওপর নির্ভর করে।

FAQ

GRUB_DEFAULT=1 পরিবর্তন করেও আমার VPS কেন কোন kernel দিয়ে boot হচ্ছে তা বদলায় না?

কারণ Ubuntu cloud image-এ তৈরি করা /boot/grub/grub.cfg-এ প্রায়ই একটি মাত্র boot entry থাকে। তাই index 1 কোনো entry-কে নির্দেশ করে না এবং GRUB প্রথম entry-তে fallback করে। sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg দিয়ে এটি নিশ্চিত করুন। count 1 হলে সেটিই উত্তর। এর কারণ হলো GRUB_FORCE_PARTUUID। image vendor /etc/default/grub.d/-এর একটি file-এ এটি সেট করে, ফলে generator ইনস্টল করা kernel-গুলোর পূর্ণ তালিকা তৈরি না করে direct boot path ব্যবহার করে। grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ দিয়ে file-টি খুঁজুন।

শুধু একবার আগের kernel দিয়ে কীভাবে boot করব?

আপনার নিজের grub.cfg থেকে identifier কপি করে sudo grub-reboot '<identifier>' চালান। এরপর provider console আগে থেকেই খোলা রেখে reboot করুন। boot করার আগে GRUB next_entry মুছে দেয়। তাই এই নির্বাচন ঠিক একবারের জন্য কার্যকর হয়, এবং panic করা kernel আবার চেষ্টা করা হয় না। sudo grub-editenv list দিয়ে value সঠিকভাবে সেট হয়েছে কি না নিশ্চিত করুন। এর ওপর নির্ভর করার আগে sudo grep -n next_entry /boot/grub/grub.cfg চালান। কারণ কোনো image-এর config-এ grubenv load না হলে command-টি কোনো error ছাড়াই উপেক্ষা করবে।

Entry number দিয়ে pin করা উচিত, নাকি identifier দিয়ে?

Identifier দিয়ে। Entry number হলো একটি তালিকার অবস্থান, যেটি 10_linux নতুন kernel আগে রেখে পুনর্নির্মাণ করে। তাই কোনো kernel install বা remove করলে entry number বদলে যায়। পুরোনো 1>2 সতর্কবার্তা ছাড়াই একটি বাস্তব কিন্তু ভুল entry-তে resolve হতে পারে। Identifier-এর মধ্যে kernel version থাকে। তাই এটি হয় আপনার নির্ধারিত kernel-এর সঙ্গে মিলে যাবে, নয়তো resolve হবে না। sudo grep -n menuentry_id_option /boot/grub/grub.cfg দিয়ে এগুলো তালিকাভুক্ত করুন এবং প্রতিটি entry line-এর পরের quoted string কপি করুন।

Bootloader পরিবর্তন করার চেয়ে kernel package hold করে রাখা কি নিরাপদ?

সাধারণ উদ্দেশ্যে, হ্যাঁ। sudo apt-mark hold linux-image-virtual linux-headers-virtual নতুন kernel আসাই বন্ধ করে দেয়। ফলে boot path পরিবর্তিত হয় না এবং এমন console থেকে ভুল করার ঝুঁকিও থাকে না, যেটিতে আপনার হয়তো access নেই। প্রথমে আপনার নিজের box-এ ইনস্টল করা flavour name-গুলো apt list --installed দিয়ে পরীক্ষা করুন। এরপর apt-mark showhold দিয়ে hold কার্যকর হয়েছে কি না নিশ্চিত করুন। এর বিনিময়ে held kernel কোনো security fix পায় না। তাই hold করার আগে কখন sudo apt-mark unhold চালাবেন তা নির্ধারণ করুন।