Ubuntu-তে do-release-upgrade কেন নতুন রিলিজ পায় না

কেন do-release-upgrade কোনো নতুন রিলিজ খুঁজে পায় না

do-release-upgrade-এ শেষ হওয়া No new release found. কোনো ত্রুটিপূর্ণ টুল নয়। আপনি যে পাথটি চেয়েছেন তা সেই মুহূর্তে বন্ধ থাকে এবং টুলটি তার সাধ্যমতো সংক্ষিপ্ত উপায়ে তা জানায়। পাঁচটি কারণে এটি বন্ধ হতে পারে: /etc/update-manager/release-upgrades-এ Prompt সেটিং, LTS (long term support) আপগ্রেডের ক্ষেত্রে পয়েন্ট রিলিজ গেট, থার্ড পার্টি রিপোজিটরি, আটকে থাকা বা আংশিক কনফিগার করা প্যাকেজ এবং এমন কোনো রিলিজ যার সাপোর্ট শেষ হয়ে গেছে।

এই ক্রমানুসারে কাজগুলো পরীক্ষা করুন। প্রতিটির জন্য একটি কমান্ড রয়েছে যা প্রমাণ করবে সেটি আপনার সার্ভারের ক্ষেত্রে প্রযোজ্য কি না, ফলে আপনাকে অনুমান করতে হবে না যে এই পাঁচটির মধ্যে কোনটি আপনার সমস্যার কারণ।

check-only ফ্ল্যাগটি আসলে কী রিপোর্ট করে

sudo do-release-upgrade -c
echo $?

-c হলো check-only মোড। এটি HTTPS (hypertext transfer protocol secure)-এর মাধ্যমে Canonical-এর রিলিজ মেটাডেটা পড়ে এবং ফলাফল প্রদর্শন করে। এটি কোনো আপগ্রেড টুল ডাউনলোড করে না এবং কোনো সোর্স ফাইল পরিবর্তন করে না। দুটি আউটপুট গুরুত্বপূর্ণ:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

স্ক্রিপ্টের ক্ষেত্রে এক্সিট কোড একই উত্তর বহন করে। যখন কোনো রিলিজ পাওয়া যায় তখন এটি 0 এবং যখন কোনো রিলিজ পাওয়া যায় না তখন এটি 1 রিটার্ন করে। এটি সাধারণ শেল কনভেনশনের বিপরীত, তাই এর ওপর ভিত্তি করে কোনো স্ক্রিপ্ট তৈরির আগে বিষয়টি সতর্কতার সাথে দেখুন।

আপনার লগইন ব্যানারে যদি এখনো পুরোনো তথ্য দেখায়, তবে বুঝতে হবে সেটি ক্যাশ করা আছে। সেই লাইনটি /etc/update-motd.d/91-release-upgrade থেকে আসে, যা নেটওয়ার্কে জিজ্ঞাসা করার পরিবর্তে সংরক্ষিত ফলাফল প্রদর্শন করে। এটিকে রিফ্রেশ করতে sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd ব্যবহার করুন অথবা সরাসরি -c-এর ওপর আস্থা রাখুন। ব্যানারটি শুধুমাত্র সর্বশেষ চালানো চেকের ফলাফল পুনরাবৃত্তি করে।

এই চেকটি সম্পন্ন করার জন্য changelogs.ubuntu.com-এ পৌঁছানো প্রয়োজন। কঠোর আউটবাউন্ড ফায়ারওয়াল বা প্রক্সির পেছনে থাকা সার্ভারে টুলটি কোনো অনুরোধ পাঠাতে পারে না, তাই এটি কোনো আপডেট খুঁজে পায় না।

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

একটি HTTP/2 200 লাইন মানে হলো সার্ভার মেটাডেটা দেখতে পাচ্ছে। একটি curl: (28) Connection timed out মানে হলো আপনার ইগ্রেস (egress) রুলগুলোই এর মূল কারণ, এবং APT (advanced package tool) ফাইল এডিট করে এর কোনো পরিবর্তন হবে না।

যদি কমান্ডটি একেবারেই অনুপস্থিত থাকে, তবে এটি ubuntu-release-upgrader-core প্যাকেজে থাকে। মিনিমাল ক্লাউড ইমেজগুলোতে অনেক সময় এই প্যাকেজটি থাকে না।

sudo apt install ubuntu-release-upgrader-core

কোনো কিছু পরিবর্তন করার আগে /etc/update-manager/release-upgrades ফাইলটি পড়ুন

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

এই ফাইলে মন্তব্য আকারে প্রয়োজনীয় নথিপত্র দেওয়া আছে। এখানে তিনটি মান বৈধ:

• never: নতুন রিলিজে আপগ্রেড করার জন্য কখনোই চেক করবে না এবং অনুমতি দেবে না।
• normal: বর্তমানে চলমান রিলিজের ঠিক পরের সমর্থিত রিলিজটি অফার করবে।
• lts: বর্তমানে চলমান রিলিজের পরের প্রথম LTS রিলিজটি অফার করবে।

Prompt=never এই তিনটির মধ্যে নির্ণয় করা সবচেয়ে সহজ, কারণ টুলটি তার আউটপুটে ফাইল এবং সেটিং—উভয়ের নামই উল্লেখ করে:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

হোস্টিং প্রোভাইডার এবং কনফিগারেশন ম্যানেজমেন্ট টুলগুলো ইচ্ছাকৃতভাবে never সেট করে রাখে, যাতে সার্ভারগুলোর রিলিজ ভার্সন পরিবর্তিত না হয়। যদি আপনি সেখানে এটি খুঁজে পান, তবে বুঝবেন কেউ এটি বেছে নিয়েছে। আপনি যদি সার্ভারটিকে লং টার্ম সাপোর্ট ট্র্যাকে রাখতে চান তবে এটিকে lts-এ পরিবর্তন করুন এবং আপনার অটোমেশন সিস্টেম যদি আগের মানটি প্রত্যাশা করে, তবে কাজ শেষে পুনরায় আগের অবস্থায় ফিরিয়ে দিন।

এই মন্তব্যগুলোর একটি বিষয় অনেককে বিভ্রান্ত করে। যখন Prompt=lts সেট করা থাকে এবং চলমান রিলিজটি নিজে কোনো LTS রিলিজ হয় না, তখন আপগ্রেডার এই সেটিংটিকে normal হিসেবে গণ্য করে। একটি 25.10 মেশিনে এই দুটি মান একইভাবে কাজ করে। কিন্তু একটি 24.04 মেশিনে তা হয় না, এবং এই পার্থক্যটিই পরবর্তী পুরো সেকশনের বিষয়বস্তু।

কেন LTS থেকে LTS আপগ্রেড প্রথম পয়েন্ট রিলিজ পর্যন্ত অপেক্ষা করে

Prompt নির্ধারণ করে যে আপগ্রেডার কোন মেটাডেটা ফাইলটি পড়বে। ঠিকানাগুলো /etc/update-manager/meta-release-এ থাকে:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts ফাইলটি meta-release-lts পড়ে। Prompt=normal ফাইলটি meta-release পড়ে। উভয় ফাইলই প্রতিটি রিলিজের বিবরণ ছোট ছোট কি (key)-এর ব্লকে রাখে এবং আপগ্রেডার কেবল তখনই একটি রিলিজ অফার করে যখন এর Supported: ফ্ল্যাগটি 1 থাকে। আপনি নিজেই একই সার্ভার থেকে এগুলো পড়ে দেখতে পারেন:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

13 আগস্ট 2026 তারিখে পরীক্ষা করে দেখা গেছে, Ubuntu 26.04-এর বিষয়ে ফাইল দুটি ভিন্ন তথ্য দিচ্ছে। LTS ফাইলে বলা হয়েছে:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

সাধারণ ফাইলে বলা হয়েছে:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

LTS ফাইলের সেই Supported: 0 হলো মূল বাধা। ডিফল্ট Prompt=lts ব্যবহারকারী একটি 24.04 সার্ভার সেই ফাইলটি পড়ে, কিন্তু সেখানে নতুন কোনো LTS রিলিজ উপলব্ধ হিসেবে চিহ্নিত না থাকায় No new release found. মেসেজটি দেখায়। আপনার মেশিনে কোনো সমস্যা নেই। Canonical এখনো আপগ্রেডের পথ উন্মুক্ত করেনি।

প্রথম পয়েন্ট রিলিজ আসার পর এই ফ্ল্যাগটি 1-এ পরিবর্তিত হয়। Ubuntu 26.04.1 রিলিজের তারিখ 27 আগস্ট 2026 নির্ধারিত আছে, তবে রিলিজের সময়সূচী পরিবর্তিত হতে পারে, তাই ক্যালেন্ডারের চেয়ে মেটাডেটা চেক করা ভালো। এই বিলম্বটি ইচ্ছাকৃত: যারা আগে আপগ্রেড করেন তারা সমস্যাগুলো খুঁজে বের করেন এবং LTS সার্ভারের বিশাল ব্যবহারকারী গোষ্ঠী আপগ্রেড করার আগেই সেগুলো সমাধান করা হয়।

এক্ষেত্রে দুটি সৎ উপায় আছে। প্রথমটি হলো পয়েন্ট রিলিজের জন্য অপেক্ষা করা, যা এমন যেকোনো সার্ভারের জন্য সঠিক সিদ্ধান্ত যেটিতে আপনি সার্বক্ষণিক নজর রাখতে চান না। অথবা Prompt=normal সেট করুন, যা একই টুলকে meta-release-এর দিকে নির্দেশ করবে, যেখানে 26.04 ইতিমধ্যেই সমর্থিত হিসেবে চিহ্নিত। দ্বিতীয় উপায়টি আপনাকে রিলিজ হওয়া 26.04 ভার্সনেই আপগ্রেড করবে, কোনো ডেভেলপমেন্ট বিল্ডে নয়, তাই স্ন্যাপশট থেকে রিস্টোর করা সম্ভব এমন মেশিনে এটি ব্যবহার করা যুক্তিসঙ্গত। কাজ শেষ হলে ভ্যালুটিকে আবার lts-এ সেট করে দিন। ধাপে ধাপে পুরো প্রক্রিয়াটি 24.04 থেকে 26.04 সার্ভার আপগ্রেডের সম্পূর্ণ নির্দেশিকা-তে দেওয়া আছে।

আপগ্রেড বাধাগ্রস্তকারী থার্ড-পার্টি রিপোজিটরি এবং PPA

আপগ্রেডার আপনার APT সোর্সগুলোকে নতুন রিলিজের দিকে নির্দেশ করার জন্য পুনরায় লিখে ফেলে। এটি শুধুমাত্র সেই রিপোজিটরিগুলোর জন্যই করা সম্ভব যেগুলোর নতুন রিলিজের জন্য প্রকাশনা রয়েছে, তাই অন্য যেকোনো সোর্সকে কমেন্ট আউট (comment out) করে দেওয়া হয়। এর কারণগুলো প্রতিটি এন্ট্রির জন্য আলাদা লাইনে প্রিন্ট করা হয় এবং সেগুলো সুনির্দিষ্ট: was disabled (unknown mirror), was disabled (unknown dist), এবং was disabled (no Release file)।

noble-এর জন্য তৈরি একটি PPA (personal package archive)-এর সার্ভারে resolute-এর জন্য কোনো ডিরেক্টরি থাকে না, তাই আপগ্রেডার নতুন সিরিজের জন্য Release ফাইল সংগ্রহ করতে পারে না এবং এন্ট্রিটিকে নিষ্ক্রিয় করে দেয়। এটি সাধারণত এমন একটি সতর্কতা যা আপনি মেনে নিতে পারেন। এটি তখন একটি বাধা হয়ে দাঁড়ায় যখন কোনো থার্ড-পার্টি রিপোজিটরি এমন একটি প্যাকেজ সরবরাহ করে যা নতুন রিলিজেও অন্তর্ভুক্ত থাকে, কারণ তখন আপগ্রেড ক্যালকুলেশনের কাছে দুটি প্রার্থী থাকে এবং উভয়কে সন্তুষ্ট করার কোনো উপায় থাকে না।

দীর্ঘ সময় ধরে চলা কোনো অটোমেটেড প্রক্রিয়ার ওপর ছেড়ে না দিয়ে, শুরু করার আগেই এই সিদ্ধান্তটি নিজে গ্রহণ করুন।

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

প্যাকেজের নামের ওপর apt policy কমান্ডটি চালালে প্রতিটি ইনস্টল করা ভার্সন কোন রিপোজিটরি থেকে এসেছে তা দেখা যায়, ফলে আপনি স্পষ্টভাবে দেখতে পাবেন যে কোন প্যাকেজগুলো সেই সোর্সের ওপর নির্ভরশীল যা আপনি নিষ্ক্রিয় করতে যাচ্ছেন। সোর্স সরিয়ে ফেললে কোনো কিছু ডাউনগ্রেড হয় না, তাই PPA থেকে ইনস্টল করা প্যাকেজটি তার PPA ভার্সনেই থেকে যায় এবং সেটি নতুন রিলিজের প্যাকেজের চেয়েও নতুন হতে পারে। যেখানে এটি গুরুত্বপূর্ণ, সেখানে প্যাকেজটি সরিয়ে ফেলুন এবং আপগ্রেডের পর আর্কাইভ থেকে পুনরায় ইনস্টল করুন। যে রিপোজিটরি আপনি পুনরায় যুক্ত করতে চান, যেমন Tailscale, সেটির কোডনেম নতুন রিলিজে আপডেট করতে হয়, অন্যথায় প্যাকেজটি পুনরায় ইনস্টল হবে না; আর এখানেই Ubuntu-তে Tailscale ইনস্টল সংক্রান্ত অধিকাংশ ত্রুটি তৈরি হয়।

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

Ubuntu 24.04 এবং পরবর্তী ভার্সনগুলোতে অধিকাংশ সোর্স /etc/apt/sources.list.d/ubuntu.sources-এ deb822 ফরম্যাটে থাকে। একই রিপোজিটরি যদি পুরনো এবং নতুন উভয় ফরম্যাটে লেখা থাকে, তবে সেটি একটি আলাদা ত্রুটি হিসেবে গণ্য হয় এবং এর নিজস্ব বার্তা রয়েছে, যা deb822 ফরম্যাটে ডুপ্লিকেট সোর্স এন্ট্রি ত্রুটি-তে আলোচনা করা হয়েছে।

Held এবং half-configured প্যাকেজগুলো ক্যালকুলেশন আটকে দেয়

একটি রিলিজ আপগ্রেডের সময় সিস্টেমের প্রায় প্রতিটি প্যাকেজ পরিবর্তন করতে হয়। যদি একটি প্যাকেজও সরানো না যায়, তবে ক্যালকুলেশন ব্যর্থ হয় এবং আপগ্রেডার আপনাকে মাঝপথে ফেলে রাখার চেয়ে কাজ শুরুতেই থামিয়ে দেওয়াকে শ্রেয় মনে করে। দুটি কমান্ডের মাধ্যমে এর কারণ খুঁজে পাওয়া যায়।

apt-mark showhold
sudo dpkg --audit

apt-mark showhold কমান্ডটি প্রতিটি লাইনে একটি করে held প্যাকেজ প্রদর্শন করে, আর সিস্টেম পরিষ্কার থাকলে কোনো কিছুই দেখায় না। একটি hold হলো প্যাকেজটি পরিবর্তন না করার জন্য দেওয়া একটি ম্যানুয়াল নির্দেশনা। হয়তো কেউ কোনো কার্নেল বা ডাটাবেস ভার্সন পিন করে রেখেছিলেন এবং পরে তা ভুলে গেছেন। যেগুলোর প্রয়োজন নেই, সেগুলো sudo apt-mark unhold এবং প্যাকেজের নাম লিখে রিলিজ করে দিন।

dpkg --audit কমান্ডটি এমন প্যাকেজগুলোর তালিকা দেয় যেগুলো আনপ্যাক করা হয়েছে কিন্তু কনফিগার করা হয়নি। কোনো ইনস্টলেশন মাঝপথে বাধাগ্রস্ত হলে, সাধারণত সেশন ড্রপ করলে এমন অবস্থার সৃষ্টি হয়। আপগ্রেডার এটি মেরামত করার চেষ্টা করে এবং dpkg interrupted, calling dpkg --configure -a প্রদর্শন করে, কিন্তু আপনি নিজে আগে মেরামত করলে এরর মেসেজটি পড়তে পারবেন, যা অন্যথায় স্ক্রল করে চলে যেত। যে প্যাকেজটি টুলটি মেরামত করতে পারে না, সেটি Package in inconsistent state মেসেজ দেয় এবং পুনরায় চেষ্টা করার আগে সেটির দিকে নজর দেওয়া প্রয়োজন।

আপগ্রেড করার আগে চলমান রিলিজটিকে সম্পূর্ণ আপ-টু-ডেট করে নিন।

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

Phased updates অপশনটি যতটা সাধারণ মনে হয়, তার চেয়েও গুরুত্বপূর্ণ। Ubuntu কিছু আপডেট নির্দিষ্ট শতাংশ মেশিনে ধাপে ধাপে পাঠায়, তাই সাধারণ apt upgrade কমান্ডটি চালালে কিছু প্যাকেজ বাদ পড়ে যেতে পারে এবং সার্ভারটি আপনার ধারণার চেয়ে কম আপডেট অবস্থায় থাকতে পারে। এই অপশনটি সবগুলো আপডেট নিয়ে আসে। যদি এর সাথে কোনো কার্নেল আপডেট আসে, তবে রিবুট করুন, যাতে আপনি বর্তমানে যে কার্নেলটি চালাচ্ছেন তা থেকেই আপগ্রেড শুরু হয়। যে সার্ভারটি unattended security upgrades-এর মাধ্যমে নিজেকে প্যাচ রাখে, সেটির ক্ষেত্রে কাজ কিছুটা কম হয়, যদিও এই মেকানিজমটি ডিজাইন অনুযায়ী কখনোই রিলিজের সীমানা অতিক্রম করে না।

যখন রিলিজটির স্ট্যান্ডার্ড সাপোর্ট শেষ হয়ে যায়

একটি অন্তর্বর্তীকালীন (interim) Ubuntu রিলিজ নয় মাসের জন্য সাপোর্ট পায়। যখন সেই সাপোর্ট শেষ হয়, তখন এর Supported: ফ্ল্যাগ 0-এ চলে যায় এবং সাধারণ পাথ থেকে আর কোনো আপগ্রেড পাওয়া যায় না। 13 আগস্ট 2026 তারিখে চেক করলে, meta-release-এ 25.10 সম্পর্কে এটি দেখা যায়:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

একই সময়ে আর্কাইভটিও স্থানান্তরিত হয়। একটি এন্ড-অফ-লাইফ রিলিজের প্যাকেজগুলো archive.ubuntu.com থেকে সরিয়ে old-releases.ubuntu.com-এ রাখা হয়। ফলে apt update তখন 404 Not Found রিটার্ন করতে শুরু করে, সিস্টেমটিকে আর আপ-টু-ডেট করা যায় না এবং যেহেতু আপগ্রেডার একটি বর্তমান সিস্টেম দাবি করে, তাই কোনো কাজই সম্পন্ন হয় না। প্রথমে সোর্সগুলো ঠিক করুন।

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

archive.ubuntu.com এবং security.ubuntu.com উভয়কেই old-releases.ubuntu.com-এর দিকে নির্দেশ করুন এবং আপনার কোডনেমটি অপরিবর্তিত রাখুন। শুধুমাত্র হোস্টের নাম পরিবর্তন হবে।

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

যদি আপনার সার্ভার এখনও তার সোর্সগুলো একটি মাত্র ফাইলে রাখে, তবে পরিবর্তে /etc/apt/sources.list-এর বিপরীতে একই কমান্ড চালান। -i.bak অপশনটি মূল ফাইলের পাশে একটি ব্যাকআপ তৈরি করে, যাতে ভুল ফাইলে এডিট করা হলে আপনি তা আগের অবস্থায় ফিরিয়ে নিতে পারেন। এরপর একটি পরিচ্ছন্ন apt update মানে হলো আর্কাইভটি পুনরায় অ্যাক্সেসযোগ্য হয়েছে এবং do-release-upgrade এখন আপনার সাথে যোগাযোগ করতে পারবে।

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

development release ফ্ল্যাগটি আসলে যা করে

-d বা --devel-release ব্যবহার করলে আপগ্রেডার Prompt দ্বারা নির্বাচিত ফাইলের পরিবর্তে meta-release-development ফাইলটি পড়ে। ম্যানুয়াল পেজে এটিকে এভাবে বর্ণনা করা হয়েছে: "যদি সর্বশেষ সমর্থিত রিলিজ ব্যবহার করা হয়, তবে ডেভেলপমেন্ট রিলিজে আপগ্রেড করুন।"

13 আগস্ট 2026 তারিখে যাচাই করে দেখা গেছে, সেই ফাইলে সর্বশেষ এন্ট্রিটি 26.04 নয়:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

সুতরাং -d কোনো 24.04 সার্ভারকে 26.04 রিলিজ প্রদান করে না। এটি 26.10-এর দিকে নির্দেশ করে, যা এখনও তৈরি করা হচ্ছে। "শুধু -d যোগ করুন" - এই পুরনো পরামর্শটি এমন সময়ের জন্য লেখা হয়েছিল যখন কোনো LTS রিলিজ হওয়ার আগের সময় চলছিল, এবং বর্তমানে এটি পুনরাবৃত্তি করলে আপনার সার্ভার এমন কোথাও নির্দেশিত হবে যেখানে আপনি যেতে চাননি। Prompt=lts কার্যকর থাকা অবস্থায় এই ফ্ল্যাগটি একটি নিজস্ব বার্তা দিয়ে থেমে যায়:

There is no development version of an LTS available.

Ubuntu-এর সার্ভার ডকুমেন্টেশনে এই ফ্ল্যাগটি সম্পর্কে সরাসরি বলা হয়েছে: "ডেভেলপমেন্ট রিলিজ (বা -d ফ্ল্যাগ) প্রোডাকশন এনভায়রনমেন্টের জন্য সুপারিশ করা হয় না"। একটি ডেভেলপমেন্ট রিলিজ প্রতিদিন পরিবর্তিত হয় এবং এতে কোনো নিরাপত্তা সহায়তার নিশ্চয়তা থাকে না, তাই সকালে যে প্যাকেজটি কাজ করে তা বিকেলে কোনো সার্ভিসকে অকেজো করে দিতে পারে। এটি শুধুমাত্র আপনার নিজস্ব কনফিগারেশন পরীক্ষা করার জন্য তৈরি করা একটি স্ক্র্যাচ ভার্চুয়াল মেশিনে ব্যবহার করুন। এমন কোনো সার্ভারে এটি ব্যবহার করবেন না যার ওপর কেউ নির্ভরশীল। যখন আপনি LTS গেট খোলার আগেই 26.04 রিলিজটি পেতে চান, তখন Prompt=normal হলো সঠিক উপায়।

এমনভাবে আপগ্রেড চালান যাতে SSH সেশন বিচ্ছিন্ন হলেও তা বাধাগ্রস্ত না হয়

একটি রিলিজ আপগ্রেড সিস্টেমের বেশিরভাগ অংশ প্রতিস্থাপন করে, যার মধ্যে openssh-server এবং systemd অন্তর্ভুক্ত। যদি openssh-server কাজ করার সময় আপনার SSH (secure shell) সেশন বিচ্ছিন্ন হয়ে যায়, তবে প্রসেসটি বন্ধ হয়ে যায় এবং প্যাকেজগুলো আনপ্যাকড ও আনকনফিগারড অবস্থায় থেকে যায়; এই অবস্থাটিই আপনার পরবর্তী আপগ্রেডের চেষ্টাকে বাধাগ্রস্ত করে। তাই প্রতিবার একটি টার্মিনাল মাল্টিপ্লেক্সারের ভেতরে আপগ্রেড শুরু করুন।

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

যদি সংযোগ বিচ্ছিন্ন হয়ে যায়, তবে পুনরায় লগ ইন করুন এবং tmux attach -t upgrade চালান। আপগ্রেডটি চলতে থাকবে, কারণ এটি আপনার SSH সেশনের পরিবর্তে tmux সার্ভারের চাইল্ড প্রসেস হিসেবে কাজ করে। আপনি যদি screen পছন্দ করেন, তবে screen -S upgrade এবং screen -r upgrade একই কাজ করবে।

যারা মাল্টিপ্লেক্সার ব্যবহার করেন না, তাদের জন্য আপগ্রেডার নিজস্ব নিরাপত্তা ব্যবস্থা প্রদান করে। যখন এটি শনাক্ত করে যে এটি SSH-এর অধীনে চলছে, তখন এটি 1022 পোর্টে একটি দ্বিতীয় sshd শুরু করার প্রস্তাব দেয়, যাতে মূল সেশন বিচ্ছিন্ন হলেও সার্ভারে প্রবেশের একটি পথ খোলা থাকে। এটি তার নিজস্ব প্যারেন্ট প্রসেসগুলো পরীক্ষা করে দেখে যে সেখানে sshd নামে কোনো প্রসেস আছে কি না। tmux বা screen-এর ভেতরে থাকলে এই পরীক্ষায় মাল্টিপ্লেক্সার সার্ভারটি পাওয়া যায়, তাই এই প্রস্তাবটি আর আসে না এবং pid ফাইল /var/run/release-upgrader-sshd.pid শুধুমাত্র তখনই লেখা হয় যখন অতিরিক্ত ডেমোনটি সত্যিই চালু হয়। আপনি যদি এই প্রম্পটটি না দেখেন, তবে চিন্তার কিছু নেই। আপনি ইতিমধ্যে আরও ভালো সুরক্ষা ব্যবহার করছেন।

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

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

অধিকাংশ VPS প্রোভাইডার অপারেটিং সিস্টেমের বাইরে তাদের কন্ট্রোল প্যানেলে একটি দ্বিতীয় ফায়ারওয়াল পরিচালনা করে। সেখানেও 1022 পোর্টটি খোলা থাকতে হবে, অন্যথায় ফলব্যাক লিসেনার চালু থাকলেও তা অকার্যকর থাকবে, যা সবচেয়ে খারাপ পরিস্থিতি।

কমান্ড টাইপ করার আগে চারটি বিষয় নিশ্চিত করুন:

• একটি স্ন্যাপশট বা সম্পূর্ণ ব্যাকআপ নিন। ইন-প্লেস রিলিজ আপগ্রেড করার কোনো 'আনডু' (undo) অপশন নেই এবং এটিই আপনার একমাত্র সুযোগ।
• প্রয়োজনে ব্যবহারের আগে আপনার প্রোভাইডারের কনসোল খুলতে পারছেন কি না তা নিশ্চিত করুন। যদি রিবুটের পর সার্ভার চালু না হয়, তবে SSH ব্যবহারের সুযোগ আর থাকবে না। কার্নেল বুট করতে ব্যর্থ হওয়া একটি ভিন্ন সমস্যা এবং এর নিজস্ব রিকভারি ধাপ রয়েছে, যা কার্নেল আপডেটের পর যে VPS বুট হয় না অংশে আলোচনা করা হয়েছে।
• df -h / /boot ব্যবহার করে ফ্রি স্পেস চেক করুন। আপগ্রেড করার সময় প্যাকেজের একটি সম্পূর্ণ সেট ডাউনলোড হয় এবং /boot পার্টিশনে অনেকগুলো পুরনো কার্নেল জমে থাকলে আপগ্রেড আটকে যাওয়ার সম্ভাবনা থাকে।
• আপনার চলমান সার্ভিসগুলোর রিলিজ নোট পড়ুন। PostgreSQL বা PHP-এর বড় কোনো ভার্সন জাম্প রিলিজের সাথেই চলে আসে, আপনি সেটির জন্য প্রস্তুত থাকুন বা না থাকুন।

FAQ

Ubuntu 24.04-এ do-release-upgrade কেন কোনো নতুন রিলিজ খুঁজে পায় না?

Prompt=lts-এর ডিফল্ট কনফিগারেশন /etc/update-manager/release-upgrades-এ টুলটিকে https://changelogs.ubuntu.com/meta-release-lts পড়ার নির্দেশ দেয়, এবং Ubuntu 26.04-এর প্রথম পয়েন্ট রিলিজ আসার আগ পর্যন্ত সেই ফাইলে Supported: 0 থাকে। আপগ্রেডার নতুন কোনো LTS রিলিজ উপলব্ধ না পাওয়ায় কাজ বন্ধ করে দেয়। curl -s https://changelogs.ubuntu.com/meta-release-lts ব্যবহার করে ফাইলটি নিজে পরীক্ষা করুন এবং শেষ ব্লকটি পড়ুন। 13 আগস্ট 2026 তারিখে পরীক্ষা করে দেখা গেছে যে ফ্ল্যাগটি তখনও 0 ছিল, যেখানে Ubuntu 26.04.1 রিলিজ হওয়ার তারিখ ছিল 27 আগস্ট 2026।

পয়েন্ট রিলিজের জন্য অপেক্ষা না করে Prompt=normal সেট করা কি নিরাপদ?

এটি আপনাকে রিলিজ হওয়া 26.04-এ আপগ্রেড করবে, কোনো ডেভেলপমেন্ট বিল্ডে নয়, কারণ Prompt=normal ফাইলটি meta-release পড়ে, যেখানে 26.04-এ ইতিমধ্যেই Supported: 1 সেট করা আছে। এখানে ঝুঁকি হলো সময়ের। আপনি প্রাথমিক আপগ্রেডারদের খুঁজে পাওয়া সমস্যাগুলো সমাধান হওয়ার আগেই আপগ্রেড করছেন। এমন সার্ভারে এটি করুন যেখান থেকে আপনি স্ন্যাপশট ব্যবহার করে আগের অবস্থায় ফিরে যেতে পারবেন এবং রিবুট ব্যর্থ হলে প্রোভাইডার কনসোল অ্যাক্সেস করতে পারবেন। কাজ শেষে ভ্যালুটি আবার lts-এ সেট করুন।

-d ফ্ল্যাগ কি আমাকে 26.04-এ আপগ্রেড করবে?

না। -d ফাইলটি meta-release-development পড়ে, যার সর্বশেষ এন্ট্রি 13 আগস্ট 2026 তারিখে ছিল Ubuntu 26.10, যা তখনও ডেভেলপমেন্ট পর্যায়ে ছিল। Prompt=lts যুক্ত একটি LTS মেশিনে এই ফ্ল্যাগটি There is no development version of an LTS available. প্রিন্ট করে এবং কাজ বন্ধ করে দেয়। উবুন্টুর নিজস্ব সার্ভার ডকুমেন্টেশন অনুযায়ী ডেভেলপমেন্ট রিলিজ প্রোডাকশনের জন্য সুপারিশ করা হয় না, তাই যখন আপনি রিলিজ হওয়া 26.04 আগে পেতে চান তখন Prompt=normal ব্যবহার করুন।

পুরনো রিলিজের ক্ষেত্রে apt update কেন 404 এরর দেয়? আমি কীভাবে এটি আপগ্রেড করব?

সেই রিলিজটির মেয়াদ শেষ হয়ে গেছে, তাই এর প্যাকেজগুলো archive.ubuntu.com থেকে old-releases.ubuntu.com-এ সরিয়ে নেওয়া হয়েছে। /etc/apt/sources.list.d/ubuntu.sources-এ, অথবা পুরনো লেআউটের ক্ষেত্রে /etc/apt/sources.list-এ শুধুমাত্র হোস্টের নামগুলো পরিবর্তন করুন এবং আপনার কোডনেমটি অপরিবর্তিত রাখুন। এরপর sudo apt update এবং sudo apt full-upgrade কমান্ড চালান। সিস্টেমটি পুনরায় আপ-টু-ডেট হয়ে গেলে, do-release-upgrade ব্যবহার করে একবারে একটি রিলিজ করে সামনে এগিয়ে যাওয়া যাবে।

do-release-upgrade চালানোর আগে কি আমার PPA-গুলো মুছে ফেলা প্রয়োজন?

আপনার তা করার প্রয়োজন নেই, কারণ আপগ্রেডার নতুন রিলিজের জন্য প্রকাশিত নয় এমন যেকোনো সোর্সকে কমেন্ট আউট করে দেয় এবং প্রতিটি সোর্সের জন্য was disabled (no Release file)-এর মতো একটি লাইন প্রিন্ট করে। তবে নিজে থেকে আগে মুছে ফেলা ভালো, কারণ এতে আপনি ক্রম নির্ধারণ করতে পারেন এবং ফলাফল দেখতে পারেন। আপনার প্রয়োজনীয় প্যাকেজগুলো কোন PPA থেকে এসেছে তা জানতে সেগুলোর ওপর apt policy চালান, এবং যদি PPA ভার্সনটি নতুন রিলিজের চেয়ে আধুনিক হয় তবে আর্কাইভ থেকে সেগুলো পুনরায় ইনস্টল করুন।