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

Why do-release-upgrade यह क्यों कहता है कि कोई नया release नहीं मिला

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

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

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

sudo do-release-upgrade -c
echo $?

-c का अर्थ है केवल जाँच करना। यह HTTPS (hypertext transfer protocol secure) के माध्यम से Canonical के release मेटाडेटा को पढ़ता है और उत्तर प्रिंट करता है। यह किसी अपग्रेड टूल को डाउनलोड नहीं करता है और न ही किसी सोर्स फाइल को फिर से लिखता है। दो आउटपुट महत्वपूर्ण हैं:

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

इस फाइल में टिप्पणियों (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 सेट करते हैं, ताकि रिलीज के बीच सिस्टम के भटकने (drift) को रोका जा सके। यदि आपको यह वहां मिलता है, तो किसी ने इसे चुना है। यदि आप सर्वर को लॉन्ग टर्म सपोर्ट ट्रैक पर रखना चाहते हैं, तो इसे 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 को पढ़ता है। दोनों फ़ाइलें हर रिलीज़ का विवरण कुंजियों (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 ने अभी तक यह रास्ता नहीं खोला है।

पहली point release जारी होने पर flag 1 में बदल जाता है। Ubuntu 26.04.1 के 27 August 2026 को जारी होने का schedule है, और release schedules बदल सकते हैं, इसलिए calendar के बजाय metadata जाँचें। Point release, Ubuntu का नया version नहीं होता। यह केवल वही release होता है जिसमें launch के बाद के सभी updates को नई install media में शामिल किया गया होता है, इसलिए चल रहे server के लिए महत्वपूर्ण बात media स्वयं नहीं, बल्कि उससे खुलने वाला gate है। यह delay जानबूझकर रखा जाता है: जो लोग जल्दी upgrade करते हैं, वे blockers खोजते हैं, और बड़ी संख्या में LTS servers के upgrade करने से पहले उन समस्याओं को ठीक कर दिया जाता है। यदि आपके पढ़ने तक वह date बीत चुकी है, तो 26.04.1 में क्या जारी हुआ और 24.04 server के लिए उसका क्या अर्थ है आगे की जानकारी देता है।

इससे दो ईमानदार विकल्प बचते हैं। Point release का इंतजार करें। यह उस हर server के लिए सही विकल्प है जिसकी लगातार निगरानी आप नहीं करना चाहते। या Prompt=normal सेट करें। इससे वही tool meta-release पर निर्देशित होता है, जहाँ 26.04 को पहले ही supported चिह्नित किया जा चुका है। दूसरे विकल्प से आपको released 26.04 पर upgrade किया जाता है, development build पर नहीं। इसलिए snapshot से restore किए जा सकने वाले machine पर यह निर्णय उचित है। काम पूरा होने पर value को वापस lts पर सेट करें। पूरी procedure, step by step, 24.04 से 26.04 तक server upgrade की पूरी मार्गदर्शिका में दी गई है। 22.04 पर चल रहे server को एक अतिरिक्त hop करना होगा, क्योंकि Prompt=lts केवल अगली LTS release की पेशकश करता है। इसलिए 22.04 से 26.04 तक का रास्ता पहले 24.04 से होकर जाता है।

Third party repositories और PPA जो अपग्रेड को रोकते हैं

Upgrader आपके APT sources को नए release की ओर इंगित करने के लिए फिर से लिखता है। यह केवल उन repositories के लिए ऐसा कर सकता है जो नए release के लिए publish करते हैं, इसलिए बाकी सभी को comment out कर दिया जाता है। इसके कारण प्रति entry एक लाइन में प्रिंट किए जाते हैं, और वे विशिष्ट होते हैं: was disabled (unknown mirror), was disabled (unknown dist), और was disabled (no Release file)।

noble के लिए बनाया गया PPA (personal package archive) सर्वर पर resolute के लिए कोई directory नहीं रखता है, इसलिए upgrader नई series के लिए Release file प्राप्त नहीं कर सकता और उस entry को disable कर देता है। यह आमतौर पर एक ऐसी चेतावनी है जिसे आप स्वीकार कर सकते हैं। यह तब एक रुकावट बन जाता है जब कोई third party repository ऐसा package प्रदान करता है जिसे नया release भी ship करता है, क्योंकि तब upgrade calculation के पास दो विकल्प होते हैं और दोनों को संतुष्ट करने का कोई तरीका नहीं होता।

लंबे समय तक चलने वाले unattended run के दौरान tool को निर्णय लेने देने के बजाय, शुरू करने से पहले आप स्वयं निर्णय लें।

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

किसी package नाम पर apt policy चलाने से यह प्रिंट होता है कि प्रत्येक installed version किस repository से आया है, ताकि आप ठीक से देख सकें कि कौन से packages उस source पर निर्भर हैं जिसे आप disable करने वाले हैं। Source को हटाने से कोई भी चीज़ downgrade नहीं होती है, इसलिए PPA से install किया गया package अपने PPA version पर ही रहता है और नए release में मौजूद version से नया हो सकता है। जहाँ यह मायने रखता है, वहाँ package को भी हटा दें, और upgrade के बाद उसे archive से फिर से install करें। जिस repository को आप वापस लाना चाहते हैं, जैसे कि Tailscale, उसके codename को नए release के अनुसार update करने की आवश्यकता होती है, तभी package फिर से install होगा; यही कारण है कि Ubuntu पर अधिकांश Tailscale install errors इसी वजह से होती हैं।

विपरीत विकल्प के लिए एक flag मौजूद है। Manual page --allow-third-party का वर्णन इस प्रकार करता है: "Third party mirrors और repositories को comment out करने के बजाय उन्हें enable रखकर upgrade का प्रयास करें।" इसका उपयोग केवल तभी करें जब आपने पुष्टि कर ली हो कि repository पहले से ही target release के लिए publish कर रहा है। यदि ऐसा नहीं है, तो आपने APT से एक ऐसी series के विरुद्ध dependency graph हल करने के लिए कहा है जिसके लिए उस repository ने कभी build नहीं किया है।

Ubuntu 24.04 और उसके बाद के संस्करणों में अधिकांश sources deb822 format में /etc/apt/sources.list.d/ubuntu.sources में रहते हैं। एक ही repository का पुराने और नए दोनों format में लिखा होना एक अलग त्रुटि है जिसका अपना संदेश है, जिसे deb822 format में duplicate source entry error में कवर किया गया है।

Held और half-configured packages गणना को रोकते हैं

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

apt-mark showhold
sudo dpkg --audit

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

dpkg --audit उन packages की सूची देता है जो unpack तो हो गए थे लेकिन configure नहीं हुए। यह स्थिति तब आती है जब install प्रक्रिया बीच में ही रुक गई हो, अक्सर session drop होने के कारण। Upgrader इसे ठीक करने का प्रयास करता है और dpkg interrupted, calling dpkg --configure -a प्रिंट करता है, लेकिन repair को स्वयं पहले चलाने का मतलब है कि आप error को पढ़ सकते हैं, बजाय इसके कि वह स्क्रीन पर तेजी से निकल जाए। जिस 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 रह जाता है। वह विकल्प उन सभी को ले आता है। यदि उनके साथ कोई kernel आया हो तो बाद में reboot करें, ताकि आप उस kernel से upgrade करें जिसे आप वास्तव में चला रहे हैं। जो सर्वर unattended security upgrades के माध्यम से खुद को patch रखता है, उसे यहाँ कम काम करना पड़ता है, हालाँकि वह mechanism डिज़ाइन के अनुसार कभी भी 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 मूल file के बगल में एक backup लिखता है, ताकि यदि edit गलत file पर किया गया हो तो आप उसे वापस ला सकें। उसके बाद एक clean apt update का मतलब है कि archive फिर से reachable है, और do-release-upgrade अब आपसे बात करेगा।

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

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 सेशन टूटने से वह बाधित न हो

Release upgrade openssh-server और systemd सहित system के अधिकांश हिस्से को बदल देता है। यदि dpkg के काम करते समय आपका SSH (secure shell) session बंद हो जाता है, तो process packages को unpacked और unconfigured स्थिति में छोड़कर समाप्त हो जाता है। यही स्थिति आपके अगले प्रयास को रोकती है। यदि ऐसा पहले ही हो चुका है, तो आधे रास्ते में रुके upgrade को recover करना एक अलग कार्य है। इसे दूसरे प्रयास से पहले पूरा करें। हर बार upgrade को 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 भी वही काम करते हैं।

अपग्रेडर उन लोगों के लिए अपनी सुरक्षा व्यवस्था रखता है जो मल्टीप्लेक्सर का उपयोग नहीं करते हैं। जब यह पता चलता है कि यह 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 को वहां भी खुला होना चाहिए, अन्यथा फॉलबैक लिसनर चल तो रहा होगा लेकिन उस तक पहुँचा नहीं जा सकेगा, जो कि सबसे खराब स्थिति है।

कमांड टाइप करने से पहले ये चार चीजें सुनिश्चित करें:

• स्नैपशॉट या पूर्ण बैकअप लें। इन-प्लेस रिलीज अपग्रेड को अनडू नहीं किया जा सकता, और यह आपका एकमात्र मौका है।
• पुष्टि करें कि आप जरूरत पड़ने पर अपने प्रदाता के कंसोल को खोल सकते हैं। यदि रीबूट के बाद सर्वर वापस नहीं आता है, तो 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 August 2026 को जाँचने पर यह फ्लैग 0 था, जबकि Ubuntu 26.04.1 को 27 August 2026 के लिए निर्धारित किया गया था।

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

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

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

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

पुराने रिलीज़ पर apt update करने पर 404 एरर क्यों आते हैं? मैं इसे कैसे अपग्रेड करूँ?

वह रिलीज़ अपने जीवनकाल के अंत (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 इसे एक बार में एक रिलीज़ आगे ले जा सकता है।

क्या do-release-upgrade चलाने से पहले मुझे अपने PPA हटाने होंगे?

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