do-release-upgrade: no new release found সমাধান

কেন 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 হলো গেট বা বাধা। একটি 24.04 সার্ভার যা ডিফল্ট Prompt=lts ব্যবহার করে, সেটি এই ফাইলটি পড়ে এবং নতুন কোনো LTS রিলিজ উপলব্ধ না থাকায় No new release found. মেসেজটি দেখায়। আপনার মেশিনে কোনো সমস্যা নেই। Canonical এখনো আপগ্রেডের পথ উন্মুক্ত করেনি।

প্রথম point release প্রকাশিত হলে flagটি 1-এ পরিবর্তিত হয়। Ubuntu 26.04.1 27 August 2026-এ প্রকাশের জন্য নির্ধারিত, তবে release schedule পরিবর্তিত হতে পারে। তাই calendar-এর বদলে metadata পরীক্ষা করুন। Point release Ubuntu-এর নতুন version নয়। এটি launch-এর পর থেকে প্রকাশিত সব update যুক্ত করা একই release-এর fresh install media। তাই চলমান server-এর ক্ষেত্রে media নয়, এটি যে gate খুলে দেয় সেটিই গুরুত্বপূর্ণ। এই বিলম্ব ইচ্ছাকৃত। যারা আগে upgrade করেন, তারা blocker শনাক্ত করেন। বৃহত্তর LTS server পরিবেশ upgrade করার আগে সেই blocker-গুলো ঠিক করা হয়। আপনি এটি পড়ার সময় যদি ওই তারিখ পেরিয়ে যায়, 26.04.1-এ কী প্রকাশিত হয়েছে এবং 24.04 server-এর জন্য এর অর্থ কী সেখান থেকে বিষয়টি এগিয়ে নেবে।

এতে দুটি বাস্তবসম্মত বিকল্প থাকে। প্রথম point release-এর জন্য অপেক্ষা করুন। আপনি যে কোনো server নজরদারি না করেই চালাতে চান, তার জন্য এটিই সঠিক সিদ্ধান্ত। অথবা Prompt=normal সেট করুন। এতে একই tool-কে meta-release-এর দিকে নির্দেশ করা হয়, যেখানে 26.04 ইতিমধ্যে supported হিসেবে চিহ্নিত। দ্বিতীয় পদ্ধতিতে development build নয়, released 26.04-এ upgrade করা হয়। তাই snapshot থেকে restore করা যায় এমন machine-এ এই পদ্ধতি গ্রহণযোগ্য। কাজ শেষ হলে মানটি আবার lts-এ সেট করুন। সম্পূর্ণ প্রক্রিয়াটি ধাপে ধাপে 24.04 থেকে 26.04 server upgrade-এর পূর্ণ নির্দেশিকায় দেওয়া আছে। 22.04-এ থাকা server-এর জন্য একটি অতিরিক্ত ধাপ প্রয়োজন। কারণ Prompt=lts কেবল পরবর্তী LTS release-ই প্রস্তাব করে। তাই 22.04 থেকে 26.04-এ যাওয়ার পথে প্রথমে 24.04-এ upgrade করতে হয়।

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

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

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

দীর্ঘ সময় ধরে চলা কোনো unattended run-এর সময় টুলটিকে সিদ্ধান্ত নিতে দেওয়ার পরিবর্তে, শুরু করার আগেই আপনি নিজে এই সিদ্ধান্ত নিন।

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 এবং পরবর্তী ভার্সনগুলোতে বেশিরভাগ সোর্স deb822 ফরম্যাটে /etc/apt/sources.list.d/ubuntu.sources-এ থাকে। একই রিপোজিটরি যদি পুরনো এবং নতুন উভয় ফরম্যাটে লেখা থাকে, তবে সেটি একটি আলাদা ত্রুটি হিসেবে গণ্য হয় এবং এর নিজস্ব বার্তা রয়েছে, যা 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.

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

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

একটি release upgrade করলে সিস্টেমের অধিকাংশ অংশ প্রতিস্থাপিত হয়। এর মধ্যে openssh-server এবং systemd-ও থাকে। dpkg কাজ করার সময় আপনার SSH (secure shell) session বিচ্ছিন্ন হলে process বন্ধ হয়ে যায়। তখন কিছু package unpacked এবং unconfigured অবস্থায় থাকে। এই অবস্থাই পরবর্তী প্রচেষ্টা ব্যর্থ করে। এটি ইতিমধ্যে ঘটে থাকলে মাঝপথে থেমে যাওয়া upgrade পুনরুদ্ধার করা আলাদা কাজ। দ্বিতীয়বার চেষ্টা করার আগে সেটি সম্পন্ন করুন। প্রতিবার terminal multiplexer-এর মধ্যে upgrade শুরু করুন।

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

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

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

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

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

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

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

• একটি স্ন্যাপশট বা সম্পূর্ণ ব্যাকআপ নিন। ইন-প্লেস রিলিজ আপগ্রেড করার পর তা পূর্বাবস্থায় ফেরানোর কোনো উপায় নেই, এটিই আপনার একমাত্র সুযোগ।
• প্রয়োজনে ব্যবহারের আগে আপনার প্রোভাইডারের কনসোল খুলতে পারেন কি না তা নিশ্চিত করুন। রিবুটের পর সার্ভার যদি চালু না হয়, তবে 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. আউটপুট দেয় এবং কাজ বন্ধ করে দেয়। Ubuntu-এর নিজস্ব সার্ভার ডকুমেন্টেশন অনুযায়ী ডেভেলপমেন্ট রিলিজ প্রোডাকশনের জন্য সুপারিশ করা হয় না, তাই রিলিজ হওয়া 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)-এর মতো একটি লাইন প্রিন্ট করে। তবে নিজে থেকে আগে মুছে ফেলা ভালো, কারণ এতে আপনি ক্রম নির্ধারণ করতে পারেন এবং ফলাফল দেখতে পারেন। আপনার প্রয়োজনীয় প্যাকেজগুলোর জন্য apt policy চালান, এতে বোঝা যাবে কোন প্যাকেজটি কোন PPA থেকে এসেছে। যদি PPA ভার্সনটি নতুন রিলিজের চেয়ে আধুনিক হয়, তবে আর্কাইভ থেকে সেগুলো পুনরায় ইনস্টল করুন।