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

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.

एक्झिट कोड स्क्रिप्टसाठी तेच उत्तर देतो. जेव्हा एखादे release उपलब्ध असते तेव्हा तो 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 ओळीचा अर्थ असा आहे की सर्व्हर metadata पाहू शकतो. curl: (28) Connection timed out चा अर्थ असा आहे की तुमचे egress नियम हेच मूळ कारण आहेत आणि APT (advanced package tool) फाईल्समध्ये कितीही बदल केले तरी उत्तर बदलणार नाही.

जर कमांड पूर्णपणे गहाळ असेल, तर ती ubuntu-release-upgrader-core मध्ये असते. काही वेळा minimal क्लाउड इमेजेसमध्ये ते पॅकेज समाविष्ट नसते.

sudo apt install ubuntu-release-upgrader-core

कोणताही बदल करण्यापूर्वी /etc/update-manager/release-upgrades वाचा

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

या फाईलमध्ये टिप्पणीच्या स्वरूपात स्वतःची कागदपत्रे दिलेली आहेत. खालील तीन मूल्ये वैध आहेत:

• 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) ट्रॅकवर हवा असेल, तर ते बदलून 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 ने अद्याप हा मार्ग खुला केलेला नाही.

जेव्हा पहिले पॉइंट रिलीज येते, तेव्हा हा फ्लॅग बदलून 1 होतो. Ubuntu 26.04.1 हे 27 ऑगस्ट 2026 साठी नियोजित आहे, परंतु रिलीजचे वेळापत्रक बदलू शकते, त्यामुळे कॅलेंडरवर अवलंबून राहण्याऐवजी मेटाडेटा तपासा. हा विलंब मुद्दाम केला जातो: जे लोक लवकर अपग्रेड करतात त्यांना तांत्रिक अडचणी (blockers) आढळतात आणि LTS सर्व्हरच्या मोठ्या समूहाने अपग्रेड करण्यापूर्वी त्या सोडवल्या जातात.

यामुळे दोन प्रामाणिक पर्याय उरतात. पॉइंट रिलीजची वाट पहा, जे सर्व्हरवर सतत लक्ष ठेवू इच्छित नसलेल्यांसाठी योग्य आहे. किंवा Prompt=normal सेट करा, जे त्याच टूलला meta-release कडे निर्देशित करते, जिथे 26.04 आधीच समर्थित (supported) म्हणून चिन्हांकित आहे. दुसरा मार्ग तुम्हाला रिलीज झालेल्या 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 आणि अर्धवट कॉन्फिगर केलेली पॅकेजेस अपग्रेड प्रक्रियेत अडथळा ठरतात

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

जेव्हा एखादी release मानक सपोर्टच्या कालावधीबाहेर जाते

Ubuntu ची interim release नऊ महिन्यांसाठी सपोर्ट केली जाते. जेव्हा तो सपोर्ट संपतो, तेव्हा तिचा 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

त्याच वेळी आर्काइव्ह देखील हलवले जाते. ज्या release चा कालावधी संपला आहे, तिची पॅकेजेस 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 कडे निर्देशित करा आणि तुमच्या कोडनेममध्ये बदल करू नका. फक्त होस्टचे नाव बदला.

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 एका वेळी एकच release स्टेप सपोर्ट करते, त्यामुळे दोन किंवा तीन जुन्या release मागे असलेला सर्व्हर प्रत्येक टप्प्यावर अपडेट करावा लागतो. प्रत्येक टप्प्यावर थर्ड-पार्टी रिपॉझिटरी किंवा होल्ड केलेले पॅकेज यामुळे अपयश येऊ शकते. VPS वर नवीन सर्व्हर सध्याच्या LTS वर तयार करणे, सर्व्हिस त्यावर हलवणे आणि खात्री होईपर्यंत जुना सर्व्हर तसाच ठेवणे हे अनेकदा जलद असते. यामुळे तुम्हाला रोलबॅकचा पर्याय मिळतो, जो इन-प्लेस अपग्रेडमध्ये कधीच मिळत नाही. त्यानंतर कोणत्या ट्रॅकवर राहायचे हे निवडत असाल, तर सर्व्हरवरील 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 सेशन खंडित झाले तरी अपग्रेड सुरू राहील अशी व्यवस्था करणे

रिलीज अपग्रेडमध्ये openssh-server आणि systemd सह सिस्टिमचे बहुतेक भाग बदलले जातात. जर dpkg काम करत असताना तुमचे SSH (secure shell) सेशन बंद पडले, तर प्रक्रिया थांबते आणि पॅकेजेस अर्धवट अनपॅक किंवा अनकॉन्फिगर राहतात. यामुळे पुढच्या वेळी अपग्रेड करण्याचा प्रयत्न करताना अडथळे येतात. त्यामुळे प्रत्येक वेळी टर्मिनल मल्टिप्लेक्सरमध्येच अपग्रेड सुरू करा.

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 वापरत असाल, तर ही शोध प्रक्रिया मल्टिप्लेक्सर सर्व्हरपर्यंत पोहोचते, त्यामुळे तो पर्याय दिसत नाही. जेव्हा अतिरिक्त डेमन खरोखर सुरू होतो, तेव्हाच /var/run/release-upgrader-sshd.pid ही pid फाईल तयार केली जाते. जर तुम्हाला तो प्रॉम्प्ट दिसत नसेल, तर काहीही चुकीचे नाही; तुमच्याकडे आधीच अधिक चांगली सुरक्षा आहे.

जर तुम्ही तो पर्याय स्वीकारला, तर पोर्ट आपोआप उघडले जात नाही. टूल हे स्पष्टपणे सांगते, कारण पोर्ट उघडणे हा सुरक्षेचा निर्णय आहे जो तुमच्या वतीने घेणे टूलच्या अधिकारात नाही. अपग्रेड सुरू असेपर्यंत ते पोर्ट उघडा आणि काम झाल्यावर पुन्हा बंद करा.

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

बहुतेक VPS प्रोव्हाइडर्स ऑपरेटिंग सिस्टिमच्या बाहेर, त्यांच्या कंट्रोल पॅनेलमध्ये दुसरे फायरवॉल चालवतात. तिथेही पोर्ट 1022 उघडे असणे आवश्यक आहे, अन्यथा फॉलबॅक लिसनर सुरू असूनही पोहोचण्यायोग्य नसेल, जी सर्वात वाईट स्थिती आहे.

कमांड टाईप करण्यापूर्वी खालील चार गोष्टींची खात्री करा:

• स्नॅपशॉट किंवा पूर्ण बॅकअप घ्या. इन-प्लेस रिलीज अपग्रेडमध्ये बदल मागे घेता येत नाहीत (undo), त्यामुळे हाच एकमेव पर्याय आहे.
• गरज पडण्यापूर्वी तुमच्या प्रोव्हाइडरचा कन्सोल उघडू शकतो का, याची खात्री करा. जर रीबूटनंतर सर्व्हर सुरू झाला नाही, तर SSH चा वापर करता येणार नाही. कर्नल बूट न होणे ही एक वेगळी समस्या आहे आणि त्यासाठीच्या रिकव्हरी स्टेप्स कर्नल अपडेटनंतर बूट न होणारा VPS मध्ये दिल्या आहेत.
• df -h / /boot वापरून मोकळी जागा तपासा. अपग्रेडसाठी पॅकेजेसचा पूर्ण संच डाउनलोड करावा लागतो आणि अनेक जुन्या कर्नल्समुळे /boot पार्टिशन भरलेले असणे ही अपग्रेड थांबण्याचे एक सामान्य कारण आहे.
• तुम्ही चालवत असलेल्या सेवांसाठी रिलीज नोट्स वाचा. PostgreSQL किंवा PHP मधील मेजर व्हर्जन बदल अपग्रेडसोबत येतातच, मग तुम्ही त्यासाठी नियोजन केले असो वा नसो.

FAQ

Why does do-release-upgrade say no new release found on Ubuntu 24.04?

The default Prompt=lts in /etc/update-manager/release-upgrades makes the tool read https://changelogs.ubuntu.com/meta-release-lts, and Ubuntu 26.04 carries Supported: 0 in that file until its first point release. The upgrader finds no newer LTS release marked available, so it stops. Check the file yourself with curl -s https://changelogs.ubuntu.com/meta-release-lts and read the last block. Checked on 13 August 2026 the flag was still 0, with Ubuntu 26.04.1 scheduled for 27 August 2026.

Is it safe to set Prompt=normal instead of waiting for the point release?

It upgrades you to the released 26.04, not to a development build, because Prompt=normal reads meta-release, where 26.04 already carries Supported: 1. The timing is the risk. You are going before the blockers found by early upgraders have been fixed. Do it on a server you can restore from a snapshot, and where you can reach the provider console if the reboot goes wrong. Set the value back to lts afterwards.

Does the -d flag upgrade me to 26.04?

No. -d reads meta-release-development, whose newest entry on 13 August 2026 was Ubuntu 26.10, a release still in development. On an LTS machine with Prompt=lts the flag prints There is no development version of an LTS available. and stops. Ubuntu's own server documentation says the development release is not recommended for production, so use Prompt=normal when you want a released 26.04 early.

apt update returns 404 errors on an old release. How do I upgrade it?

That release has reached end of life, so its packages were moved from archive.ubuntu.com to old-releases.ubuntu.com. Change only the host names in /etc/apt/sources.list.d/ubuntu.sources, or in /etc/apt/sources.list on older layouts, and keep your codename as it is. Then run sudo apt update and sudo apt full-upgrade. Once the system is current again, do-release-upgrade can move it forward one release at a time.

Do I need to remove my PPAs before running do-release-upgrade?

You do not have to, because the upgrader comments out any source that does not publish for the new release and prints a line such as was disabled (no Release file) for each one. Doing it yourself first is better, since you choose the order and you see the result. Run apt policy on the packages you care about to find which ones came from each PPA, then reinstall those from the archive if the PPA version is newer than the new release carries.