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

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

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

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 हैं और जिनका support समाप्त हो चुका है। इसे lts पर रहने दें और प्रतीक्षा करें। Canonical के शेड्यूल की तारीखें बदल सकती हैं, इसलिए यदि निर्धारित दिन शांति से बीत जाए तो इसे दोबारा चेक करें।

नीचे दिया गया प्रत्येक कमांड वह है जिसे आप स्वयं, अपने सर्वर पर, दिए गए क्रम में चलाते हैं। release upgrade का पूर्वाभ्यास (rehearsal) उस मशीन पर नहीं किया जा सकता जिसे आप अपग्रेड कर रहे हैं। यह 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 या सीरियल) को खोलकर उसमें लॉग इन नहीं किया है। यदि SSH टूट जाता है, तो वह कंसोल ही सर्वर में वापस जाने का एकमात्र तरीका है, और लॉक आउट होने के बाद यह पता चलना कि वह काम नहीं कर रहा है, बहुत देर हो चुकी होती है।
• आप एक घंटे का डाउनटाइम वहन नहीं कर सकते और आपके पास रोलबैक की कोई व्यवस्था नहीं है।
• आपका स्टैक किसी ऐसे थर्ड-पार्टी रिपॉजिटरी पर निर्भर है जिसने अभी तक resolute के लिए पब्लिश नहीं किया है।
• सर्वर को दो वर्षों में मैन्युअल रूप से तैयार किया गया था और किसी को यह नहीं पता कि उस पर क्या-क्या कॉन्फ़िगर है।

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

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

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

सबसे पहले databases को मैन्युअल रूप से dump करें। एक dump ही database का एकमात्र ऐसा बैकअप है जिस पर आप उसे रोके बिना भरोसा कर सकते हैं।

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 टेबल्स के लिए एक consistent dump देता है। MyISAM टेबल्स के लिए database को रोकना आवश्यक है। /etc tarball वह है जिसे आप वास्तव में उपयोग करेंगे, क्योंकि इसमें वे सभी config फाइलें होती हैं जिनके बारे में upgrade आपसे प्रश्न पूछने वाला है।

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

चरण 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 और पैकेज नाम के साथ उसे रिलीज़ करें, या यह स्वीकार करें कि होल्ड किसी कारण से है और यहीं रुक जाएं।

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

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

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

df -h / /boot

/ पर लगभग 5 GB से कम खाली जगह होने पर यह प्रक्रिया विफल हो जाती है। 300 MB से कम का /boot बाद में, कर्नेल इंस्टॉल के दौरान, No space left on device के साथ विफल हो जाता है। पुराने कर्नेल आमतौर पर इसका कारण होते हैं, और 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 सिस्टम को खराब कर सकता है। यह बाद में उन सोर्स को फिर से इनेबल कर देता है जिन्हें यह पहचानता है और बाकी को कमेंट आउट (commented out) छोड़ देता है। टूल द्वारा निर्णय लेने से पहले यह जान लें कि आप क्या उपयोग कर रहे हैं।

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 टूट जाता है, तो process को SIGHUP signal मिलता है और वह unpacking के बीच में ही बंद हो जाती है। इससे dpkg आधा-अधूरा configure रह जाता है, और server का network stack खराब हो सकता है जिससे आप दोबारा connect न कर पाएं। इसे एक terminal multiplexer के अंदर चलाएं, ताकि आपके client के disconnect होने पर भी server पर 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 में छेद करना एक गलत व्यवहार होगा। शुरू करने से पहले 1022 port को स्वयं खोलें, और sudo ufw delete allow 1022/tcp का काम पूरा होने पर इसे बंद कर दें। याद रखें कि आपका provider server के बाहर, अपने control panel में एक दूसरा firewall भी चला सकता है।

यदि फिर भी connection टूट जाए, तो वापस login करें और tmux attach -t upgrade चलाएं। आपके जाने के बाद भी upgrade प्रक्रिया चलती रही है।

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

dpkg केवल उन्हीं फाइलों के लिए prompt दिखाता है जिन्हें आपने या किसी script ने बदला है। इसलिए, हर prompt एक ऐसी फाइल है जिसे आपने जानबूझकर संपादित किया है। केवल enter दबाकर prompt को हटा देना, एक सुरक्षित सर्वर को अनजाने में 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 होता है, जो कि एक सुरक्षित उत्तर है, क्योंकि आपकी फाइल वर्तमान में काम कर रही है और packaged फाइल इस मशीन पर कभी नहीं चली है।

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

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

Step 6: reboot, फिर machine की जाँच करें

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 आता है। ये पैकेज 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 एक ऐसे पैकेज का symlink है जो अब हट चुका है।

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

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

आपकी php.ini tuning भी साथ नहीं आती है। memory_limit, upload_max_filesize और जो कुछ भी आपने set किया है, वे /etc/php/8.3/ में रहते हैं, और नया tree defaults से शुरू होता है। दोनों files को diff करें और values को हाथ से copy करें। पूरी पुरानी file को नई file के ऊपर copy करने से 8.3 के defaults 8.5 के install में आ जाते हैं। फिर php -m चलाएँ और तुलना करें: php8.3-redis के रूप में install किए गए extension को अपने php8.5- पैकेज की आवश्यकता होती है, और यदि वह 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 दिनों में चुपचाप। nginx पर Let's Encrypt के साथ Certbot में बताया गया है कि उन hooks को कैसा दिखना चाहिए।

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

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)'

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

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

FAQ

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

क्योंकि /etc/update-manager/release-upgrades में Ubuntu Server पर 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 उपलब्ध हो। इन-प्लेस अपग्रेड का रास्ता आजमाया हुआ है, लेकिन यह अपग्रेड के दौरान एक तरफा रास्ता होता है।

यदि अपग्रेड के दौरान 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 एरर लॉग में connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) दिखाई देगा। fastcgi_pass को 8.5 सॉकेट पर अपडेट करें, sudo nginx -t चलाएं, और फिर nginx को रिलोड करें। Apache में mod_php के साथ इसका समाधान sudo a2dismod php8.3 है, जिसके बाद sudo a2enmod php8.5 चलाकर रीस्टार्ट करना होता है।