Ubuntu में do-release-upgrade: no new release found का

Why do-release-upgrade says no new release found

do-release-upgrade का अंत No new release found. पर होना लगभग कभी भी टूल के खराब होने का संकेत नहीं होता है। जिस path के लिए आपने अनुरोध किया है, वह उस समय बंद होता है और टूल इसे सबसे संक्षिप्त तरीके से रिपोर्ट करता है। पाँच चीजें इसे बंद करती हैं: /etc/update-manager/release-upgrades में Prompt सेटिंग, LTS (long term support) अपग्रेड पर point release गेट, थर्ड-पार्टी रिपॉजिटरी, ऐसे पैकेज जो होल्ड पर हैं या आधे कॉन्फ़िगर किए गए हैं, और कोई ऐसा रिलीज़ जो अपने सपोर्ट की अवधि समाप्त कर चुका है।

इनका इसी क्रम में समाधान करें। प्रत्येक के लिए एक कमांड है जो यह साबित करती है कि क्या वह आपके सर्वर पर लागू होती है, इसलिए आपको कभी यह अनुमान लगाने की आवश्यकता नहीं है कि आप इन पाँचों में से किस समस्या का सामना कर रहे हैं।

check-only फ्लैग वास्तव में क्या रिपोर्ट करता है

sudo do-release-upgrade -c
echo $?

-c का अर्थ केवल चेक करना है। यह HTTPS (हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल सिक्योर) के माध्यम से 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 (एडवांस्ड पैकेज टूल) फ़ाइलों को एडिट करने से उत्तर नहीं बदलेगा।

यदि कमांड पूरी तरह से गायब है, तो यह 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: नए release के लिए कभी जाँच न करें और न ही upgrade की अनुमति दें।
• normal: वर्तमान release के ठीक बाद आने वाले समर्थित release का सुझाव दें।
• lts: वर्तमान release के बाद आने वाले पहले LTS release का सुझाव दें।

Prompt=never इन तीनों में से सबसे आसान है जिसे डायग्नोस किया जा सकता है, क्योंकि टूल अपने आउटपुट में फाइल और सेटिंग दोनों का नाम बताता है:

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

Hosting providers और configuration management टूल्स जानबूझकर never सेट करते हैं, ताकि सर्वर का समूह अलग-अलग releases के बीच भटक न जाए। यदि आपको यह वहाँ मिलता है, तो किसी ने इसे चुना है। यदि आप चाहते हैं कि सर्वर long term support ट्रैक पर रहे, तो इसे lts में बदलें, और यदि आपका ऑटोमेशन पुराने मान की अपेक्षा करता है तो बाद में इसे वापस बदल दें।

उन टिप्पणियों में एक विवरण लोगों को भ्रमित करता है। जब Prompt=lts सेट होता है और चल रहा release स्वयं LTS release नहीं होता है, तो upgrader इस सेटिंग को 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 को पढ़ता है। दोनों फ़ाइलें हर रिलीज़ का विवरण कुंजियों (keys) के एक छोटे ब्लॉक में देती हैं, और अपग्रेडर केवल तभी रिलीज़ का सुझाव देता है जब उसका 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 के लिए निर्धारित किया गया है, और रिलीज़ शेड्यूल बदलते रहते हैं, इसलिए कैलेंडर के बजाय मेटाडेटा की जाँच करें। यह देरी जानबूझकर की जाती है: जो लोग जल्दी अपग्रेड करते हैं वे समस्याओं (blockers) को ढूंढ लेते हैं, और LTS सर्वरों की बड़ी आबादी के अपग्रेड करने से पहले उन्हें ठीक कर दिया जाता है।

इसके बाद दो ईमानदार विकल्प बचते हैं। पॉइंट रिलीज़ का इंतज़ार करें, जो किसी भी ऐसे सर्वर के लिए सही निर्णय है जिसे आप लगातार मॉनिटर नहीं करना चाहते। या फिर Prompt=normal सेट करें, जो उसी टूल को meta-release की ओर निर्देशित करता है, जहाँ 26.04 पहले से ही समर्थित (supported) के रूप में चिह्नित है। दूसरा रास्ता आपको रिलीज़ हो चुकी 26.04 पर अपग्रेड करता है, न कि किसी डेवलपमेंट बिल्ड पर, इसलिए ऐसी मशीन पर यह उचित है जिसे आप स्नैपशॉट से रिस्टोर कर सकते हैं। काम पूरा होने पर मान (value) को वापस 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 और उसके बाद के वर्जन्स में अधिकांश सोर्सेज deb822 फॉर्मेट में /etc/apt/sources.list.d/ubuntu.sources में रहते हैं। एक ही रिपॉजिटरी का पुराने और नए दोनों फॉर्मेट में लिखा होना एक अलग एरर है जिसका अपना मैसेज है, जिसे deb822 फॉर्मेट में डुप्लीकेट सोर्स एंट्री एरर में कवर किया गया है।

Held और half-configured packages calculation को रोकते हैं

Release upgrade के दौरान सिस्टम के लगभग हर package को move करना पड़ता है। यदि एक भी package move नहीं हो पाता, तो calculation विफल हो जाती है, और upgrader आपको बीच रास्ते में छोड़ने के बजाय प्रक्रिया को जल्दी रोकना बेहतर समझता है। दो commands कारण का पता लगाती हैं।

apt-mark showhold
sudo dpkg --audit

apt-mark showhold held packages को प्रति पंक्ति एक के हिसाब से print करता है, और एक clean सिस्टम पर कुछ भी print नहीं करता। Hold एक manual निर्देश है कि उस package को कभी न बदला जाए। किसी ने kernel या database version को pin किया होगा और फिर भूल गए होंगे। जिन packages की अब आपको आवश्यकता नहीं है, उन्हें sudo apt-mark unhold और उसके बाद package का नाम लिखकर release करें।

dpkg --audit उन packages की सूची देता है जो unpack तो हो गए थे लेकिन configure नहीं हुए। यह स्थिति तब आती है जब installation बीच में ही रुक गई हो, अक्सर session drop होने के कारण। Upgrader इसे ठीक करने का प्रयास करता है और dpkg interrupted, calling dpkg --configure -a print करता है, लेकिन इसे स्वयं ठीक करने का मतलब है कि आप error को पढ़ सकते हैं, बजाय इसके कि वह screen पर तेजी से scroll हो जाए। जिस package को tool ठीक नहीं कर पाता, वह Package in inconsistent state संदेश देता है, और retry करने से पहले उस पर ध्यान देने की आवश्यकता होती है।

Upgrade करने से पहले चल रहे release को पूरी तरह से current बनाएँ।

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 कुछ updates को एक बार में मशीनों के एक निश्चित प्रतिशत तक ही पहुँचाता है, इसलिए एक साधारण apt upgrade packages को पीछे छोड़ सकता है, और सर्वर आपके विश्वास से कम current रह जाता है। वह विकल्प उन सभी को ले आता है। यदि updates के साथ kernel आया हो तो उसके बाद reboot करें, ताकि आप उस kernel से upgrade करें जिसे आप वास्तव में चला रहे हैं। जो मशीन unattended security upgrades के माध्यम से खुद को patch रखती है, उसे यहाँ कम काम करना पड़ता है, हालाँकि वह mechanism design के अनुसार कभी भी release boundary को पार नहीं करता।

जब release standard support की अवधि समाप्त कर ले

एक interim Ubuntu release नौ महीने तक supported रहती है। जब वह support समाप्त हो जाता है, तो उसका Supported: flag 0 पर चला जाता है, और सामान्य path से उससे आगे कोई upgrade नहीं मिलता। 13 August 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 भी move हो जाता है। end of life हो चुकी release के packages को archive.ubuntu.com से हटाकर old-releases.ubuntu.com पर रखा जाता है। इसलिए apt update, 404 Not Found return करना शुरू कर देता है, system को अब current नहीं बनाया जा सकता, और चूंकि upgrader एक current system की मांग करता है, इसलिए प्रक्रिया आगे नहीं बढ़ती। पहले 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 पर point करें, और अपने codename को न बदलें। केवल host name बदलता है।

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

यदि आपका server अभी भी अपने sources को उस एक file में रखता है, तो /etc/apt/sources.list के विरुद्ध वही command चलाएं। -i.bak option original file के बगल में एक backup लिख देता है, ताकि यदि edit गलत file पर किया गया हो तो आप उसे वापस ला सकें। उसके बाद एक clean apt update का मतलब है कि archive फिर से reachable है, और do-release-upgrade अब आपसे बात करेगा।

यह यथार्थवादी रहें कि इससे आप कितनी दूर तक पहुँच पाएंगे। Ubuntu एक बार में एक ही release step को support करता है, इसलिए जो server दो या तीन dead releases पीछे है, उसे हर step को क्रमानुसार पूरा करना होगा, और हर step अपने किसी third party repository या held package पर fail हो सकता है। एक VPS पर अक्सर current LTS पर नया server बनाना, service को उस पर move करना, और पुराने server को तब तक रखना जब तक आप सुनिश्चित न हो जाएं, अधिक तेज़ होता है। यह आपको एक rollback का विकल्प भी देता है, जो in-place upgrade में कभी नहीं मिलता। यदि आप यह चुन रहे हैं कि बाद में किस track पर रहना है, तो server पर LTS और interim releases के बीच का अंतर निर्णय लेने से पहले पढ़ना उचित है।

development release flag वास्तव में क्या करता है

-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) सेशन बंद हो जाए, तो प्रक्रिया समाप्त हो जाती है और पैकेज अनपैक्ड (unpacked) व अनकॉन्फिगर (unconfigured) रह जाते हैं। यही वह स्थिति है जो आपके अगले प्रयास को रोकती है। इसलिए, हर बार अपग्रेड को टर्मिनल मल्टीप्लेक्सर के अंदर ही शुरू करें।

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 वह चीज होगी जो आपके पास नहीं होगी। यदि कर्नल बूट होने में विफल रहता है, तो यह एक अलग समस्या है जिसके अपने रिकवरी चरण हैं, जो a VPS that will not boot after a kernel update में बताए गए हैं।
• df -h / /boot के साथ खाली जगह की जांच करें। अपग्रेड के दौरान पैकेजों का पूरा सेट डाउनलोड होता है, और /boot पार्टीशन, जिसमें कई पुराने कर्नल होते हैं, अक्सर अपग्रेड के रुकने का कारण बनता है।
• अपने द्वारा चलाए जा रहे सर्विसेज के लिए रिलीज नोट्स पढ़ें। PostgreSQL या PHP में मेजर वर्जन जंप रिलीज के साथ ही आता है, चाहे आपने इसकी योजना बनाई हो या नहीं।

FAQ

Ubuntu 24.04 पर do-release-upgrade यह क्यों कहता है कि कोई नया release नहीं मिला?

Prompt=lts में मौजूद डिफ़ॉल्ट /etc/update-manager/release-upgrades के कारण टूल https://changelogs.ubuntu.com/meta-release-lts को पढ़ता है, और Ubuntu 26.04 अपने पहले point release तक उस फ़ाइल में Supported: 0 रखता है। अपग्रेडर को कोई भी नया LTS release उपलब्ध नहीं दिखता, इसलिए वह रुक जाता है। curl -s https://changelogs.ubuntu.com/meta-release-lts के साथ फ़ाइल को स्वयं जाँचें और अंतिम ब्लॉक पढ़ें। 13 अगस्त 2026 को जाँचने पर यह फ्लैग 0 था, जबकि Ubuntu 26.04.1 को 27 अगस्त 2026 के लिए निर्धारित किया गया था।

क्या point release का इंतज़ार करने के बजाय Prompt=normal सेट करना सुरक्षित है?

यह आपको released 26.04 पर अपग्रेड करता है, न कि development build पर, क्योंकि Prompt=normal, meta-release को पढ़ता है, जहाँ 26.04 पहले से ही Supported: 1 के रूप में मौजूद है। जोखिम समय का है। आप उन समस्याओं के ठीक होने से पहले ही अपग्रेड कर रहे हैं जिन्हें शुरुआती अपग्रेडर्स ने पहचाना है। इसे ऐसे सर्वर पर करें जिसे आप स्नैपशॉट से रिस्टोर कर सकें, और जहाँ रीबूट विफल होने पर आप प्रोवाइडर कंसोल तक पहुँच सकें। बाद में मान को वापस lts पर सेट कर दें।

क्या -d फ्लैग मुझे 26.04 पर अपग्रेड करता है?

नहीं। -d, meta-release-development को पढ़ता है, जिसकी नवीनतम प्रविष्टि 13 अगस्त 2026 को Ubuntu 26.10 थी, जो अभी भी development में है। Prompt=lts वाली LTS मशीन पर यह फ्लैग There is no development version of an LTS available. प्रिंट करता है और रुक जाता है। Ubuntu का अपना सर्वर डॉक्यूमेंटेशन कहता है कि development release को प्रोडक्शन के लिए अनुशंसित नहीं किया जाता है, इसलिए जब आप released 26.04 को जल्दी प्राप्त करना चाहते हैं तो Prompt=normal का उपयोग करें।

पुराने release पर apt update 404 त्रुटियाँ क्यों देता है? मैं इसे कैसे अपग्रेड करूँ?

वह release अपने जीवनकाल के अंत (end of life) तक पहुँच चुका है, इसलिए इसके पैकेज 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 इसे एक बार में एक release आगे ले जा सकता है।

क्या do-release-upgrade चलाने से पहले मुझे अपने PPA हटाने की आवश्यकता है?

आपको ऐसा करने की आवश्यकता नहीं है, क्योंकि अपग्रेडर किसी भी ऐसे सोर्स को कमेंट आउट कर देता है जो नए release के लिए प्रकाशित नहीं होता है और प्रत्येक के लिए was disabled (no Release file) जैसी लाइन प्रिंट करता है। इसे स्वयं पहले करना बेहतर है, क्योंकि आप क्रम चुनते हैं और परिणाम देख पाते हैं। उन पैकेजों पर apt policy चलाएँ जिनकी आपको परवाह है ताकि यह पता चल सके कि कौन सा पैकेज किस PPA से आया है, फिर यदि PPA संस्करण नए release से अधिक नया है तो उन्हें आर्काइव से पुनः इंस्टॉल करें।