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

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

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

August 2026 की शुरुआत में 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 शामिल है, जिसका अर्थ है कि यह टूल केवल अगला long term support release प्रदान करता है, और वह भी केवल तब जब उसका .1 point release मौजूद हो। इसके बजाय Prompt=normal सेट करने पर आप 24.10, 25.04 और 25.10 के माध्यम से आगे बढ़ेंगे, जो कि interim releases हैं और अपनी end of life तक पहुँच चुके हैं। इसे lts पर छोड़ दें और प्रतीक्षा करें। Canonical के शेड्यूल पर तारीखें बदल सकती हैं, इसलिए यदि निर्धारित दिन बीत जाए तो इसे दोबारा चेक करें।

नीचे दिए गए प्रत्येक कमांड को आप स्वयं, अपने सर्वर पर, दिए गए क्रम में चलाएंगे। जिस मशीन को आप अपग्रेड कर रहे हैं, उस पर release upgrade का पूर्वाभ्यास (rehearse) नहीं किया जा सकता है। यह kernel और C library को बदल देता है, और इसे पूरा करने के लिए reboot की आवश्यकता होती है।

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

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: ऐसा बैकअप लें जिसे आप रिस्टोर कर सकें

दो परतों का उपयोग करें, क्योंकि वे अलग-अलग तरीकों से विफल होती हैं। एक प्रोवाइडर स्नैपशॉट पूरी डिस्क को कवर करता है और मिनटों में रिस्टोर हो जाता है, लेकिन यह तब लिया जाता है जब आपके डेटाबेस लिख रहे होते हैं, इसलिए यह एप्लिकेशन कंसिस्टेंट होने के बजाय क्रैश कंसिस्टेंट होता है। 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 के कुछ भी न दिखाने का मतलब है कि कोई भी पैकेज ऐसे वर्ज़न पर पिन नहीं है जो अपग्रेड को रोकेगा। यदि यह कुछ भी लिस्ट करता है, तो उसे sudo apt-mark unhold और पैकेज के नाम के साथ रिलीज़ करें, या यह स्वीकार करें कि होल्ड किसी कारण से है और यहीं रुक जाएं।

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

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

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

df -h / /boot

/ पर लगभग 5 GB से कम खाली जगह होने पर यह प्रक्रिया विफल हो जाती है। 300 MB से कम का /boot बाद में, kernel इंस्टॉल के दौरान, No space left on device के साथ विफल हो जाता है। पुराने kernels आमतौर पर इसका कारण होते हैं, और sudo apt --purge autoremove उन्हें हटा देता है।

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

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

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

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/ में मौजूद कोई भी चीज एक पिन है, और 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.

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

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

यदि do-release-upgrade के चलते समय आपका connection टूट जाता है और आप plain login shell का उपयोग कर रहे हैं, तो process को SIGHUP signal मिलता है और वह unpacking के दौरान ही बंद हो जाता है। इससे dpkg आधा-अधूरा configure रह जाता है और सर्वर का network stack काम करना बंद कर सकता है, जिससे आप दोबारा connect नहीं कर पाएंगे। इसके बजाय इसे terminal multiplexer के अंदर चलाएं, ताकि आपके client के disconnect होने पर भी सर्वर पर process जीवित रहे।

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.

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

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

चरण 5: configuration file के prompts का सोच-समझकर उत्तर दें

dpkg केवल उन्हीं फाइलों के लिए prompt दिखाता है जिन्हें आपने या किसी script ने बदला है। इसलिए, प्रत्येक prompt वह फाइल है जिसे आपने जानबूझकर edit किया है। केवल enter दबाकर prompt को हटा देना, एक सुरक्षित server को अनजाने में default settings पर वापस ले जाने का कारण बनता है।

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 सुरक्षित रखें। default विकल्प पहले से ही N होता है, जो कि एक सुरक्षित उत्तर है, क्योंकि आपकी फाइल वर्तमान में काम कर रही है और package वाली फाइल इस machine पर कभी run नहीं हुई है।

अपनी फाइल को बनाए रखने की एक कीमत है: आपको नई default settings नहीं मिलेंगी। बाद में, जब server चालू हो और आप पर समय का दबाव न हो, तब इन बदलावों का मिलान (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 हो सकती हैं।

upgrade के दौरान needrestart के माध्यम से यह भी पूछा जाता है कि किन services को restart करना है। पूरी सूची को स्वीकार करें। यदि कोई daemon ऐसी shared library file का उपयोग कर रहा है जिसे disk से delete कर दिया गया है, तो वह बाद में किसी भी समय crash हो सकता है, जब आप उसे monitor नहीं कर रहे होंगे।

चरण 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 उन updates को प्राप्त करता है जो release images के बनने के बाद प्रकाशित किए गए हैं।

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

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

pg_lsclusters

दो क्लस्टर सूचीबद्ध होने का मतलब है कि आपने माइग्रेशन नहीं किया है। इसे तब करें जब आप एप्लिकेशन को रोक सकें:

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

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

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

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

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

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

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

सबसे पहले, यदि कॉन्फ़िगरेशन में ऐसा विकल्प हो जिसे नए संस्करण से हटा दिया गया है, तो mysqld स्टार्ट होने से मना कर देता है। default_authentication_plugin एक सामान्य विकल्प है, क्योंकि कई पुरानी गाइड इसे सेट करने का सुझाव देती हैं। सर्विस फेल हो जाती है, और journalctl -u mysql -n 50 सीधे उस अज्ञात वेरिएबल का नाम बताता है। /etc/mysql/mysql.conf.d/ के अंतर्गत फ़ाइल से उस लाइन को हटा दें, फिर sudo systemctl start mysql करें।

दूसरा, mysql_native_password प्लगइन अब 8.4 में डिफ़ॉल्ट रूप से सक्षम नहीं है, इसलिए जो अकाउंट अभी भी इसका उपयोग कर रहे हैं, वे बिल्कुल भी लॉग इन नहीं कर पाएंगे। 8.0 पर रहते हुए ही इसकी जाँच करें:

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

अपग्रेड से पहले mysql_native_password दिखाने वाले प्रत्येक अकाउंट को बदलें, फिर अपने एप्लिकेशन कॉन्फ़िगरेशन में पासवर्ड अपडेट करें:

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

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

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

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 की ओर इशारा कर रहा है जिसे कोई भी 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

यदि आपने Ubuntu 24.04 पर LAMP stack का उपयोग करके server तैयार किया था, तो उन दोनों 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 चलाएं। यह live certificate को छुए बिना, web server reload hook सहित पूरे renewal path को test करता है। एक hook जो किसी service name या binary को call करता है जो बदल गई है, वह यहाँ आपके सामने fail हो जाएगा, बजाय इसके कि 60 दिनों में चुपचाप fail हो। nginx पर Let's Encrypt के साथ Certbot में बताया गया है कि उन hooks को कैसा दिखना चाहिए।

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

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

अपग्रेड करने से पहले इसे रोकें। 24.04 पर /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf से शुरू होता है, और OpenSSH प्रत्येक सेटिंग के लिए पढ़ी गई पहली वैल्यू को रखता है, इसलिए सबसे ऊपर शामिल किया गया ड्रॉप-इन नीचे की किसी भी सेटिंग पर हावी हो जाता है। अपनी सेटिंग्स को ऐसी फाइल में ले जाएं जिसका स्वामित्व 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 में आपकी कोई भी सेटिंग नहीं रहती है, तो वह प्रॉम्प्ट मायने नहीं रखता: कोई भी उत्तर आपकी सेटिंग्स को सुरक्षित रखता है, क्योंकि वे एक अलग फाइल में मौजूद होती हैं।

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

systemctl is-enabled ssh.socket

यदि यह enabled प्रिंट करता है, तो systemd लिसनिंग पोर्ट का मालिक है और sshd_config में Port लाइन को अनदेखा कर दिया जाता है। Ubuntu 22.10 से sshd के लिए सॉकेट एक्टिवेशन का उपयोग कर रहा है, और यही कारण है कि Port 2222 में किया गया संपादन निष्प्रभावी लगता है। इसे sudo systemctl edit ssh.socket के साथ सॉकेट यूनिट पर सेट करें:

[Socket]
ListenStream=
ListenStream=2222

खाली ListenStream= आवश्यक है। यह इनहेरिट की गई वैल्यू को क्लियर करता है, और इसके बिना सॉकेट 22 के साथ-साथ 2222 पर भी लिसन करेगा। इसे 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)'

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

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

FAQ

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

क्योंकि Ubuntu Server पर /etc/update-manager/release-upgrades में Prompt=lts सेट होता है, और यह सेटिंग केवल पहली point release आने के बाद ही अगली long term support release का सुझाव देती है। Ubuntu 26.04 LTS को 23 April 2026 को release किया गया था, और 26.04.1 के लिए 27 August 2026 की तारीख तय है। उस दिन तक, 24.04 सर्वर को कोई नया अपडेट नहीं दिखेगा। इस सेटिंग को न बदलें; इसे Prompt=normal पर स्विच करने से आप interim releases के चक्र में फंस जाएंगे।

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

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

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

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

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

साधारण login shell में प्रक्रिया को SIGHUP सिग्नल मिलता है और वह बीच में ही बंद हो जाती है, जिससे dpkg आधा-अधूरा कॉन्फ़िगर रह जाता है। इसे tmux या screen के अंदर शुरू करें ताकि प्रक्रिया सुरक्षित रहे; कनेक्शन कटने पर आप फिर से कनेक्ट करके tmux attach -t upgrade चलाकर उसे वहीं से जारी रख सकते हैं। अपग्रेडर पोर्ट 1022 पर एक अतिरिक्त SSH daemon भी शुरू करता है, लेकिन यह उस पोर्ट के लिए firewall नहीं खोलता। इसलिए, पहले खुद 1022 पोर्ट को अनुमति दें और काम पूरा होने के बाद उसे बंद कर दें।

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

वर्ज़न बदलने के साथ 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 और एक रीस्टार्ट की आवश्यकता होती है।