Ubuntu 24.04 থেকে 26.04 আপগ্রেড করার সঠিক নিয়ম

কখন আপনি Ubuntu 24.04 থেকে 26.04-এ আপগ্রেড করতে পারবেন?

আপনি একটি VPS-এ Ubuntu 24.04 থেকে 26.04-এ আপগ্রেড করতে পারবেন যখন 26.04.1 point release বাজারে আসবে, যা 27 আগস্ট 2026 তারিখে নির্ধারিত। ততক্ষণ পর্যন্ত একটি 24.04 সার্ভার নতুন রিলিজটি দেখতে পাবে না, এটি ইচ্ছাকৃতভাবেই করা হয়েছে। Ubuntu 26.04 LTS (Resolute Raccoon) 23 এপ্রিল 2026 তারিখে রিলিজ হয়েছিল, কিন্তু Canonical শুধুমাত্র প্রথম point release-এর সময় LTS থেকে LTS আপগ্রেড পাথ উন্মুক্ত করে। কারণ এই রিলিজটিতে প্রথম কয়েক মাসে পাওয়া ইনস্টলেশন এবং আপগ্রেড সংক্রান্ত বাগগুলো সমাধান করা থাকে। যদি এই নম্বর পদ্ধতি আপনার কাছে নতুন মনে হয়, তবে 26.04.1 আলাদা কোনো Ubuntu নয়, বরং এটি একই 26.04 যার সাথে চার মাসের ফিক্সগুলো যুক্ত করা হয়েছে, এবং ঠিক এই কারণেই এটি প্রথম সংস্করণ যা Canonical বিদ্যমান কোনো সার্ভারের জন্য প্রদান করবে।

2026 সালের আগস্টের শুরুতে একটি 24.04 বক্সে চেক রান করলে আপনি এটি পাবেন:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

এটি আপনার সার্ভারের কোনো ত্রুটি নয়। /etc/update-manager/release-upgrades-এ Ubuntu Server-এর জন্য Prompt=lts থাকে, যার অর্থ হলো টুলটি শুধুমাত্র পরবর্তী long term support রিলিজটি অফার করে এবং সেটিও শুধুমাত্র তখনই যখন এর .1 point release বিদ্যমান থাকে। Prompt=normal সেট করলে বরং আপনাকে পর্যায়ক্রমে 24.10, 25.04 এবং 25.10-এর মধ্য দিয়ে যেতে হবে, যা অন্তর্বর্তীকালীন রিলিজ এবং এগুলোর মেয়াদ শেষ হয়ে গেছে। এটিকে lts-এ রাখুন এবং অপেক্ষা করুন। Canonical-এর সময়সূচীর তারিখ পরিবর্তিত হতে পারে, তাই দিনটি পার হয়ে গেলে পুনরায় চেক করুন। 22.04-এ থাকা একটি সার্ভার সরাসরি এই জাম্পটি করতে পারে না, কারণ আপগ্রেডার সবসময় শুধুমাত্র পরবর্তী LTS অফার করে। তাই 24.04-এর মাধ্যমে 22.04 থেকে 26.04-এ আপগ্রেড করার প্রক্রিয়াটি প্রথম ধাপ এবং দ্বিতীয় ধাপের আগে নেওয়া স্ন্যাপশটটি কভার করে।

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

আপনার কি আদৌ আপগ্রেড করা উচিত?

Ubuntu 24.04-এ 2029 সাল পর্যন্ত স্ট্যান্ডার্ড সিকিউরিটি আপডেট পাওয়া যাবে, তাই একটি সচল প্রোডাকশন সার্ভারের জন্য কোনো সময়সীমা নেই। আপগ্রেড তখনই করুন যদি আপনার এমন কোনো ফিচারের প্রয়োজন হয় যা 26.04-এ রয়েছে: যেমন PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 অথবা 7.0 কার্নেল। শুধুমাত্র "ভার্সন নম্বর বেড়েছে" এই কারণে গ্রাহক সেবা প্রদানকারী কোনো মেশিনে হাত দেওয়া উচিত নয়।

নিচের কোনো একটি সত্য হলে ইন-প্লেস (in-place) আপগ্রেড করবেন না:

• আপনি কখনো আপনার প্রোভাইডারের কনসোল (VNC বা সিরিয়াল) খুলে তাতে লগ-ইন করেননি। SSH ভেঙে গেলে সার্ভারে ঢোকার একমাত্র উপায় হলো এই কনসোল, আর আপনি যখন সার্ভার থেকে লকড-আউট হয়ে যাবেন তখন এটি কাজ না করলে তা ঠিক করার জন্য অনেক দেরি হয়ে যাবে।
• আপনার এক ঘণ্টা ডাউনটাইম সহ্য করার ক্ষমতা নেই এবং আপনার কাছে কোনো রোলব্যাক (rollback) পরিকল্পনা নেই।
• আপনার স্ট্যাক এমন কোনো থার্ড-পার্টি রিপোজিটরির ওপর নির্ভরশীল যা এখনো resolute-এর জন্য প্রকাশিত হয়নি।
• সার্ভারটি দুই বছর ধরে হাতে তৈরি করা হয়েছে এবং এতে কী কী আছে তা কারো জানা নেই।

বিকল্প পদ্ধতিটি প্রায়ই বেশি কার্যকর: একটি নতুন 26.04 VPS তৈরি করুন, আপনার স্ট্যাক ইনস্টল করুন এবং ডেটা রিস্টোর করুন, তারপর নতুন সার্ভার সঠিকভাবে কাজ করলে DNS পরিবর্তন করে দিন। নতুন সার্ভারটি নিজেকে প্রমাণ না করা পর্যন্ত আপনি পুরনো সার্ভারটি চালু রাখতে পারেন এবং এক্ষেত্রে রোলব্যাক করার অর্থ হলো শুধুমাত্র একটি DNS পরিবর্তন করা, কোনো রিস্টোর করার প্রয়োজন নেই। আপনি যদি এই পথে যেতে চান, তবে নতুন VPS-এ প্রথম দশ মিনিট দিয়ে শুরু করুন এবং নতুন বক্সটি সঠিকভাবে তৈরি করুন।

ধাপ 1: এমন একটি ব্যাকআপ নিন যা থেকে আপনি রিস্টোর করতে পারবেন

দুটি স্তরের ব্যাকআপ ব্যবহার করুন, কারণ এগুলোর ব্যর্থ হওয়ার ধরন ভিন্ন। প্রোভাইডার স্ন্যাপশট পুরো ডিস্ক কভার করে এবং কয়েক মিনিটের মধ্যে রিস্টোর করা যায়, কিন্তু এটি নেওয়ার সময় আপনার ডাটাবেসগুলো রাইট মোডে থাকে, তাই এটি অ্যাপ্লিকেশন কনসিস্টেন্ট হওয়ার চেয়ে ক্র্যাশ কনসিস্টেন্ট বেশি। restic, সার্ভারের বাইরে সংরক্ষিত ফাইল-লেভেল ব্যাকআপ আপনাকে একক ফাইল রিস্টোর করার সুবিধা দেয় এবং আপনার অ্যাকাউন্ট লক হয়ে গেলেও এই কপিটি সুরক্ষিত থাকে।

প্রথমে ডাটাবেসগুলো ম্যানুয়ালি ডাম্প করুন। ডাটাবেস বন্ধ না করে বিশ্বাসযোগ্য ব্যাকআপ পাওয়ার একমাত্র উপায় হলো ডাম্প নেওয়া।

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction শুধুমাত্র InnoDB টেবিলের জন্য কনসিস্টেন্ট ডাম্প প্রদান করে। MyISAM টেবিলের ক্ষেত্রে ডাটাবেস বন্ধ রাখা প্রয়োজন। /etc টারবলটিই আপনার সবচেয়ে বেশি কাজে আসবে, কারণ আপগ্রেডের সময় যেসব কনফিগারেশন ফাইল সম্পর্কে আপনাকে প্রশ্ন করা হবে, তার সবগুলোই এতে থাকে।

যে ব্যাকআপ আপনি কখনো রিস্টোর করে দেখেননি, তা কেবল একটি অনুমান। চাপের মুখে পড়ার আগেই এখনই ব্যাকআপ থেকে একটি ফাইল বের করে পরীক্ষা করুন।

ধাপ 2: প্রথমে 24.04 সম্পূর্ণ প্যাচ করুন

do-release-upgrade এমন সিস্টেমে চলতে অস্বীকার করে যেখানে প্যাকেজের অবস্থা অসম্পূর্ণ, এবং অর্ধেক প্যাচ করা 24.04 পরবর্তী যেকোনো ত্রুটিকে শনাক্ত করা কঠিন করে তোলে।

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit কোনো আউটপুট না আসা মানে কোনো প্যাকেজ অর্ধেক কনফিগার করা নেই। apt-mark showhold কোনো আউটপুট না আসা মানে এমন কোনো প্যাকেজ নেই যা আপগ্রেড আটকে দিতে পারে। যদি কোনো প্যাকেজের নাম দেখায়, তবে sudo apt-mark unhold এবং প্যাকেজের নাম ব্যবহার করে সেটিকে রিলিজ করুন, অথবা ধরে নিন যে এই হোল্ডটি কোনো নির্দিষ্ট কারণে রাখা হয়েছে এবং এখানেই কাজ থামিয়ে দিন।

কার্নেল পরিবর্তিত হলে রিবুট করুন, যাতে আপনি এমন একটি মেশিন থেকে আপগ্রেড করতে পারেন যা বর্তমানে চলমান কোডটিই ব্যবহার করছে।

[ -f /var/run/reboot-required ] && sudo reboot

এরপর ডিস্কের জায়গা পরীক্ষা করুন। আপগ্রেডার কোনো কিছু ইনস্টল করার আগেই নতুন প্যাকেজ সেটটি সম্পূর্ণ ডাউনলোড করে, এবং পর্যাপ্ত জায়গা না থাকলে ফাইলসিস্টেমের নাম উল্লেখ করে কাজ বন্ধ করে দেয়।

df -h / /boot

/-এ 5 জিবি-র কম জায়গা থাকলে সমস্যা হতে পারে। /boot-এ 300 এমবি-র কম জায়গা থাকলে কার্নেল ইনস্টলের সময় No space left on device ত্রুটি দেখা দেয়। সাধারণত পুরনো কার্নেলের কারণে এমন হয়, এবং sudo apt --purge autoremove সেগুলো মুছে ফেলে জায়গা খালি করে।

শুরু করার আগে আরও একটি বিষয় খেয়াল রাখুন: যদি স্বয়ংক্রিয় নিরাপত্তা আপডেট চলাকালীন কোনো আপডেট শুরু হয়, তবে তা dpkg লক ধরে রাখে এবং রিলিজ আপগ্রেডার Could not get lock /var/lib/dpkg/lock-frontend ত্রুটি দেখিয়ে বন্ধ হয়ে যায়। প্রথমে sudo systemctl stop unattended-upgrades চালান এবং কাজ শেষ হলে পুনরায় শুরু করুন।

ধাপ 3: থার্ড-পার্টি রিপোজিটরি এবং পিন করা প্যাকেজগুলো পরীক্ষা করুন

do-release-upgrade উবুন্টু নয় এমন প্রতিটি apt সোর্সকে নিষ্ক্রিয় করে দেয়, কারণ noble-এর জন্য তৈরি কোনো প্যাকেজ resolute সিস্টেমকে অকেজো করে দিতে পারে। এটি পরবর্তীতে পরিচিত সোর্সগুলোকে পুনরায় সক্রিয় করে এবং বাকিগুলোকে কমেন্ট আউট করে রাখে। টুলটি আপনার হয়ে সিদ্ধান্ত নেওয়ার আগেই জেনে নিন আপনি কী ব্যবহার করছেন।

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

উবুন্টু 24.04 এই ডিরেক্টরিতে দুটি ফরম্যাট ব্যবহার করে: পুরনো এক লাইনের .list ফাইল এবং Types: ও Suites: ফিল্ডসহ deb822 .sources ফাইল। আপগ্রেডের সময় উভয়ই নিষ্ক্রিয় হয়ে যায়। /etc/apt/preferences.d/-এ যা কিছু আছে তা হলো একটি পিন, এবং noble-এর জন্য লেখা একটি পিন নতুন রিলিজেও পুরনো প্যাকেজ নির্বাচন করতে থাকবে। ubuntu-security-status --thirdparty সেই ইনস্টল করা প্যাকেজগুলোর তালিকা দেখায় যা কোনো উবুন্টু আর্কাইভ প্রদান করে না, যা আপনার সিস্টেমে যুক্ত করা অতিরিক্ত প্যাকেজের সঠিক সংখ্যা।

প্রতিটি থার্ড-পার্টি রিপোজিটরির জন্য, কাজ শুরু করার আগে নিশ্চিত করুন যে ভেন্ডর নতুন কোডনেমের জন্য প্যাকেজ প্রকাশ করেছে। Docker-এর স্যুটগুলো https://download.docker.com/linux/ubuntu/dists/-এ তালিকাভুক্ত থাকে এবং অন্যান্য ভেন্ডররাও একই ডিরেক্টরি ব্যবহার করে। এমন কোনো স্যুটের দিকে নির্দেশ করা সোর্স যা অস্তিত্বহীন, তা আপগ্রেডের পর প্রথম apt update-এ নিচের ত্রুটিটি দেখাবে:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

ভেন্ডর নতুন প্যাকেজ প্রকাশ না করা পর্যন্ত সেই সোর্সটিকে নিষ্ক্রিয় রাখুন। ভেন্ডর যে কোডনেমের জন্য বিল্ড করেছে, সেই কোডনেমে এডিট করা মানেই হলো ভুল সিস্টেম লাইব্রেরির সাথে লিঙ্ক করা প্যাকেজ ইনস্টল করা।

ধাপ 4: সাধারণ SSH শেল-এর পরিবর্তে tmux-এ আপগ্রেড চালান

যদি সাধারণ লগইন শেলে do-release-upgrade চলার সময় আপনার সংযোগ বিচ্ছিন্ন হয়ে যায়, তবে প্রসেসটি SIGHUP সিগন্যাল পায় এবং আনপ্যাকিং-এর মাঝপথে বন্ধ হয়ে যায়। এর ফলে dpkg অর্ধেক কনফিগার করা অবস্থায় থেকে যায় এবং সার্ভারের নেটওয়ার্ক স্ট্যাক অকেজো হয়ে যেতে পারে, যার ফলে পুনরায় সংযোগ করা অসম্ভব হয়ে পড়ে। তাই এটি একটি টার্মিনাল মাল্টিপ্লেক্সারের ভেতরে চালান, যাতে আপনার ক্লায়েন্ট ডিসকানেক্ট হলেও সার্ভারে প্রসেসটি সচল থাকে।

sudo apt install -y tmux
tmux new -s upgrade

সেই সেশনের ভেতরে:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

আপগ্রেডার কোনো কিছু পরিবর্তন করার আগেই 1022 পোর্টে দ্বিতীয় একটি SSH ডেমোন চালু করে এবং তা জানিয়ে দেয়:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

এটি আপনার ফায়ারওয়ালে সেই পোর্টের জন্য কোনো রুল তৈরি করে না, কারণ অনুমতি ছাড়া ফায়ারওয়ালে ছিদ্র করা একটি ঝুঁকিপূর্ণ কাজ। শুরু করার আগে নিজেই 1022 পোর্টটি খুলে নিন এবং sudo ufw delete allow 1022/tcp এর কাজ শেষ হলে তা বন্ধ করে দিন। মনে রাখবেন, আপনার প্রোভাইডার সার্ভারের বাইরে তাদের কন্ট্রোল প্যানেলে আলাদা একটি ফায়ারওয়াল চালাতে পারে।

যদি সংযোগ বিচ্ছিন্ন হয়েই যায়, তবে পুনরায় লগইন করুন এবং tmux attach -t upgrade চালান। আপনার অনুপস্থিতিতেও আপগ্রেড প্রক্রিয়া চলতে থাকবে। যদি তা না হয় এবং আপনি অর্ধেক কনফিগার করা dpkg বা আংশিক noble ও আংশিক resolute যুক্ত apt সোর্সের সম্মুখীন হন, তবে ব্যর্থ রিলিজ আপগ্রেড পুনরুদ্ধার অংশে প্যাকেজের অবস্থা ঠিক করা এবং কখন মেরামত বন্ধ করে স্ন্যাপশট থেকে রিস্টোর করতে হবে তা আলোচনা করা হয়েছে।

ধাপ 5: কনফিগারেশন ফাইলের প্রম্পটগুলো সতর্কতার সাথে উত্তর দিন

dpkg শুধুমাত্র সেই ফাইলগুলোর জন্যই প্রম্পট দেখায় যেগুলো আপনি বা কোনো স্ক্রিপ্ট পরিবর্তন করেছেন। তাই প্রতিটি প্রম্পটই এমন একটি ফাইল যা আপনি উদ্দেশ্যমূলকভাবে এডিট করেছেন। এন্টার চেপে প্রম্পট এড়িয়ে যাওয়া মানে হলো একটি হার্ডেনড সার্ভারকে নীরবে ডিফল্ট কনফিগারেশনে ফিরিয়ে নেওয়া।

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

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

আপনার ফাইলটি রেখে দেওয়ার একটি অসুবিধা আছে: আপনি নতুন ডিফল্ট সেটিংসগুলো পাবেন না। সিস্টেম আপ হওয়ার পর এবং তাড়াহুড়ো না থাকলে পরবর্তীতে সেগুলো মিলিয়ে নিন।

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

তালিকাভুক্ত প্রতিটি ফাইল হলো মেইনটেইনারের ভার্সন, যা আপনার ফাইলের পাশেই সেভ করা থাকে। একটি একটি করে ফাইল Diff করুন এবং প্রয়োজনীয় সেটিংসগুলো কপি করে নিন। দুটি ফাইলের ক্ষেত্রে বাড়তি সতর্কতা অবলম্বন করুন: /etc/ssh/sshd_config, কারণ ভুল উত্তর দিলে আপনার সেশন বিচ্ছিন্ন হয়ে যাবে; এবং আপনার ওয়েব সার্ভার কনফিগারেশন, কারণ ভুল উত্তরের ফলে সাইটগুলো ডাউন হয়ে যেতে পারে।

আপগ্রেডের সময় needrestart-এর মাধ্যমে জানতে চাওয়া হয় কোন সার্ভিসগুলো রিস্টার্ট করতে হবে। সম্পূর্ণ তালিকাটি গ্রহণ করুন। কোনো ডেমোন যদি এমন কোনো শেয়ারড লাইব্রেরি ফাইল ব্যবহার করতে থাকে যা ডিস্ক থেকে মুছে ফেলা হয়েছে, তবে পরবর্তীতে কোনো এক সময় সেটি ক্র্যাশ করবে, যখন আপনি হয়তো বিষয়টি খেয়াল করছেন না।

ধাপ 6: রিবুট করুন, তারপর মেশিনটি পরীক্ষা করুন

sudo reboot

মেশিনটি চালু হওয়ার পর:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a কমান্ডটি Release: 26.04 এবং Codename: resolute রিপোর্ট করবে। uname -r কমান্ডে 7.0 কার্নেল দেখানো উচিত। systemctl --failed কমান্ডে কোনো ইউনিট তালিকাভুক্ত হওয়া উচিত নয়; যদি কিছু দেখায়, তবে সেটিই আপনার পরবর্তী কাজ। সবশেষে apt update কমান্ডটি রিলিজ ইমেজ তৈরির পর প্রকাশিত আপডেটগুলো সংগ্রহ করবে।

PostgreSQL 16 থেকে 18: যে ক্লাস্টারটি নীরবে পেছনে পড়ে থাকে

Ubuntu 24.04-এ PostgreSQL 16 এবং 26.04-এ PostgreSQL 18 থাকে। আপগ্রেড করার সময় এটি 16-এর পাশাপাশি 18 ইনস্টল করে, কিন্তু আপনার ডেটা স্থানান্তর করে না। Debian-এর postgresql-common লেয়ার নতুন মেজর ভার্সনের জন্য পরবর্তী খালি পোর্টে একটি নতুন ক্লাস্টার তৈরি করে। ফলে 16 আগের মতোই 5432 পোর্টে আপনার সমস্ত ডেটা নিয়ে সচল থাকে এবং 18 খালি অবস্থায় 5433 পোর্টে বসে থাকে। আপনার অ্যাপ্লিকেশন 5432 পোর্টের সাথেই যোগাযোগ চালিয়ে যায় এবং কোনো সমস্যা ধরা পড়ে না, যে কারণে ব্যবহারকারীরা কয়েক মাস পর এটি লক্ষ্য করেন।

pg_lsclusters

দুটি ক্লাস্টার তালিকাভুক্ত থাকার অর্থ হলো আপনি মাইগ্রেশন সম্পন্ন করেননি। অ্যাপ্লিকেশন বন্ধ করার সুযোগ থাকলে নিচের কাজটি করুন:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

প্রথমে খালি 18 ক্লাস্টারটি ড্রপ করুন, কারণ pg_upgradecluster বিদ্যমান কোনো টার্গেট ক্লাস্টারে ডেটা লেখে না। ডিফল্ট পদ্ধতিতে 16-এর ডাম্প নিয়ে 18-এ রিলোড করা হয়, তাই আপনার ডেটাবেসের আকারের সমান খালি ডিস্ক স্পেস প্রয়োজন। -m upgrade এক্ষেত্রে pg_upgrade ব্যবহার করে, যা বড় ডেটাবেসের ক্ষেত্রে অনেক দ্রুত কাজ করে। এটি শেষ হলে Port কলামটি দেখুন: নতুন ক্লাস্টারটি 5432 পোর্ট গ্রহণ করে এবং পুরনোটি বন্ধ অবস্থায় পড়ে থাকে। নিজে থেকে analyze পাসটি চালান, কারণ নতুন লোড হওয়া ক্লাস্টারে কোনো পরিসংখ্যান থাকে না এবং প্রথম দিকের কুয়েরিগুলো ধীরগতির হতে পারে।

নতুন ক্লাস্টারের সাথে কয়েক দিন অ্যাপ্লিকেশনটি পরীক্ষা করুন। এরপরই পুরনোটি মুছে ফেলুন:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

পুরনো ক্লাস্টারের ডেটা ডিরেক্টরি হলো আপনার কাছে থাকা দ্রুততম রোলব্যাক ব্যবস্থা। আপগ্রেডের দিনই এটি মুছে ফেলবেন না।

MySQL 8.0 থেকে 8.4: যে অপশনটি সরিয়ে ফেলায় সার্ভার চালু হচ্ছে না

26.04 ভার্সনে MySQL-কে 8.0 থেকে 8.4 LTS-এ উন্নীত করা হয়েছে, এবং দুটি পরিবর্তনের কারণে সার্ভারে সমস্যা হতে পারে।

প্রথমত, কনফিগারেশন ফাইলে নতুন ভার্সনে সরিয়ে ফেলা কোনো অপশন থাকলে mysqld চালু হতে অস্বীকার করে। default_authentication_plugin এক্ষেত্রে সবচেয়ে সাধারণ সমস্যা, কারণ অনেক পুরনো গাইডে এটি সেট করার পরামর্শ দেওয়া হয়েছে। সার্ভিসটি ব্যর্থ হয় এবং journalctl -u mysql -n 50 সরাসরি অজানা ভেরিয়েবলটির নাম উল্লেখ করে। /etc/mysql/mysql.conf.d/-এর অধীনে থাকা ফাইল থেকে সেই লাইনটি মুছে ফেলুন, তারপর sudo systemctl start mysql করুন।

দ্বিতীয়ত, 8.4 ভার্সনে mysql_native_password প্লাগইনটি ডিফল্টভাবে সক্রিয় থাকে না, তাই যে অ্যাকাউন্টগুলো এখনও এটি ব্যবহার করছে তারা লগইন করতে পারে না। 8.0 ভার্সনে থাকাকালীনই এটি পরীক্ষা করুন:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

আপগ্রেড করার আগেই mysql_native_password প্রদর্শনকারী প্রতিটি অ্যাকাউন্ট পরিবর্তন করুন, তারপর আপনার অ্যাপ্লিকেশন কনফিগারেশনে পাসওয়ার্ড আপডেট করুন:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

যদি কোনো ক্লায়েন্ট লাইব্রেরি caching_sha2_password সমর্থন করার মতো যথেষ্ট আধুনিক না হয়, তবে আপনি [mysqld]-এর অধীনে mysql_native_password=ON যোগ করে 8.4 ভার্সনে পুরনো প্লাগইনটি পুনরায় চালু করতে পারেন। এটিকে একটি সাময়িক সমাধান হিসেবে বিবেচনা করুন, কারণ এই প্লাগইনটি পুরোপুরি সরিয়ে ফেলার প্রক্রিয়া চলছে।

PHP 8.3 থেকে 8.5: আপনার vhost এমন একটি সকেটের দিকে নির্দেশ করছে যা এখন আর নেই

24.04 ভার্সনে PHP 8.3 এবং 26.04 ভার্সনে PHP 8.5 থাকে। প্যাকেজগুলো ভার্সন-ভিত্তিক পাথে ইনস্টল হয় এবং কোনো কিছুই আপনার ওয়েব সার্ভারের কনফিগারেশন স্বয়ংক্রিয়ভাবে পরিবর্তন করে না। একটি nginx vhost যাতে fastcgi_pass unix:/run/php/php8.3-fpm.sock; রয়েছে, তা এখন এমন একটি সকেটের দিকে নির্দেশ করছে যা কোনো প্রসেস তৈরি করছে না। ফলে প্রতিটি PHP রিকোয়েস্ট 502 এরর দেয় এবং nginx এরর লগে নিচের বার্তাটি দেখা যায়:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

এটিকে নতুন সকেটের দিকে নির্দেশ করুন, কনফিগারেশন পরীক্ষা করুন এবং রিলোড করুন:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Apache-তে mod_php ব্যবহারের ক্ষেত্রে লক্ষণ ভিন্ন: Apache মোটেও চালু হবে না এবং sudo apache2ctl -t রিপোর্ট করবে যে এটি libphp8.3.so লোড করতে পারছে না কারণ ফাইলটির অস্তিত্ব নেই। এনাবল করা মডিউলটি এমন একটি প্যাকেজের সিমলিঙ্ক যা এখন আর নেই।

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

আপনি যদি Ubuntu 24.04-এ একটি LAMP stack থেকে সার্ভারটি তৈরি করে থাকেন, তবে উভয় পাথই চেক করা জরুরি, কারণ সেই গাইডে ভার্সন-ভিত্তিক মডিউল নাম এবং ভার্সন-ভিত্তিক সকেট ব্যবহার করা হয়েছিল।

আপনার php.ini টিউনিংও নিজে থেকে স্থানান্তরিত হয় না। memory_limit, upload_max_filesize এবং অন্যান্য যা কিছু আপনি সেট করেছিলেন তা /etc/php/8.3/-এ থাকে, এবং নতুন ভার্সনে সবকিছু ডিফল্ট থেকে শুরু হয়। দুটি ফাইলের মধ্যে পার্থক্য (diff) দেখুন এবং মানগুলো হাতে কপি করুন। পুরো পুরনো ফাইলটি নতুনটির ওপর কপি করলে 8.3-এর ডিফল্ট সেটিংস 8.5 ইনস্টলে চলে আসবে। এরপর php -m চালান এবং তুলনা করুন: php8.3-redis হিসেবে ইনস্টল করা কোনো এক্সটেনশনের জন্য এর php8.5- প্যাকেজ প্রয়োজন, এবং যদি এটি কোনো PPA থেকে এসে থাকে, তবে আপগ্রেডার সেই সোর্সটি ডিজেবল করে দিয়েছে এবং এক্সটেনশনটি এখন আর নেই।

সার্টিফিকেটগুলো আলাদাভাবে একবার চেক করা প্রয়োজন। আপগ্রেডের পর sudo certbot renew --dry-run চালান। এটি লাইভ সার্টিফিকেট স্পর্শ না করেই ওয়েব সার্ভার রিলোড হুকসহ পুরো রিনিউয়াল প্রক্রিয়াটি পরীক্ষা করে। কোনো হুক যদি এমন কোনো সার্ভিস নাম বা বাইনারিকে কল করে যা পরিবর্তিত হয়েছে, তবে তা 60 দিন পর নীরবে ব্যর্থ হওয়ার পরিবর্তে এখনই আপনার সামনে ধরা পড়বে। nginx-এ Let's Encrypt সহ Certbot গাইডে এই হুকগুলো কেমন হওয়া উচিত তা আলোচনা করা হয়েছে।

SSH: যে ব্যর্থতা আপনার বর্তমান সেশনটি বন্ধ করে দেয়

sshd_config প্রম্পটটি হলো সেই জায়গা যেখানে মানুষ নিজেদের লক-আউট করে ফেলে। Y-এর উত্তর দিলে তা মেইনটেইনারের ফাইলটি ইনস্টল করে, যা আপনার PermitRootLogin, PasswordAuthentication, AllowUsers, Port এবং আপনার যোগ করা অন্য সব লাইন মুছে ফেলে। যদি আপনার ফায়ারওয়াল শুধুমাত্র একটি কাস্টম পোর্ট অনুমোদন করে এবং প্যাকেজ করা কনফিগারেশনটি 22 পোর্টে লিসেন করে, তবে পরবর্তী সংযোগটি প্রত্যাখ্যান করা হবে এবং আপনি বর্তমানে যে সেশনে আছেন সেটিই হবে আপনার শেষ সেশন।

আপগ্রেড করার আগেই এটি প্রতিরোধ করুন। 24.04-এ /etc/ssh/sshd_config শুরু হয় Include /etc/ssh/sshd_config.d/*.conf দিয়ে, এবং OpenSSH প্রতিটি সেটিংসের জন্য প্রথম যে মানটি পায় সেটিই গ্রহণ করে, তাই শুরুতে থাকা একটি ড্রপ-ইন ফাইল নিচের যেকোনো সেটিংসের চেয়ে বেশি কার্যকর হয়। আপনার সেটিংসগুলো এমন একটি ফাইলে সরিয়ে নিন যা dpkg-এর মালিকানাধীন নয়:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

একবার /etc/ssh/sshd_config-এ আপনার নিজস্ব কিছু না থাকলে, সেই প্রম্পটটি আর গুরুত্বপূর্ণ থাকে না: যেকোনো উত্তরের ক্ষেত্রেই আপনার সেটিংসগুলো অক্ষত থাকবে, কারণ সেগুলো অন্য একটি ফাইলে সংরক্ষিত থাকে।

একটি কাস্টম পোর্টের জন্য আরও একটি পরীক্ষা প্রয়োজন, কারণ এটি আপনার ধারণার জায়গায় নাও থাকতে পারে:

systemctl is-enabled ssh.socket

যদি এটি enabled প্রিন্ট করে, তবে systemd লিসেনিং পোর্টটি নিয়ন্ত্রণ করছে এবং sshd_config-এর Port লাইনটি উপেক্ষা করা হচ্ছে। Ubuntu 22.10 থেকে sshd-এর জন্য socket activation ব্যবহার করছে, এবং এই কারণেই Port 2222 এডিট করলে কোনো পরিবর্তন দেখা যায় না। এর পরিবর্তে sudo systemctl edit ssh.socket ব্যবহার করে সকেট ইউনিটে এটি সেট করুন:

[Socket]
ListenStream=
ListenStream=2222

খালি ListenStream= থাকা আবশ্যক। এটি উত্তরাধিকারসূত্রে প্রাপ্ত মানটি মুছে ফেলে, এবং এটি ছাড়া সকেটটি 22 এবং 2222 উভয় পোর্টেই লিসেন করবে। sudo systemctl daemon-reload && sudo systemctl restart ssh.socket দিয়ে এটি প্রয়োগ করুন।

আপগ্রেডের পরে, আপনার বর্তমান সেশনটি বন্ধ করার আগে:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

এরপর আপনার নিজের মেশিনে একটি দ্বিতীয় টার্মিনাল খুলুন এবং পুনরায় লগ ইন করুন। সেই দ্বিতীয় টার্মিনালে একটি কার্যকর শেল পাওয়াটাই একমাত্র প্রমাণ যা গণ্য হয়। যতক্ষণ না আপনি এটি পাচ্ছেন, ততক্ষণ প্রথম সেশনটি খোলা রাখুন। Hardening SSH on a VPS-এ সেই ড্রপ-ইন ফাইলে রাখা প্রয়োজনীয় সেটিংসগুলো নিয়ে আলোচনা করা হয়েছে।

যদি ইতিমধ্যে অনেক দেরি হয়ে গিয়ে থাকে, তবে আপনার প্রোভাইডারের ওয়েব কনসোল আপনাকে এমন একটি লগইন দেয় যা SSH ব্যবহার করে না। সেখানে লগ ইন করুন, কনফিগারেশন ঠিক করুন, sudo sshd -t চালান এবং সার্ভিসটি রিস্টার্ট করুন। সেই কনসোলটিই হলো কারণ যার জন্য আপগ্রেডের সময় নয়, বরং তার আগেই কনসোল অ্যাক্সেস পরীক্ষা করে নেওয়া উচিত।

FAQ

Ubuntu 24.04-এ do-release-upgrade কেন "No new release found" বলে?

কারণ /etc/update-manager/release-upgrades-এ Prompt=lts সেট করা থাকে, যা শুধুমাত্র প্রথম point release আসার পরেই পরবর্তী long term support রিলিজের প্রস্তাব দেয়। Ubuntu 26.04 LTS রিলিজ হয়েছে 23 এপ্রিল 2026 তারিখে এবং 26.04.1 রিলিজ হওয়ার কথা 27 আগস্ট 2026 তারিখে। সেই তারিখ পর্যন্ত, একটি 24.04 সার্ভার নতুন কোনো রিলিজ খুঁজে পাবে না। এই সেটিং পরিবর্তন করে Prompt=normal করবেন না, কারণ এটি আপনাকে interim রিলিজগুলোর মাধ্যমে আপডেট করতে বাধ্য করবে।

আপগ্রেড শেষ করতে কি সার্ভার রিবুট করা বাধ্যতামূলক?

হ্যাঁ। আপগ্রেড প্রক্রিয়ায় নতুন kernel, নতুন C library এবং নতুন init system ইনস্টল হয়, কিন্তু রিবুট না করা পর্যন্ত চলমান সিস্টেম পুরনো ফাইলগুলোই ব্যবহার করতে থাকে। do-release-upgrade শেষে রিবুট করার অনুরোধ জানায়; রিবুট না করে সার্ভার চালু রাখলে সেটি দুটি ভিন্ন রিলিজের মিশ্রণে চলতে থাকে। সার্ভার চালু হওয়ার পর নতুন kernel যাচাই করতে uname -r এবং যেসব সার্ভিস চালু হয়নি তা দেখতে systemctl --failed ব্যবহার করুন।

আমি কি ইন-প্লেস আপগ্রেড করব নাকি নতুন একটি 26.04 সার্ভার তৈরি করব?

সম্ভব হলে নতুন সার্ভার তৈরি করুন। নতুন VPS-এ আপনি স্ট্যাক ইনস্টল করতে পারেন, ডেটা রিস্টোর করতে পারেন এবং পুরনো সার্ভার চালু থাকা অবস্থাতেই সবকিছু পরীক্ষা করতে পারেন। এতে কোনো সমস্যা হলে শুধু DNS পরিবর্তন করলেই আগের সার্ভারে ফিরে যাওয়া যায়, ব্যাকআপ থেকে রিস্টোর করার প্রয়োজন হয় না। যদি সার্ভারের ডেটা স্থানান্তর করা কঠিন হয়, প্রোভাইডার যদি প্রতি মেশিনের জন্য বিল করে, অথবা আপনার কাছে স্ন্যাপশট ও কনসোল অ্যাক্সেস থাকে, তবেই ইন-প্লেস আপগ্রেড করুন। ইন-প্লেস আপগ্রেড একটি প্রচলিত পদ্ধতি, তবে এটি চলাকালীন সময়ে কোনো ভুল হলে তা সংশোধন করা কঠিন।

আপগ্রেড চলাকালীন SSH সংযোগ বিচ্ছিন্ন হলে কী হবে?

সাধারণ login shell-এ প্রসেসটি SIGHUP সিগন্যাল পেয়ে মাঝপথে বন্ধ হয়ে যায়, যার ফলে dpkg অসম্পূর্ণ কনফিগারেশনে আটকে থাকে। tmux বা screen-এর ভেতরে আপগ্রেড শুরু করলে সংযোগ বিচ্ছিন্ন হলেও প্রসেসটি সচল থাকে, ফলে আপনি পুনরায় লগইন করে tmux attach -t upgrade চালিয়ে কাজ চালিয়ে নিতে পারেন। আপগ্রেডার পোর্ট 1022-এ একটি অতিরিক্ত SSH daemon চালু রাখে, তবে এটি নিজে থেকে firewall খোলে না। তাই আগে থেকেই 1022 পোর্টটি firewall-এ অনুমতি দিন এবং কাজ শেষে তা বন্ধ করে দিন।

আপগ্রেডের পর আমার PHP সাইট 502 error দিচ্ছে। কী সমস্যা হয়েছে?

ভার্সন পরিবর্তনের সাথে সাথে PHP FPM সকেটের পাথ পরিবর্তিত হয়েছে। Ubuntu 24.04-এ PHP 8.3 এবং 26.04-এ PHP 8.5 চলে, তাই /run/php/php8.3-fpm.sock এখন আর নেই, অথচ আপনার nginx vhost-এ সেটিই উল্লেখ করা আছে। nginx এর error log-এ connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) দেখা যাবে। fastcgi_pass আপডেট করে 8.5 সকেট দিন, তারপর sudo nginx -t চালান এবং nginx রিলোড করুন। Apache-এর mod_php ব্যবহার করলে এর সমাধান হলো sudo a2dismod php8.3 চালানো এবং এরপর sudo a2enmod php8.5 দিয়ে রিস্টার্ট করা।