VPS-এ পরের boot-এর জন্য kernel pin করার নিরাপদ উপায়

আপনার VPS পরবর্তীবার কোন kernel চালু করবে তা কী নির্ধারণ করে

আপনার VPS পরবর্তীবার কোন kernel চালু করবে, তা একটি generated file, /boot/grub/grub.cfg, নির্ধারণ করে। এই file কখনও সরাসরি edit করবেন না। এর input file-গুলো edit করে সেটি পুনরায় generate করুন। Ubuntu cloud image-এ এই input file-গুলোর একটি 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 প্রয়োজন হতে পারে। তাই এই পৃষ্ঠার শেষের নিরাপদ পদ্ধতিগুলো অনুসরণ করুন। অনেক ক্ষেত্রে সেগুলোই সঠিক পছন্দ।

প্রথমে নিশ্চিত করুন, 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 করার মতো কিছু নেই। সে ক্ষেত্রে uname -r এমন একটি version দেখায়, যা /boot/vmlinuz-*-এ একেবারেই নেই। কারণ চলমান kernel host-এর এবং আপনার disk-এর কোনো setting সেটি পরিবর্তন করতে পারে না।

ls -1 /boot/vmlinuz-*-এ আপনি যে kernel-গুলোর মধ্যে বেছে নিতে পারেন, সেগুলোর প্রকৃত তালিকা থাকে। এতে যদি একটি মাত্র line থাকে, তাহলে আগের kernel ইতিমধ্যে মুছে ফেলা হয়েছে। কোনো bootloader setting সেটিকে ফিরিয়ে আনতে পারবে না। এটি সাধারণত autoremove-এর সময় ঘটে। আপনি গুরুত্বপূর্ণ কোনো box-এ 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 বের হয়।

আপনার সেটিং ওভাররাইড করে যা: /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 read হওয়ার পরে timeout ও kernel command line-এর মতো setting নির্ধারণ করে। /etc/default/grub-এ থাকা আপনার GRUB_TIMEOUT=10-কে কিছুক্ষণ পরেই একটি vendor file ওভাররাইড করে 0 নির্ধারণ করে। উপরের grep আপনার image-এ থাকা সঠিক assignment-গুলো দেখায়। তাই এই বাক্যের ওপর নির্ভর না করে সেগুলো পড়ুন।

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

কেন 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 এটি সেট করে, কারণ এতে যে hardware-এ image তৈরি করা হয়নি, সেখানেও একই disk image নির্ভরযোগ্যভাবে boot করতে পারে। দ্বিতীয় grep কমান্ডটি /etc/grub.d/10_linux-এ থাকা এই variable-এর কার্যকর code দেখায়। ওই script আপনার নিজের disk-এ রয়েছে। আপনার image কীভাবে কাজ করে, সে বিষয়ে সেটিই authoritative source।

এখানে ফলাফলটাই গুরুত্বপূর্ণ। এই path-এ 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 এটি resolve করতে পারে না। ফলে এটি প্রথম entry boot করে, আর সেটিই সেই নতুন kernel যেটি আপনি এড়াতে চেয়েছিলেন। grub-set-default-ও এতে সাহায্য করে না, কারণ সমস্যা default entry-তে নয়। আপনি যে মেনু থেকে নির্বাচন করতে চাইছেন, সেটি কখনো তৈরি হয়নি।

সম্পূর্ণ মেনু ফিরিয়ে আনতে vendor file-টি অন্যত্র সরিয়ে রাখুন এবং পরিবর্তন প্রয়োগের আগে ফলাফল preview করুন। grub-mkconfig-এ কোনো -o না থাকলে এটি 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-টি আগের জায়গায় ফিরিয়ে দিন। কারণ forced PARTUUID-ই আপনার provider-এর image-কে root filesystem খুঁজে পেতে সাহায্য করে। এটি সরিয়ে ফেললে মেশিনটি search path ব্যবহার করবে। বাস্তবে update-grub চালানোর আগে snapshot নিন।

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

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

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

Index স্থির থাকে না। 10_linux kernel-গুলোকে সর্বশেষটি আগে দেখায়। তাই একটি 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-এ define করা variable দেখায়। এরপর বাম পাশের অংশটি হলো reader যে title দেখেন। ডান পাশের অংশটি হলো tools-এ দেওয়া identifier। Submenu-এর ভেতরের কোনো entry-এর ক্ষেত্রে submenu identifier এবং entry identifier-কে > দিয়ে, numeric form-এর মতো একই ক্রমে, একত্র করুন।

grub-reboot দিয়ে আগের kernel একবার চালু করুন

Remote server-এ একবারের জন্য kernel নির্বাচন করাই সঠিক পদ্ধতি, কারণ এটি নিজে থেকেই আগের অবস্থায় ফিরে যায়। grub-reboot, /boot/grub/grubenv-এর মধ্যে next_entry লিখে। GRUB ওই variable পড়ে, সেটি clear করে, এবং যেকোনো কিছু boot করার আগেই clear করা value সংরক্ষণ করে। ফলে panic করা kernel পরের 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-এ এমন একটি next_entry= line দেখানো উচিত, যাতে আপনি যে value দিয়েছেন ঠিক সেটিই থাকে। Browser tab-এ provider-এর console খুলুন, তারপর reboot করে ফলাফল পরীক্ষা করুন।

sudo reboot

uname -r

uname -r-এ আগের version দেখালে বুঝবেন, pin কাজ করেছে। নতুন version দেখালে হয় identifier resolve হয়নি, নয়তো grubenv পড়া হচ্ছে না। উভয় ক্ষেত্রেই machine চালু হয়েছে, আর one shot 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-টির output অবশ্যই set default="${saved_entry}" হতে হবে। যদি set default="0" দেখা যায়, তাহলে আপনার file-এর পরে sourced হওয়া কোনো file GRUB_DEFAULT-কে আবার একটি literal value-তে সেট করেছে। তাই /etc/default/grub.d/ আবার তালিকাভুক্ত করুন এবং যাচাই করুন যে 99-local.cfg সত্যিই শেষে sort হচ্ছে।

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

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

প্রোভাইডারের কনসোলে মেনু দেখানো

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

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

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

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

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

এখন থেকে প্রতিটি boot-এ দশ সেকেন্ড যোগ হবে। কাজ শেষ হলে 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-এ সাধারণত virtual বা kvm flavour install হয়, generic নয়। hold করা package apt upgrade এড়িয়ে যায় এবং The following packages have been kept back: দিয়ে তা জানায়। Ubuntu-র unattended upgrades-এও package-টি এড়িয়ে যায়। এর খরচ আছে: hold করা kernel আর security fix পায় না। তাই এটিকে নির্দিষ্ট তারিখসহ সাময়িক বিরতি হিসেবে বিবেচনা করুন এবং sudo apt-mark unhold দিয়ে hold তুলে দিন। reboot-এর কারণে downtime হয় বলে kernel update এড়ালে, কোনো নির্দিষ্ট kernel খারাপ বলে নয়, তাহলে VPS-এ live kernel patching ব্যবহার করুন।

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

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

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

/boot/grub/grub.cfg-এ আপনার করা পরিবর্তন হারিয়ে গেছে। একটি kernel package ইনস্টল বা অপসারণ করা হয়েছে, তার maintainer script update-grub চালিয়েছে, এবং input থেকে ফাইলটি আবার তৈরি হয়েছে। # 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 দিয়ে এটি আবার তৈরি করুন। এরপর আপনার মানটি আবার সেট করে sudo grub-editenv list দিয়ে যাচাই করুন।

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

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

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

মনে রাখার মতো একমাত্র বাক্যটি হলো: আপনি যে ফাইল সম্পাদনা করেন, GRUB সেই ফাইলটি পড়ে না। একটি cloud image-এ এই দুই ফাইলের মধ্যকার ব্যবধানেই বিভ্রান্তির মূল কারণ থাকে। প্রথমে 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 দিয়ে এটি নিশ্চিত করুন। ফলাফল 1 হলে সেটিই কারণ। এর কারণ হলো GRUB_FORCE_PARTUUID। image vendor এটি /etc/default/grub.d/-এর অধীনে একটি file-এ সেট করে। এর ফলে generator ইনস্টল করা kernel-গুলোর পূর্ণ তালিকা তৈরি না করে সরাসরি 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 হয় না, কোনো error ছাড়াই এই command উপেক্ষা করবে।

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

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

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

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