Ubuntu: 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) आहे. हे Canonical चे release मेटाडेटा HTTPS (hypertext transfer protocol secure) द्वारे वाचते आणि उत्तर प्रिंट करते. हे कोणतेही अपग्रेड टूल डाउनलोड करत नाही आणि कोणतीही सोर्स फाईल बदलत नाही. दोन आउटपुट महत्त्वाचे आहेत:

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) दिलेल्या आहेत. यामध्ये तीन मूल्ये वैध आहेत:

• 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 सेट करतात, जेणेकरून सर्व्हरच्या ताफ्याला (fleet) रिलीज दरम्यान बदलण्यापासून रोखता येईल. जर तुम्हाला ते तिथे आढळले, तर ते कोणीतरी निवडलेले असते. जर तुम्हाला सर्व्हर दीर्घकालीन सपोर्ट (LTS) ट्रॅकवर हवा असेल, तर ते 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 हाच मुख्य अडथळा आहे. डिफॉल्ट Prompt=lts वापरणारा 24.04 सर्व्हर ती फाइल वाचतो, त्याला नवीन 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 नसते. ती सुरुवातीपासून झालेले सर्व updates नव्या install media मध्ये समाविष्ट असलेली तीच release असते. त्यामुळे चालू server साठी महत्त्वाचे media स्वतः नसून त्यातून खुले होणारे gate असते. हा विलंब जाणीवपूर्वक ठेवला जातो. लवकर upgrade करणाऱ्या वापरकर्त्यांना अडथळे आढळतात. मोठ्या संख्येने LTS servers upgrade करण्यापूर्वी ते अडथळे दूर केले जातात. तुम्ही हे वाचत असताना ती तारीख निघून गेली असल्यास, 26.04.1 मध्ये काय समाविष्ट होते आणि त्याचा 24.04 server साठी काय अर्थ आहे यापासून पुढील माहिती सुरू होते.

यामुळे दोन प्रामाणिक पर्याय उरतात. तुम्हाला ज्याच्यावर सतत लक्ष ठेवावे लागू नये अशा कोणत्याही सर्व्हरसाठी point release ची प्रतीक्षा करणे हा योग्य पर्याय आहे. किंवा Prompt=normal सेट करा. यामुळे तेच साधन meta-release कडे निर्देशित होते, जिथे 26.04 आधीच समर्थित म्हणून चिन्हांकित आहे. दुसऱ्या पर्यायामुळे तुम्ही development build वर नव्हे, तर release झालेल्या 26.04 वर upgrade करता. त्यामुळे snapshot मधून पुनर्संचयित करता येणाऱ्या मशीनवर हा पर्याय योग्य ठरतो. काम पूर्ण झाल्यावर मूल्य पुन्हा lts वर सेट करा. या प्रक्रियेचे step-by-step वर्णन 24.04 ते 26.04 सर्व्हर upgrade करण्याच्या संपूर्ण मार्गदर्शकात दिले आहे. अजूनही 22.04 वर असलेल्या सर्व्हरला एक अतिरिक्त टप्पा पार करावा लागतो, कारण 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 आणि अर्धवट कॉन्फिगर केलेली पॅकेजेस अपग्रेड प्रक्रियेत अडथळा ठरतात

सिस्टमवरील जवळजवळ प्रत्येक पॅकेज हलवणे हे रिलीज अपग्रेडचे काम असते. जर एखादे पॅकेज हलवता आले नाही, तर गणना (calculation) अयशस्वी होते आणि सिस्टिम अर्धवट स्थितीत सोडण्यापेक्षा अपग्रेडर प्रक्रिया थांबवणे पसंत करतो. दोन कमांड्स या समस्येचे मूळ शोधण्यास मदत करतात.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold कमांड प्रत्येक ओळीवर एक याप्रमाणे 'held' पॅकेजेसची यादी दाखवते; जर सिस्टिम व्यवस्थित असेल तर ही कमांड काहीही आउटपुट देत नाही. 'Hold' म्हणजे त्या पॅकेजमध्ये कोणताही बदल करू नये अशी दिलेली मॅन्युअल सूचना असते. कदाचित कोणीतरी कर्नल किंवा डेटाबेसची आवृत्ती पिन केली असेल आणि नंतर ती काढायला विसरले असेल. ज्या पॅकेजेसची आता गरज नाही, ती sudo apt-mark unhold आणि त्यानंतर पॅकेजचे नाव देऊन 'release' करा.

dpkg --audit कमांड अशी पॅकेजेस दाखवते जी अनपॅक झाली आहेत पण कॉन्फिगर झालेली नाहीत. ही स्थिती सहसा इन्स्टॉलेशन प्रक्रियेत व्यत्यय आल्यामुळे निर्माण होते, बहुतेकदा सेशन डिस्कनेक्ट झाल्यामुळे असे घडते. अपग्रेडर ही त्रुटी दुरुस्त करण्याचा प्रयत्न करतो आणि dpkg interrupted, calling dpkg --configure -a असा संदेश देतो, परंतु तुम्ही स्वतः ही दुरुस्ती आधीच केल्यास, तुम्हाला त्रुटीचा संदेश स्पष्टपणे वाचता येईल. जर एखादे पॅकेज टूलद्वारे दुरुस्त होऊ शकत नसेल, तर ते Package in inconsistent state हा संदेश देते; अशा पॅकेजवर पुन्हा प्रयत्न करण्यापूर्वी लक्ष देणे आवश्यक आहे.

अपग्रेड करण्यापूर्वी सध्याची रिलीज पूर्णपणे अद्ययावत (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 काही अपडेट्स एका वेळी ठराविक टक्के मशीनवरच लागू करते, त्यामुळे साधे 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 वाचतो. मॅन्युअल पेजमध्ये याचे वर्णन "जर तुम्ही नवीनतम समर्थित रिलीज वापरत असाल, तर डेव्हलपमेंट रिलीजवर अपग्रेड करा" असे केले आहे.

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 बंद झाले, तर packages unpacked आणि unconfigured अवस्थेत असतानाच process बंद होतो. हीच अवस्था पुढील प्रयत्नाला अडथळा आणते. असे आधीच झाले असल्यास, अर्ध्यावर थांबलेला 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 ही 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 'no new release found' असे का दाखवते?

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 असते. यात वेळेचा धोका असतो. सुरुवातीच्या अपग्रेडर्सना आढळलेल्या त्रुटी (blockers) दुरुस्त होण्यापूर्वीच तुम्ही अपग्रेड करत असता. हे अशा सर्व्हरवर करा ज्याचा तुम्ही स्नॅपशॉटवरून रिस्टोर करू शकता आणि जिथे रीबूट अयशस्वी झाल्यास तुम्ही प्रोव्हायडर कन्सोलपर्यंत पोहोचू शकता. त्यानंतर व्हॅल्यू पुन्हा 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 एरर का देते? मी ते अपग्रेड कसे करू?

त्या रिलीजचे आयुष्य संपले आहे (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 मधून आले आहेत ते शोधा, आणि जर PPA मधील व्हर्जन नवीन रिलीजपेक्षा जास्त असेल, तर ते आर्काइव्हमधून पुन्हा इन्स्टॉल करा.