Ubuntu میں do-release-upgrade: no new release found کا حل

do-release-upgrade کیوں کہتا ہے کہ کوئی نئی ریلیز نہیں ملی

do-release-upgrade جو No new release found. پر ختم ہوتا ہے، وہ تقریباً کبھی بھی خراب ٹول نہیں ہوتا۔ جس راستے (path) کی آپ نے درخواست کی ہے وہ اس لمحے بند ہے، اور ٹول اسے ممکنہ حد تک مختصر طریقے سے رپورٹ کرتا ہے۔ پانچ چیزیں اسے بند کرتی ہیں: /etc/update-manager/release-upgrades میں Prompt کی ترتیب، LTS (long term support) اپ گریڈز پر پوائنٹ ریلیز گیٹ، تھرڈ پارٹی ریپوزٹریز، ایسے پیکجز جو ہولڈ پر ہیں یا آدھے کنفیگرڈ ہیں، اور ایسی ریلیز جس کی سپورٹ ختم ہو چکی ہے۔

ان کو اسی ترتیب سے چیک کریں۔ ہر ایک کے لیے ایک کمانڈ موجود ہے جو یہ ثابت کرتی ہے کہ آیا یہ آپ کے سرور پر لاگو ہوتی ہے یا نہیں، لہذا آپ کو کبھی یہ اندازہ لگانے کی ضرورت نہیں پڑے گی کہ آپ ان پانچوں میں سے کس مسئلے کا سامنا کر رہے ہیں۔

check-only فلیگ دراصل کیا رپورٹ کرتا ہے

sudo do-release-upgrade -c
echo $?

-c کا مطلب صرف چیک کرنا ہے۔ یہ 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 ہوتا ہے، جو کہ عام شیل کنونشن کے برعکس ہے، لہذا اس کے گرد کوئی چیک بنانے سے پہلے اسے احتیاط سے پڑھیں۔

اگر آپ کا لاگ ان بینر اب بھی پرانا جواب دکھا رہا ہے، تو یہ کیشڈ (cached) ہے۔ وہ لائن /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

یہ فائل اپنے تبصروں (comments) میں اپنی دستاویزات خود رکھتی ہے۔ تین اقدار (values) درست ہیں:

• never: نئے ریلیز کے لیے کبھی چیک نہ کریں اور نہ ہی اپ گریڈ کی اجازت دیں۔
• normal: موجودہ ریلیز کے فوراً بعد آنے والی معاونت شدہ (supported) ریلیز پیش کریں۔
• 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 کو پڑھتا ہے۔ دونوں فائلیں ہر ریلیز کی تفصیل کلیدوں کے ایک چھوٹے بلاک میں بیان کرتی ہیں، اور اپ گریڈر تب ہی ریلیز کی پیشکش کرتا ہے جب اس کا 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 نے ابھی تک راستہ نہیں کھولا ہے۔

جب پہلی پوائنٹ ریلیز جاری ہوتی ہے تو یہ فلیگ 1 میں تبدیل ہو جاتا ہے۔ Ubuntu 26.04.1 کی تاریخ 27 اگست 2026 طے ہے، اور ریلیز کے شیڈول تبدیل ہوتے رہتے ہیں، اس لیے کیلنڈر کے بجائے میٹا ڈیٹا چیک کریں۔ یہ تاخیر جان بوجھ کر کی جاتی ہے: جو لوگ جلد اپ گریڈ کرتے ہیں وہ رکاوٹیں (blockers) تلاش کر لیتے ہیں، اور LTS سرورز کی بڑی تعداد کے اپ گریڈ کرنے سے پہلے انہیں ٹھیک کر دیا جاتا ہے۔

اس کے دو ایماندارانہ طریقے ہیں۔ پوائنٹ ریلیز کا انتظار کریں، جو کہ کسی بھی ایسے سرور کے لیے درست فیصلہ ہے جسے آپ مسلسل مانیٹر نہیں کرنا چاہتے۔ یا پھر Prompt=normal سیٹ کریں، جو اسی ٹول کو meta-release کی طرف موڑ دیتا ہے، جہاں 26.04 پہلے سے ہی سپورٹڈ کے طور پر نشان زد ہے۔ دوسرا راستہ آپ کو ریلیز شدہ 26.04 پر اپ گریڈ کرتا ہے، نہ کہ کسی ڈیولپمنٹ بلڈ پر، لہذا ایسی مشین پر یہ قابلِ دفاع ہے جسے آپ اسنیپ شاٹ سے بحال کر سکتے ہیں۔ کام مکمل ہونے پر ویلیو کو واپس lts پر سیٹ کر دیں۔ طریقہ کار، قدم بہ قدم، 24.04 سے 26.04 سرور اپ گریڈ کی مکمل واک تھرو میں موجود ہے۔

تھرڈ پارٹی ریپوزٹریز اور PPA جو اپ گریڈ میں رکاوٹ بنتے ہیں

اپ گریڈر آپ کے APT ذرائع کو نئے ریلیز کی طرف پوائنٹ کرنے کے لیے دوبارہ لکھتا ہے۔ یہ صرف ان ریپوزٹریز کے لیے ایسا کر سکتا ہے جو نئے ریلیز کے لیے پبلش کی گئی ہوں، لہذا باقی تمام کو کمنٹ آؤٹ کر دیا جاتا ہے۔ اس کی وجوہات ہر انٹری کے لیے ایک لائن میں درج ہوتی ہیں، اور وہ مخصوص ہیں: was disabled (unknown mirror)، was disabled (unknown dist)، اور was disabled (no Release file)۔

noble کے لیے بنایا گیا PPA (پرسنل پیکیج آرکائیو) سرور پر 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 اور نصف کنفیگر شدہ پیکجز کیلکولیشن کو روکتے ہیں

ایک release upgrade کو سسٹم پر موجود تقریباً ہر پیکج کو منتقل کرنا پڑتا ہے۔ اگر ایک بھی پیکج منتقل نہ ہو سکے تو کیلکولیشن ناکام ہو جاتی ہے، اور اپ گریڈر آپ کو ادھوری حالت میں چھوڑنے کے بجائے جلد رک جانا بہتر سمجھتا ہے۔ دو کمانڈز اس کی وجہ تلاش کرتی ہیں۔

apt-mark showhold
sudo dpkg --audit

apt-mark showhold ہر لائن پر ایک held پیکج پرنٹ کرتی ہے، اور کلین سسٹم پر کچھ بھی پرنٹ نہیں کرتی۔ Hold ایک دستی ہدایت ہے کہ اس پیکج کو کبھی تبدیل نہ کیا جائے۔ کسی نے کرنل یا ڈیٹا بیس ورژن کو پن (pin) کیا ہوگا اور پھر بھول گیا ہوگا۔ جن کی آپ کو مزید ضرورت نہیں انہیں sudo apt-mark unhold اور اس کے بعد پیکج کا نام لکھ کر ریلیز کریں۔

dpkg --audit ان پیکجز کی فہرست دیتی ہے جو ان پیک (unpack) تو ہو چکے تھے لیکن کنفیگر نہیں ہوئے۔ یہ حالت اس انسٹالیشن سے پیدا ہوتی ہے جو درمیان میں رک گئی ہو، اکثر سیشن ڈراپ ہونے کی وجہ سے۔ اپ گریڈر اسے ٹھیک کرنے کی کوشش کرتا ہے اور 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 کے ذریعے خود کو پیچ رکھتا ہے اسے یہاں کم کام کرنا پڑتا ہے، حالانکہ یہ میکانزم ڈیزائن کے لحاظ سے کبھی بھی ریلیز کی حدود کو عبور نہیں کرتا۔

جب ریلیز معیاری سپورٹ کی مدت ختم کر لے

ایک عبوری 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 کو پڑھے۔ مینوئل پیج اسے یوں بیان کرتا ہے: "اگر تازہ ترین معاون ریلیز استعمال کر رہے ہیں، تو 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 کی سرور دستاویزات اس فلیگ کے بارے میں واضح ہیں: "development ریلیز (یا -d فلیگ) کا استعمال پروڈکشن ماحول کے لیے تجویز کردہ نہیں ہے۔" ایک development ریلیز روزانہ تبدیل ہوتی ہے اور اس میں سیکیورٹی سپورٹ کا کوئی وعدہ نہیں ہوتا، لہذا جو پیکیج صبح کام کر رہا ہو وہ دوپہر کو کسی سروس کو خراب کر سکتا ہے۔ اسے صرف ایک ایسی scratch ورچوئل مشین پر استعمال کریں جسے آپ نے اپنی کنفیگریشن ٹیسٹ کرنے کے لیے بنایا ہو۔ اسے ایسے سرور پر ہرگز استعمال نہ کریں جس پر کوئی انحصار کرتا ہو۔ جب آپ LTS گیٹ کھلنے سے پہلے ریلیز شدہ 26.04 حاصل کرنا چاہتے ہوں، تو Prompt=normal درست راستہ ہے۔

اپ گریڈ کو اس طرح چلائیں کہ SSH سیشن منقطع ہونے سے عمل متاثر نہ ہو

ایک ریلیز اپ گریڈ سسٹم کے بیشتر حصوں کو تبدیل کر دیتا ہے، بشمول openssh-server اور systemd۔ اگر dpkg کے کام کرنے کے دوران آپ کا SSH (secure shell) سیشن ختم ہو جائے، تو عمل منقطع ہو جاتا ہے اور پیکجز غیر ترتیب شدہ (unconfigured) حالت میں رہ جاتے ہیں، جو کہ اگلی کوشش میں رکاوٹ بنتا ہے۔ ہر بار اپ گریڈ کو terminal multiplexer کے اندر شروع کریں۔

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 بھی یہی کام کرتے ہیں۔

اپ گریڈر ان لوگوں کے لیے اپنی حفاظتی تدبیر رکھتا ہے جو multiplexer استعمال نہیں کرتے۔ جب یہ پتہ لگاتا ہے کہ یہ SSH کے تحت چل رہا ہے، تو یہ پورٹ 1022 پر ایک دوسرا sshd شروع کرنے کی پیشکش کرتا ہے، تاکہ مرکزی سیشن ٹوٹنے کی صورت میں بھی رسائی کا راستہ موجود رہے۔ یہ اپنے پیرنٹ پروسیسز کو دیکھ کر فیصلہ کرتا ہے کہ آیا کوئی sshd نامی پروسیس موجود ہے۔ tmux یا screen کے اندر یہ تلاش multiplexer سرور تک پہنچ جاتی ہے، اس لیے وہ پیشکش ظاہر نہیں ہوتی، اور pid فائل /var/run/release-upgrader-sshd.pid صرف تب لکھی جاتی ہے جب اضافی daemon واقعی شروع ہو۔ اگر آپ کو یہ پرامپٹ نظر نہ آئے تو کوئی مسئلہ نہیں ہے۔ آپ کے پاس پہلے ہی بہتر تحفظ موجود ہے۔

اگر آپ پیشکش قبول کرتے ہیں، تو پورٹ آپ کے لیے خودکار طور پر نہیں کھلے گا۔ ٹول یہ بات واضح طور پر بتاتا ہے، کیونکہ پورٹ کھولنا ایک سیکیورٹی فیصلہ ہے جو اسے آپ کی جانب سے کرنے کا اختیار نہیں ہے۔ اپ گریڈ کے دوران اسے کھولیں، اور پھر دوبارہ بند کر دیں۔

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

زیادہ تر VPS فراہم کرنے والے آپریٹنگ سسٹم کے باہر اپنے کنٹرول پینل میں ایک دوسرا فائر وال چلاتے ہیں۔ پورٹ 1022 کو وہاں بھی کھلا ہونا چاہیے، ورنہ fallback listener چل تو رہا ہوگا لیکن ناقابل رسائی ہوگا، جو کہ بدترین صورتحال ہے۔

کمانڈ ٹائپ کرنے سے پہلے چار چیزیں یقینی بنائیں:

• اسنیپ شاٹ لیں یا مکمل بیک اپ بنائیں۔ ان-پلیس ریلیز اپ گریڈ کو واپس (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. پرنٹ کرتا ہے اور رک جاتا ہے۔ 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 چلانے سے پہلے مجھے اپنے PPAs ہٹانے کی ضرورت ہے؟

آپ کو ایسا کرنے کی ضرورت نہیں ہے، کیونکہ اپ گریڈر ہر اس سورس کو کمنٹ آؤٹ کر دیتا ہے جو نئی ریلیز کے لیے شائع نہیں ہوتا اور ہر ایک کے لیے was disabled (no Release file) جیسی لائن پرنٹ کرتا ہے۔ خود ایسا کرنا بہتر ہے، کیونکہ آپ ترتیب کا انتخاب خود کرتے ہیں اور نتیجہ دیکھ سکتے ہیں۔ جن پیکجز کی آپ کو فکر ہے ان پر apt policy چلائیں تاکہ معلوم ہو سکے کہ کون سا پیکج کس PPA سے آیا ہے، پھر اگر PPA ورژن نئی ریلیز سے زیادہ نیا ہو تو انہیں آرکائیو سے دوبارہ انسٹال کریں۔