Ubuntu 24.04 से 26.04 पर अपग्रेड कैसे करें

Ubuntu 24.04 को 26.04 में कब अपग्रेड किया जा सकता है?

आप अब VPS पर Ubuntu 24.04 को 26.04 में अपग्रेड कर सकते हैं। 29 सितंबर 2026 से, जब Canonical ने 24.04 LTS से अपग्रेड सक्षम किया, तब 24.04 सर्वर पर do-release-upgrade, 26.04.1 का विकल्प देता है। Ubuntu 26.04 LTS (Resolute Raccoon) को 23 अप्रैल 2026 को रिलीज़ किया गया था, लेकिन Canonical LTS से LTS अपग्रेड का रास्ता केवल पहली पॉइंट रिलीज़ के बाद ही खोलता है, क्योंकि वह रिलीज़ शुरुआती महीनों में मिले इंस्टॉलेशन और अपग्रेड संबंधी बग्स को ठीक कर देती है। इस बार प्रतीक्षा पॉइंट रिलीज़ के बाद तक चली: 26.04.1 को 27 अगस्त 2026 को जारी किया गया था, और Canonical ने rust-coreutils के हालिया संस्करण में रिग्रेशन को ठीक करने वाले नियोजित बैकपोर्ट्स के लिए अपग्रेड को कुछ और हफ्तों तक रोक कर रखा। यदि यह नंबरिंग आपके लिए नई है, तो 26.04.1 कोई अलग Ubuntu नहीं है, बल्कि वही 26.04 है जिसमें चार महीनों के सुधार शामिल हैं, और यही कारण है कि यह पहला संस्करण है जिसे Canonical मौजूदा सर्वर पर उपलब्ध कराता है।

29 सितंबर तक, 24.04 बॉक्स पर चेक चलाने पर आपको यह परिणाम मिलता था:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

यह सर्वर पर कोई खराबी नहीं थी, और यदि आपको आज भी यह दिखाई देता है, तो उस सेटिंग की जाँच करें जिस पर यह निर्भर करता है। /etc/update-manager/release-upgrades में Ubuntu Server पर Prompt=lts होता है, जिसका अर्थ है कि टूल केवल अगले लॉन्ग टर्म सपोर्ट रिलीज़ का विकल्प देता है, और वह भी केवल तब जब Canonical ने उसके लिए रास्ता खोल दिया हो। इसे वैसे भी lts पर ही रहने दें, क्योंकि बाद के रिलीज़ पर normal अल्पकालिक अंतरिम संस्करणों (interim versions) का भी विकल्प देगा। प्रतीक्षा अवधि के दौरान Canonical ने उन लोगों के लिए do-release-upgrade -d की पेशकश की थी जो रुकना नहीं चाहते थे; अब जब रास्ता खुल गया है, तो सर्वर के लिए इसकी घोषणा में दिया गया साधारण कमांड ही सही है। शुरू करने से पहले 26.04.1 में क्या बदलाव हुए और अपग्रेड का रास्ता कब खुला पढ़ें। 22.04 पर चल रहा सर्वर सीधे इस जंप को नहीं ले सकता, क्योंकि अपग्रेडर केवल अगले LTS का विकल्प देता है, इसलिए 22.04 से 24.04 के माध्यम से 26.04 में अपग्रेड करना पहले चरण और दूसरे चरण से पहले लिए जाने वाले स्नैपशॉट को कवर करता है।

नीचे दिया गया प्रत्येक कमांड वह है जिसे आप स्वयं, अपने सर्वर पर, दिए गए क्रम में चलाते हैं। रिलीज़ अपग्रेड का पूर्वाभ्यास उस मशीन पर नहीं किया जा सकता जिसे आप अपग्रेड कर रहे हैं। यह कर्नल और C लाइब्रेरी को बदल देता है, और इसे पूरा करने के लिए रीबूट की आवश्यकता होती है।

क्या आपको अपग्रेड करना चाहिए?

Ubuntu 24.04 को 2029 तक मानक सुरक्षा अपडेट मिलते रहेंगे, इसलिए एक कार्यशील प्रोडक्शन सर्वर पर कोई समय सीमा का दबाव नहीं है। अपग्रेड तभी करें जब आपको ऐसी किसी चीज़ की आवश्यकता हो जो 26.04 में उपलब्ध है: जैसे PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 या 7.0 kernel। "वर्जन नंबर बढ़ गया है" यह किसी ऐसे सर्वर को छेड़ने का कारण नहीं है जो ग्राहकों को सेवा दे रहा है।

यदि निम्नलिखित में से कोई भी स्थिति सत्य है, तो इन-प्लेस अपग्रेड न करें:

• आपने कभी अपने प्रदाता के कंसोल (VNC या serial) को खोलकर उसमें लॉग इन नहीं किया है। यदि SSH टूट जाता है, तो वह कंसोल ही सर्वर तक पहुँचने का एकमात्र रास्ता है, और यह पता चलना कि वह काम नहीं कर रहा है, तब बहुत देर हो चुकी होगी जब आप बाहर लॉक हो चुके होंगे।
• आप एक घंटे का डाउनटाइम वहन नहीं कर सकते और आपके पास रोलबैक की कोई व्यवस्था नहीं है।
• आपका स्टैक किसी ऐसे थर्ड-पार्टी रिपॉजिटरी पर निर्भर है जिसने अभी तक resolute के लिए पब्लिश नहीं किया है।
• सर्वर को दो साल से अधिक समय में मैन्युअल रूप से बनाया गया था और किसी को यह नहीं पता कि उस पर क्या-क्या कॉन्फ़िगर है।

अक्सर दूसरा विकल्प बेहतर होता है: एक नया 26.04 VPS बनाएँ, अपना स्टैक इंस्टॉल करें और डेटा रिस्टोर करें, फिर जब वह सही ढंग से काम करने लगे तो DNS स्विच कर दें। आप पुराने सर्वर को तब तक चालू रखते हैं जब तक नया सर्वर खुद को साबित न कर दे, और रोलबैक के लिए रिस्टोर करने के बजाय केवल DNS बदलना पड़ता है। यदि आप इस रास्ते पर चलते हैं, तो नए VPS पर शुरुआती दस मिनट से शुरुआत करें और नए सर्वर को सही तरीके से तैयार करें।

चरण 1: ऐसा बैकअप लें जिसे आप रिस्टोर कर सकें

दो स्तरों (layers) का उपयोग करें, क्योंकि वे अलग-अलग तरीकों से विफल होते हैं। एक प्रोवाइडर स्नैपशॉट पूरी डिस्क को कवर करता है और मिनटों में रिस्टोर हो जाता है, लेकिन यह तब लिया जाता है जब आपके डेटाबेस लिख रहे होते हैं, इसलिए यह एप्लिकेशन कंसिस्टेंट होने के बजाय क्रैश कंसिस्टेंट होता है। restic, सर्वर से बाहर स्टोर किया गया के साथ फाइल-लेवल बैकअप आपको सिंगल फाइलें देता है और एक ऐसी कॉपी प्रदान करता है जो आपके अकाउंट के लॉक होने पर भी सुरक्षित रहती है।

सबसे पहले डेटाबेस को मैन्युअल रूप से डंप करें। रनिंग डेटाबेस का बैकअप लेने का एक तरीका डंप है।

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction केवल InnoDB टेबल्स के लिए कंसिस्टेंट डंप देता है। MyISAM टेबल्स को कंसिस्टेंट डंप के लिए लॉक की आवश्यकता होती है। /etc टारबॉल वह है जिसे आप वास्तव में उपयोग करेंगे, क्योंकि इसमें वे सभी कॉन्फ़िगरेशन फाइलें होती हैं जिनके बारे में अपग्रेड आपसे प्रश्न पूछेगा।

जिस बैकअप को आपने कभी रिस्टोर नहीं किया है, वह केवल एक अनुमान है। अभी, दबाव में जरूरत पड़ने से पहले, उसमें से एक फाइल निकाल कर देखें।

चरण 2: पहले 24.04 को पूरी तरह से पैच करें

do-release-upgrade टूटी हुई पैकेज स्थिति वाले सिस्टम पर चलने से इनकार कर देता है, और आधा पैच किया गया 24.04 बाद की हर विफलता को समझना कठिन बना देता है।

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit के कुछ भी न दिखाने का मतलब है कि कोई भी पैकेज आधा कॉन्फ़िगर नहीं है। apt-mark showhold के कुछ भी न दिखाने का मतलब है कि किसी भी पैकेज पर dpkg होल्ड नहीं लगा है। यह APT प्रिफरेंस पिन्स को नहीं दिखाता है, जो एक अलग तंत्र है और पैकेज को रोक कर रख सकता है; चरण 3 उनकी जाँच करता है। showhold जो भी लिस्ट करता है उसे sudo apt-mark unhold और पैकेज नाम के साथ रिलीज़ करें, या यह स्वीकार करें कि होल्ड किसी कारण से है और यहीं रुक जाएं।

यदि कर्नेल बदल गया है तो रीबूट करें, ताकि आप उस मशीन से अपग्रेड करें जो उस कोड पर चल रही है जिसे वह अपना मानती है।

[ -f /var/run/reboot-required ] && sudo reboot

फिर डिस्क स्पेस की जाँच करें। अपग्रेडर कुछ भी इंस्टॉल करने से पहले नए पैकेज सेट को पूरी तरह से डाउनलोड करता है, और यदि पर्याप्त जगह नहीं है तो यह फाइलसिस्टम का नाम बताते हुए एक संदेश के साथ रुक जाता है।

df -h / /boot

पुराने कर्नेल आमतौर पर इसका कारण होते हैं, और sudo apt --purge autoremove उन्हें हटा देता है।

शुरू करने से पहले एक और बात: यदि स्वचालित सुरक्षा अपडेट रन के बीच में शुरू होते हैं तो वे dpkg लॉक को होल्ड कर लेते हैं, और रिलीज़ अपग्रेडर Could not get lock /var/lib/dpkg/lock-frontend के साथ रुक जाता है। पहले sudo systemctl stop unattended-upgrades चलाएं और काम पूरा होने पर इसे फिर से शुरू करें।

चरण 3: थर्ड-पार्टी रिपॉजिटरी और पिन किए गए पैकेज की जाँच करें

डिफ़ॉल्ट रूप से, do-release-upgrade हर उस apt सोर्स को कमेंट आउट कर देता है जो Ubuntu का नहीं है, क्योंकि noble के लिए बना पैकेज resolute सिस्टम को खराब कर सकता है। इसका --allow-third-party विकल्प उन्हें इनेबल रखता है, जिसमें यही जोखिम बना रहता है। टूल द्वारा आपके लिए निर्णय लेने से पहले यह जान लें कि आप क्या उपयोग कर रहे हैं।

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 उस डायरेक्टरी में दो फॉर्मेट का उपयोग करता है: पुराने एक-लाइन वाले .list फाइलें, और Types: तथा Suites: फील्ड्स वाले deb822 .sources फाइलें। डिफ़ॉल्ट अपग्रेड द्वारा दोनों को डिसेबल कर दिया जाता है। ubuntu-security-status --thirdparty उन इंस्टॉल किए गए पैकेजों की सूची देता है जो किसी भी Ubuntu आर्काइव में उपलब्ध नहीं हैं, जो यह दर्शाता है कि आपने वास्तव में क्या अतिरिक्त जोड़ा है। /etc/apt/preferences.d/ में कोई फाइल पिन के रूप में तभी पढ़ी जाती है यदि उसके नाम में कोई एक्सटेंशन न हो या वह .pref पर समाप्त हो और उसमें केवल अक्षर, अंक, हाइफ़न, अंडरस्कोर और पीरियड हों; APT किसी भी अन्य फाइल को अनदेखा कर देता है, आमतौर पर एक सूचना के साथ। एक पिन जो noble को नाम देता है, वह अपग्रेड के बाद भी पैकेज को पुराने वर्जन पर रख सकता है, जो इस पर निर्भर करता है कि कौन से वर्जन अभी भी उपलब्ध हैं और पिन क्या प्राथमिकता सेट करता है, इसलिए प्रत्येक फाइल को पढ़ें और तय करें कि क्या वह अभी भी आवश्यक है।

प्रत्येक थर्ड-पार्टी रिपॉजिटरी के लिए, शुरू करने से पहले पुष्टि करें कि वेंडर ने नए कोडनेम के लिए पब्लिश किया है या नहीं। Docker की सूइट्स https://download.docker.com/linux/ubuntu/dists/ पर सूचीबद्ध हैं, और अन्य वेंडर भी इसी तरह की डायरेक्टरी दिखाते हैं। अपग्रेड के बाद पहले apt update पर, ऐसी सूइट की ओर इशारा करने वाला सोर्स जो मौजूद नहीं है, यह त्रुटि देता है:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Docker अब एक resolute सूइट पब्लिश करता है। जिस सोर्स की सूइट गायब है, उसे तब तक डिसेबल रहने दें जब तक वेंडर उसे पब्लिश न कर दे। कोडनेम को बदलकर उस कोडनेम पर सेट करना जिसके लिए वेंडर ने बिल्ड किया है, वह तरीका है जिससे आप गलत सिस्टम लाइब्रेरी से लिंक किए गए पैकेज इंस्टॉल कर लेते हैं।

चरण 4: upgrade को plain SSH shell के बजाय tmux में चलाएं

Server upgrader सामान्यतः GNU screen के भीतर चलता है और connection टूटने के बाद reattach करने की सुविधा देता है, इसलिए केवल SSH session खोने से upgrade प्रक्रिया बंद नहीं होती। इसे अपने स्वयं के tmux session के भीतर चलाएं, ताकि आपके पास reconnect करने के लिए एक named session उपलब्ध रहे।

sudo apt install -y tmux
tmux new -s upgrade

उस session के भीतर:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

Upgrader किसी भी बदलाव को करने से पहले port 1022 पर एक दूसरा SSH daemon शुरू करता है, और इसकी सूचना देता है:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

यह उस port के लिए आपके firewall को नहीं खोलता है, क्योंकि बिना पूछे firewall में छेद करना एक बुरा अनुभव हो सकता है। शुरू करने से पहले 1022 को स्वयं खोलें, और sudo ufw delete allow 1022/tcp के साथ काम पूरा होने पर इसे बंद कर दें। याद रखें कि आपका provider सर्वर के बाहर अपने control panel में एक दूसरा firewall चला सकता है।

यदि connection फिर भी टूट जाता है, तो वापस login करें और tmux attach -t upgrade चलाएं। आपके जाने के बाद भी upgrade चलता रहा। यदि ऐसा नहीं हुआ, और आप एक ऐसे half-configured dpkg या apt sources पर वापस आते हैं जो आंशिक रूप से noble और आंशिक रूप से resolute हैं, तो विफल release upgrade को recover करना विषय package state को ठीक करने और यह जानने में मदद करता है कि कब मरम्मत बंद करके snapshot restore करना चाहिए।

चरण 5: configuration file के prompts का सावधानीपूर्वक उत्तर दें

dpkg केवल उन्हीं फाइलों के लिए prompt दिखाता है जिन्हें आपने या किसी script ने बदला है। इसलिए, प्रत्येक prompt एक ऐसी फाइल है जिसे आपने या किसी script ने संशोधित किया है, और default रूप से enter दबाने पर वर्तमान version ही बना रहता है।

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

हर बार सबसे पहले D दबाएं। देखें कि क्या बदलाव हुए हैं, फिर तय करें कि क्या आप N के साथ अपना version रखना चाहते हैं या maintainer का version install करना चाहते हैं। Default विकल्प पहले से ही N होता है, लेकिन हर package के लिए पुरानी फाइल रखना सुरक्षित नहीं है: upgraded system के काम करने के लिए कुछ configuration बदलाव आवश्यक होते हैं।

अपनी फाइल रखने की एक कीमत है: आपको नए defaults नहीं मिलते। बाद में, जब system चालू हो और आप पर समय का दबाव न हो, तब इनका मिलान (reconcile) करें।

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

सूचीबद्ध प्रत्येक फाइल maintainer का version है, जिसे आपकी फाइल के बगल में save किया गया है। एक-एक करके उनका diff देखें और महत्वपूर्ण settings को copy करें। दो फाइलों पर अतिरिक्त ध्यान दें: /etc/ssh/sshd_config, क्योंकि गलत उत्तर देने से आपका session समाप्त हो जाएगा, और आपका web server config, क्योंकि गलत उत्तर देने से sites down हो सकती हैं।

Ubuntu 24.04 के बाद से, needrestart default रूप से प्रभावित services को स्वचालित रूप से restart कर देता है। यदि आपने इसके interactive mode को restore किया है, तो पूरी सूची स्वीकार करें। यदि कोई daemon अभी भी पुरानी shared library का उपयोग कर रहा है, तो वह तब तक update द्वारा ठीक की गई खामियों के प्रति असुरक्षित रहता है जब तक कि उसे restart न किया जाए।

चरण 6: reboot करें, फिर मशीन की जाँच करें

sudo reboot

जब मशीन वापस चालू हो जाए:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a को Release: 26.04 और Codename: resolute रिपोर्ट करना चाहिए। uname -r को 7.0 kernel दिखाना चाहिए। systemctl --failed को शून्य units की सूची दिखानी चाहिए, और यदि यह कुछ भी सूचीबद्ध करता है, तो वह आपका अगला कार्य है। अंतिम apt update पैकेज इंडेक्स को रिफ्रेश करता है, और apt full-upgrade फिर उन सभी अपडेट्स को इंस्टॉल करता है जो अपग्रेड द्वारा पैकेज प्राप्त करने के बाद जारी किए गए हैं।

PostgreSQL 16 से 18: वह क्लस्टर जो चुपचाप पीछे रह जाता है

Ubuntu 24.04 में PostgreSQL 16 आता है और 26.04 में PostgreSQL 18 आता है। अपग्रेड 16 के साथ-साथ 18 को भी इंस्टॉल करता है, लेकिन यह आपके डेटा को स्थानांतरित नहीं करता है। Debian की postgresql-common लेयर केवल तभी एक main क्लस्टर बनाती है जब कोई क्लस्टर मौजूद न हो, इसलिए मौजूदा PostgreSQL 16 क्लस्टर स्वचालित रूप से पोर्ट 5433 पर एक खाली 18 क्लस्टर प्राप्त नहीं करता है। आपका एप्लिकेशन 5432 पर ही बात करता रहता है और सब कुछ सामान्य दिखता है, यही कारण है कि लोगों को इसका पता महीनों बाद चलता है।

pg_lsclusters

वर्जन 16 के लिए एक एंट्री का मतलब है कि क्लस्टर अभी भी 16 पर है। यदि pg_lsclusters में एक 18 main क्लस्टर भी सूचीबद्ध है, तो उसे sudo pg_dropcluster --stop 18 main के साथ हटाने से पहले पुष्टि करें कि वह खाली है, क्योंकि pg_upgradecluster किसी ऐसे टारगेट क्लस्टर में नहीं लिखेगा जो पहले से मौजूद है। माइग्रेशन तब करें जब आप एप्लिकेशन को रोक सकें:

sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

डिफ़ॉल्ट विधि 16 का डंप लेती है और उसे 18 में रीलोड करती है, इसलिए आपको डेटाबेस के आकार के बराबर खाली डिस्क स्पेस की आवश्यकता होती है। -m upgrade इसके बजाय pg_upgrade का उपयोग करता है और बड़े डेटाबेस पर बहुत तेज़ है। जब यह पूरा हो जाए, तो Port कॉलम पढ़ें: नया क्लस्टर 5432 का कार्यभार संभाल लेता है और पुराना क्लस्टर बंद छोड़ दिया जाता है। पैकेज्ड अपग्रेड हुक स्वचालित रूप से एक analyze पास चलाता है; ऊपर दिया गया कमांड इसे स्पष्ट रूप से दोहराता है।

कुछ दिनों तक नए क्लस्टर के साथ एप्लिकेशन का परीक्षण करें। उसके बाद ही पुराने क्लस्टर को हटाएं:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

पुराने क्लस्टर की डेटा डायरेक्टरी आपके पास उपलब्ध सबसे तेज़ रोलबैक विकल्प है। अपग्रेड वाले दिन इसे डिलीट न करें।

MySQL 8.0 से 8.4: हटाया गया विकल्प जो सर्वर को रोकता है

26.04 में MySQL को 8.0 से 8.4 LTS पर ले जाया गया है, और दो बदलाव सर्वरों को प्रभावित करते हैं।

पहला, यदि configuration में ऐसा विकल्प हो जिसे नए version में हटा दिया गया है, तो mysqld start होने से मना कर देता है। default_authentication_plugin एक सामान्य विकल्प है, क्योंकि कई पुराने guides इसे set करने का सुझाव देते हैं। Service fail हो जाती है, और journalctl -u mysql -n 50 सीधे उस अज्ञात variable का नाम बताता है। /etc/mysql/mysql.conf.d/ के अंतर्गत file से उस line को हटा दें, और फिर sudo systemctl start mysql करें।

दूसरा, mysql_native_password plugin अब 8.4 में default रूप से enabled नहीं है, इसलिए जो account अभी भी इसका उपयोग कर रहा है, वह login नहीं कर पाएगा। 8.0 पर रहते हुए ही इसकी जाँच करें:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Upgrade से पहले mysql_native_password दिखाने वाले प्रत्येक account को migrate करें, और फिर अपने application config में password update करें:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

यदि कोई client library इतनी पुरानी है कि वह caching_sha2_password का समर्थन नहीं करती, तो आप [mysqld] के अंतर्गत mysql_native_password=ON जोड़कर 8.4 में पुराने plugin को वापस चालू कर सकते हैं। इसे एक अस्थायी समाधान (bridge) के रूप में देखें, क्योंकि MySQL ने 9.0 में इस plugin को पूरी तरह हटा दिया है।

PHP 8.3 से 8.5: आपके vhosts ऐसे socket पर point कर रहे हैं जो अब मौजूद नहीं है

24.04 में PHP 8.3 आता है और 26.04 में PHP 8.5। ये packages versioned paths में install होते हैं और कोई भी प्रक्रिया आपके web server config को rewrite नहीं करती है। एक nginx vhost जिसमें fastcgi_pass unix:/run/php/php8.3-fpm.sock; है, अब ऐसे socket पर point कर रहा है जिसे कोई process नहीं बना रही है, इसलिए हर PHP request 502 error देती है और nginx error log में यह दिखता है:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

इसे नए socket पर point करें, config test करें और reload करें:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Apache पर mod_php के साथ लक्षण अलग होते हैं: Apache start ही नहीं होगा, और sudo apache2ctl -t रिपोर्ट करेगा कि वह libphp8.3.so को load नहीं कर सकता क्योंकि वह file मौजूद नहीं है। enabled module एक ऐसे package का symlink है जो अब हट चुका है।

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

यदि आपने इस server को Ubuntu 24.04 पर LAMP stack का उपयोग करके बनाया है, तो दोनों paths की जाँच करना आवश्यक है, क्योंकि guide आपको एक versioned module name और एक versioned socket के साथ छोड़ती है।

आपकी php.ini tuning भी migrate नहीं होती है। memory_limit, upload_max_filesize और जो कुछ भी आपने set किया है, वह /etc/php/8.3/ में रहता है, और नया tree defaults से शुरू होता है। दोनों files का diff निकालें और values को manually copy करें। पूरी पुरानी file को नई file के ऊपर copy करने से 8.3 के defaults 8.5 के install में आ जाएंगे। इसके बाद php -m चलाएं और तुलना करें: php8.3-redis के रूप में install किए गए extension को उसके php8.5- package की आवश्यकता होती है, और यदि वह PPA से आया था, तो upgrader ने उस source को disable कर दिया है और extension गायब है।

Certificates की एक बार अलग से जाँच करना जरूरी है। upgrade के बाद sudo certbot renew --dry-run --run-deploy-hooks चलाएं। यह live certificate को छुए बिना, web server reload hook सहित पूरे renewal path को test करता है। यदि कोई hook किसी ऐसे service name या binary को call करता है जो बदल गया है, तो वह renewal के समय चुपचाप fail होने के बजाय आपके सामने यहाँ fail हो जाएगा। nginx पर Let's Encrypt के साथ Certbot में बताया गया है कि उन hooks को कैसा दिखना चाहिए।

SSH: वह विफलता जो आपके वर्तमान सत्र को समाप्त कर देती है

sshd_config प्रॉम्प्ट वह जगह है जहाँ लोग खुद को लॉक कर लेते हैं। Y का उत्तर देने पर maintainer की फाइल इंस्टॉल हो जाती है, जो आपकी PermitRootLogin, PasswordAuthentication, AllowUsers, Port और आपके द्वारा जोड़ी गई हर दूसरी लाइन को हटा देती है। यदि आपका firewall केवल एक custom port की अनुमति देता है और packaged config 22 पर listen करता है, तो अगला कनेक्शन अस्वीकार कर दिया जाएगा, और जिस सत्र में आप अभी बैठे हैं, वह आपका अंतिम सत्र होगा।

अपग्रेड करने से पहले इसे रोकें। 24.04 पर /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf से शुरू होता है, और अधिकांश सेटिंग्स के लिए OpenSSH उस पहले मान को रखता है जिसे वह पढ़ता है, इसलिए शीर्ष पर शामिल किया गया drop-in नीचे दी गई समान सेटिंग पर प्रभावी रहता है। कुछ keywords अपवाद हैं: Port और ListenAddress कई मान स्वीकार करते हैं, इसलिए drop-in में एक Port लाइन नीचे सेट किए गए पोर्ट को बदलने के बजाय एक नया पोर्ट जोड़ती है। अपनी सेटिंग्स को ऐसी फाइल में ले जाएं जिसका स्वामित्व dpkg के पास नहीं है:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

एक बार जब /etc/ssh/sshd_config में आपकी कोई भी सेटिंग नहीं रहती, तो वह प्रॉम्प्ट मायने नहीं रखता: कोई भी उत्तर आपकी सेटिंग्स को सुरक्षित रखेगा, क्योंकि वे एक अलग फाइल में रहती हैं।

एक custom port के लिए एक और जांच की आवश्यकता होती है, क्योंकि यह वहां नहीं हो सकता है जहां आप सोचते हैं:

systemctl is-enabled ssh.socket

यदि यह enabled प्रिंट करता है, तो systemd listening port को खोलता है, sshd नहीं। Ubuntu 22.10 के बाद से sshd के लिए socket activation का उपयोग कर रहा है। 24.04 पर एक systemd generator sshd कॉन्फ़िगरेशन से Port और ListenAddress सेटिंग्स को पढ़ता है और उन्हें socket के listen addresses में बदल देता है, लेकिन केवल तब जब systemd अपनी units को reload करता है। यही कारण है कि Port 2222 संपादन का कोई प्रभाव नहीं पड़ता है: यह sudo systemctl daemon-reload && sudo systemctl restart ssh.socket के बाद प्रभावी होता है, और packaged sshd_config में अब ऐसा करने का उल्लेख है। पोर्ट को सीधे socket unit पर सेट करने के लिए, sudo systemctl edit ssh.socket का उपयोग करें:

[Socket]
ListenStream=
ListenStream=2222

खाली ListenStream= आवश्यक है। यह विरासत में मिले मान को हटा देता है, और इसके बिना socket 22 के साथ-साथ 2222 पर भी listen करेगा। इसे sudo systemctl daemon-reload && sudo systemctl restart ssh.socket के साथ लागू करें।

अपग्रेड के बाद, अपने वर्तमान सत्र को बंद करने से पहले:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

फिर अपनी मशीन पर एक दूसरा terminal खोलें और दोबारा लॉग इन करें। उस दूसरे terminal में एक कार्यशील shell ही एकमात्र प्रमाण है जो मायने रखता है। जब तक आपके पास वह न हो, तब तक पहला सत्र खुला रखें। Hardening SSH on a VPS उन सेटिंग्स के बारे में बताता है जिन्हें उस drop-in में रखना उचित है।

यदि बहुत देर हो चुकी है, तो आपके प्रदाता का web console आपको एक ऐसा लॉगिन देता है जो SSH का उपयोग बिल्कुल नहीं करता है। वहां लॉग इन करें, config को ठीक करें, sudo sshd -t चलाएं, और service को restart करें। वह console ही मुख्य कारण है कि आप अपग्रेड के दौरान नहीं, बल्कि उससे पहले console access का परीक्षण करते हैं।

FAQ

Ubuntu 24.04 पर do-release-upgrade "No new release found" क्यों कहता है?

29 September 2026 के बाद ऐसा नहीं होना चाहिए, क्योंकि इसी दिन Canonical ने 24.04 LTS से 26.04.1 पर अपग्रेड की सुविधा शुरू की थी। उससे पहले यह संदेश अपेक्षित था: Ubuntu 26.04 LTS को 23 April 2026 को release किया गया था, 26.04.1 को 27 August को, और rust-coreutils regressions के लिए fixes backport करने के कारण यह रास्ता कुछ हफ्तों तक बंद रहा था। यदि आपको अभी भी यह संदेश दिख रहा है, तो जाँचें कि /etc/update-manager/release-upgrades में Prompt=lts सेट है या नहीं, जो Ubuntu Server का डिफ़ॉल्ट है और केवल अगले long term support release का विकल्प देता है। इसे lts पर सेट करें।

क्या अपग्रेड पूरा करने के लिए सर्वर को रीबूट करना अनिवार्य है?

हाँ। अपग्रेड एक नया kernel, एक नई C library और एक नया init system इंस्टॉल करता है, और जब तक सिस्टम रीस्टार्ट नहीं होता, तब तक वह पुराने वर्ज़न का ही उपयोग करता रहता है। do-release-upgrade अंत में रीबूट करने के लिए कहता है, और यदि मशीन को "बाद में" रीबूट करने के लिए छोड़ दिया जाए, तो वह दो अलग-अलग releases के मिश्रण पर चल रही होती है। रीबूट के बाद, नए kernel के लिए uname -r और जो सेवाएं नहीं चल पाईं उनके लिए systemctl --failed की जाँच करें।

क्या मुझे इन-प्लेस अपग्रेड करना चाहिए या नया 26.04 सर्वर बनाना चाहिए?

जब संभव हो, नया सर्वर ही बनाएं। एक नया VPS आपको स्टैक इंस्टॉल करने, डेटा रिस्टोर करने और सब कुछ टेस्ट करने की सुविधा देता है जबकि पुराना सर्वर ट्रैफिक सर्व कर रहा होता है, जिससे rollback केवल एक DNS बदलाव रह जाता है, न कि बैकअप से रिस्टोर करने की प्रक्रिया। इन-प्लेस अपग्रेड तब करें जब सर्वर पर ऐसा डेटा हो जिसे स्थानांतरित करना कठिन हो, जब प्रदाता प्रति मशीन शुल्क लेता हो, या जब आपके पास snapshot और विश्वसनीय console access हो। इन-प्लेस अपग्रेड का रास्ता काफी आजमाया हुआ है, लेकिन यह उस एक घंटे के लिए एकतरफा रास्ता है जब यह प्रक्रिया चलती है।

अपग्रेड के दौरान SSH कनेक्शन कट जाए तो क्या होगा?

सर्वर अपग्रेडर आमतौर पर GNU screen का उपयोग करता है, इसलिए SSH कनेक्शन कटने से अपग्रेड अपने आप बंद नहीं होता। यदि आपने इसे ऊपर बताए गए tmux session के अंदर शुरू किया था, तो पुनः कनेक्ट करें और इसे जारी रखने के लिए tmux attach -t upgrade चलाएं। अपग्रेडर पोर्ट 1022 पर एक अतिरिक्त SSH daemon भी शुरू करता है ताकि दूसरा रास्ता बना रहे, लेकिन यह उस पोर्ट के लिए firewall नहीं खोलता, इसलिए पहले खुद 1022 को allow करें और बाद में इसे बंद कर दें।

अपग्रेड के बाद मेरी PHP साइट 502 error क्यों दे रही है? क्या खराब हुआ?

वर्ज़न बदलने के साथ PHP FPM socket का पाथ बदल गया है। Ubuntu 24.04 पर PHP 8.3 चलता है और 26.04 पर PHP 8.5, इसलिए /run/php/php8.3-fpm.sock अब मौजूद नहीं है जबकि आपका nginx vhost अभी भी उसी का नाम ले रहा है। nginx error log में connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) दिखाई देगा। fastcgi_pass को 8.5 socket पर अपडेट करें, sudo nginx -t चलाएं, और फिर nginx को reload करें। Apache पर mod_php के साथ इसका समाधान sudo a2dismod php8.3 है, जिसके बाद sudo a2enmod php8.5 चलाकर रीस्टार्ट करना होता है।