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

ان تبصروں میں ایک تفصیل لوگوں کو الجھا دیتی ہے۔ جب 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 نے ابھی تک راستہ نہیں کھولا ہے۔

پہلی point release جاری ہونے پر flag 1 میں تبدیل ہو جاتا ہے۔ Ubuntu 26.04.1 کی مقررہ تاریخ 27 August 2026 ہے، لیکن release schedules تبدیل ہو سکتے ہیں، اس لیے calendar کے بجائے metadata چیک کریں۔ point release، Ubuntu کا نیا version نہیں ہوتی؛ یہ صرف وہی release ہوتی ہے جس میں launch کے بعد کی تمام updates کو نئی install media میں شامل کر دیا جاتا ہے۔ اس لیے running server کے لیے اہم چیز media نہیں بلکہ وہ gate ہے جو یہ کھولتی ہے۔ یہ تاخیر دانستہ ہوتی ہے: جو لوگ جلد upgrade کرتے ہیں وہ blockers تلاش کرتے ہیں، اور بڑی تعداد میں LTS servers کے upgrade کرنے سے پہلے ان مسائل کو حل کر دیا جاتا ہے۔ اگر آپ کے پڑھنے تک یہ تاریخ گزر چکی ہو تو 26.04.1 میں کیا شامل ہو کر جاری ہوا اور 24.04 server کے لیے اس کا کیا مطلب ہے اسی سلسلے کو آگے بڑھاتا ہے۔

اس سے دو دیانت دارانہ اختیارات باقی رہتے ہیں۔ Point release کا انتظار کریں؛ ایسے ہر server کے لیے یہی درست فیصلہ ہے جس کی مسلسل نگرانی آپ نہیں کرنا چاہتے۔ یا Prompt=normal سیٹ کریں، جو اسی tool کو meta-release کی طرف متوجہ کرتا ہے، جہاں 26.04 کو پہلے ہی supported نشان زد کیا گیا ہے۔ دوسرے طریقے سے آپ released 26.04 پر upgrade ہوتے ہیں، development build پر نہیں؛ اس لیے ایسی machine پر یہ قابلِ دفاع ہے جسے snapshot سے restore کیا جا سکے۔ کام مکمل ہونے پر value کو واپس lts پر سیٹ کریں۔ طریقۂ کار کی step-by-step تفصیل 24.04 سے 26.04 server upgrade کی مکمل رہنمائی میں موجود ہے۔ 22.04 پر موجود server کو ایک اضافی مرحلہ مکمل کرنا ہوگا، کیونکہ Prompt=lts ہمیشہ صرف اگلی LTS release پیش کرتا ہے؛ اس لیے 22.04 سے 26.04 تک راستہ پہلے 24.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 اور نیم تشکیل شدہ (half-configured) پیکیجز کیلکولیشن کو روکتے ہیں

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

apt-mark showhold
sudo dpkg --audit

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

dpkg --audit ان پیکیجز کی فہرست دیتی ہے جو unpack تو ہو چکے تھے لیکن configure نہیں ہوئے۔ یہ حالت اس وقت پیدا ہوتی ہے جب انسٹالیشن کے دوران خلل پڑ جائے، اکثر سیشن منقطع ہونے کی وجہ سے۔ اپ گریڈر اسے ٹھیک کرنے کی کوشش کرتا ہے اور dpkg interrupted, calling dpkg --configure -a پرنٹ کرتا ہے، لیکن خود مرمت کرنے کا فائدہ یہ ہے کہ آپ error کو پڑھ سکتے ہیں بجائے اس کے کہ وہ اسکرین پر تیزی سے گزر جائے۔ جو پیکیج ٹول ٹھیک نہیں کر سکتا وہ 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 پیکیجز کو پیچھے چھوڑ سکتا ہے، اور سرور آپ کی توقع سے کم اپ ٹو ڈیٹ رہتا ہے۔ یہ آپشن ان سب کو لے آتا ہے۔ اگر اپ ڈیٹس کے ساتھ kernel بھی شامل ہو تو بعد میں ریبوٹ کریں، تاکہ آپ اس kernel سے اپ گریڈ کریں جو فی الحال چل رہا ہے۔ جو سرور 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

آرکائیو اسی وقت منتقل ہو جاتا ہے۔ end of life ریلیز کے پیکجز archive.ubuntu.com سے ہٹا دیے جاتے ہیں اور old-releases.ubuntu.com پر رکھے جاتے ہیں۔ چنانچہ apt update واپس 404 Not Found دینا شروع کر دیتا ہے، سسٹم کو مزید اپ ٹو ڈیٹ نہیں کیا جا سکتا، اور چونکہ اپ گریڈر ایک موجودہ سسٹم کا تقاضا کرتا ہے، اس لیے کوئی عمل آگے نہیں بڑھتا۔ پہلے سورسز (sources) کو درست کریں۔

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 کی طرف پوائنٹ کریں، اور اپنے کوڈ نیم (codename) کو نہ چھیڑیں۔ صرف ہوسٹ کا نام تبدیل ہوتا ہے۔

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 پر ایک نیا سرور بنائیں، سروس کو وہاں منتقل کریں، اور پرانے سرور کو تب تک رکھیں جب تک آپ کو یقین نہ ہو جائے۔ یہ آپ کو ایک رول بیک (rollback) بھی دیتا ہے، جو کہ ان پلیس اپ گریڈ (in-place upgrade) کبھی نہیں دیتا۔ اگر آپ فیصلہ کر رہے ہیں کہ اس کے بعد کس ٹریک پر رہنا ہے، تو سرور پر LTS اور interim ریلیز کے درمیان فرق فیصلہ کرنے سے پہلے پڑھنا مفید ہے۔

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) session ختم ہو جائے تو process ختم ہو جاتا ہے، جبکہ packages unpacked اور unconfigured رہ جاتے ہیں۔ یہی حالت آپ کی اگلی کوشش کو ناکام بناتی ہے۔ اگر آپ کے ساتھ ایسا پہلے ہی ہو چکا ہے تو آدھے راستے میں رک جانے والے اپ گریڈ کی بحالی ایک الگ کام ہے، اور دوسری کوشش سے پہلے اسے مکمل کرنا ضروری ہے۔ ہر بار اپ گریڈ کو terminal multiplexer کے اندر شروع کریں۔

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

اگر کنکشن منقطع ہو جائے، تو دوبارہ لاگ ان کریں اور tmux attach -t upgrade چلائیں۔ اپ گریڈ چلتا رہتا ہے، کیونکہ یہ آپ کے SSH سیشن کے بجائے tmux سرور کا چائلڈ (child) ہوتا ہے۔ اگر آپ 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. پرنٹ کرتا ہے اور رک جاتا ہے۔ 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 ورژن نئی ریلیز سے زیادہ نیا ہو تو انہیں آرکائیو سے دوبارہ انسٹال کریں۔