Ubuntu 24.04 నుంచి 26.04కు VPS upgrade ఎప్పుడు?

Ubuntu 24.04 ను 26.04 కు ఎప్పుడు upgrade చేయవచ్చు?

26.04.1 point release విడుదలైన తర్వాత VPS పై Ubuntu 24.04 ను 26.04 కు upgrade చేయవచ్చు. ఇది 27 August 2026న విడుదల కావాల్సి ఉంది. అప్పటివరకు 24.04 server కు కొత్త release కనిపించదు. ఇది ఉద్దేశపూర్వకమే. Ubuntu 26.04 LTS (Resolute Raccoon) 23 April 2026న విడుదలైంది. అయితే మొదటి point release సమయంలోనే Canonical LTS నుంచి LTS upgrade మార్గాన్ని అందుబాటులోకి తెస్తుంది. ఎందుకంటే మొదటి కొన్ని నెలల్లో గుర్తించిన installation మరియు upgrade bugs ఆ releaseలో చేర్చబడతాయి.

2026 August ప్రారంభంలో 24.04 machineపై check నడిపితే ఇది కనిపిస్తుంది:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

ఇది మీ serverలోని fault కాదు. Ubuntu Serverలో /etc/update-manager/release-upgrades లో Prompt=lts ఉంటుంది. అందువల్ల ఆ tool తదుపరి long term support releaseను మాత్రమే అందిస్తుంది. అదీ దాని .1 point release అందుబాటులోకి వచ్చిన తర్వాత మాత్రమే. Prompt=normal ను సెట్ చేస్తే బదులుగా 24.10, 25.04, 25.10 releases ద్వారా వరుసగా upgrade చేస్తుంది. ఇవన్నీ ఇప్పటికే end of life కు చేరుకున్న interim releases. దాన్ని lts లోనే ఉంచి వేచి ఉండండి. Canonical scheduleలోని తేదీలు మారవచ్చు. ఆ రోజు ఎలాంటి మార్పు లేకుండా గడిచిపోతే మళ్లీ check చేయండి.

కింద ఉన్న ప్రతి command ను మీరు మీ స్వంత serverపై, ఇచ్చిన క్రమంలో, స్వయంగా run చేయాలి. మీరు upgrade చేస్తున్న machineపై release upgradeను ముందుగా పరీక్షించలేరు. ఇది kernel మరియు C libraryలను replace చేస్తుంది. పూర్తి కావడానికి reboot అవసరం.

అసలు upgrade చేయాలా?

Ubuntu 24.04 కు 2029 వరకు standard security updates అందుతాయి. అందువల్ల సరిగ్గా పనిచేస్తున్న production server పై తక్షణ upgrade ఒత్తిడి లేదు. 26.04లో లభించే ఏదైనా మీకు అవసరమైతే upgrade చేయండి: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 లేదా 7.0 kernel. "సంఖ్య పెరిగింది" అనేది customer సేవలను అందిస్తున్న machine ను మార్చడానికి సరైన కారణం కాదు.

కింది పరిస్థితుల్లో in-place upgrade చేయకండి:

• మీరు మీ provider యొక్క console (VNC లేదా serial) ను ఎప్పుడూ తెరిచి, దాని ద్వారా login కాలేదు. SSH పనిచేయకపోతే ఆ console మాత్రమే server లోకి తిరిగి ప్రవేశించే మార్గం. మీరు బయటకు lock అయిన తర్వాత అది పనిచేయదని తెలుసుకోవడం ఆలస్యం అవుతుంది.
• ఒక గంట downtime ను భరించలేరు మరియు rollback మార్గం లేదు.
• మీ stack, resolute కోసం ఇంకా ప్రచురించని third-party repository పై ఆధారపడి ఉంది.
• ఆ server ను రెండు సంవత్సరాలకు పైగా చేతితో నిర్మించారు, అందులో ఏమి ఉందో ఎవరికీ తెలియదు.

తరచుగా మెరుగైన ప్రత్యామ్నాయం ఇదే: కొత్త 26.04 VPS ను నిర్మించి, మీ stack ను install చేసి, data ను restore చేయండి. అది సరిగ్గా స్పందిస్తోందని నిర్ధారించిన తర్వాత DNS ను మార్చండి. కొత్త server తన సామర్థ్యాన్ని నిరూపించే వరకు పాత server ను నడుస్తూనే ఉంచవచ్చు. అప్పుడు rollback కోసం restore అవసరం కాకుండా DNS మార్చడం సరిపోతుంది. ఈ విధానాన్ని ఎంచుకుంటే, కొత్త VPSలో మొదటి పది నిమిషాలు నుండి ప్రారంభించి, కొత్త server ను సరిగ్గా నిర్మించండి.

దశ 1: పునరుద్ధరించగలిగే బ్యాకప్ తీసుకోండి

రెండు పొరలను ఉపయోగించండి. అవి వేర్వేరు విధాలుగా విఫలమవుతాయి. Provider snapshot మొత్తం disk ను కవర్ చేసి, కొన్ని నిమిషాల్లో పునరుద్ధరిస్తుంది. అయితే databases రాస్తున్న సమయంలో snapshot తీసుకోబడుతుంది. అందువల్ల ఇది application consistent కాకుండా crash consistent గా ఉంటుంది. server వెలుపల నిల్వ చేసిన restic తో తీసిన file-level backup ద్వారా individual files పొందవచ్చు. మీ account lock అయినా ఈ backup copy అందుబాటులో ఉంటుంది.

ముందుగా databases ను చేతితో dump చేయండి. Database ను ఆపకుండా నమ్మదగినదిగా తీసుకోగల ఏకైక backup dump మాత్రమే.

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 tables కోసం మాత్రమే consistent dump ఇస్తుంది. MyISAM tables కోసం database ను ఆపాలి. Upgrade అడగబోయే ప్రతి config file ఇందులో ఉండటం వల్ల /etc tarball నే మీరు వాస్తవంగా ఉపయోగిస్తారు.

మీరు ఎప్పుడూ restore చేయని backup ఒక అంచనా మాత్రమే. అత్యవసర సమయంలో అవసరం పడకముందే, ఇప్పుడే దాని నుంచి ఒక file ను వెలికి తీయండి.

దశ 2: ముందుగా 24.04 ను పూర్తిగా patch చేయండి

విరిగిన package స్థితి ఉన్న system పై do-release-upgrade అమలు కావడానికి నిరాకరిస్తుంది. సగం patch అయిన 24.04 లో తరువాతి ప్రతి failure ను అర్థం చేసుకోవడం మరింత కష్టమవుతుంది.

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

dpkg --audit ఏ output ఇవ్వకపోతే ఏ package కూడా half configured కాలేదని అర్థం. apt-mark showhold ఏ output ఇవ్వకపోతే upgrade ను అడ్డుకునే version కు ఏ package కూడా pinned కాలేదని అర్థం. అది చూపించే ప్రతి package పై package పేరు తో కలిసి sudo apt-mark unhold అమలు చేయండి. లేదా ఆ hold ఒక కారణంతో ఉందని అంగీకరించి ఇక్కడే ఆపండి.

Kernel మారి ఉంటే reboot చేయండి. అప్పుడు system తాను నడుపుతున్నదని భావించే code తోనే upgrade ప్రారంభమవుతుంది.

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

తరువాత disk space ను తనిఖీ చేయండి. ఏదైనా install చేయడానికి ముందు upgrader మొత్తం కొత్త package set ను download చేస్తుంది. తగినంత స్థలం లేకపోతే filesystem పేరును చూపిస్తూ ఆగిపోతుంది.

df -h / /boot

/ లో సుమారు 5 GB కంటే తక్కువ free space ఉంటే ఈ సమస్య సాధారణంగా వస్తుంది. /boot 300 MB కంటే తక్కువగా ఉంటే kernel install సమయంలో తరువాత failure అవుతుంది; అప్పుడు No space left on device కనిపిస్తుంది. సాధారణంగా పాత kernels దీనికి కారణం. sudo apt --purge autoremove వాటిని తొలగిస్తుంది.

ప్రారంభించే ముందు ఆపాల్సిన మరో విషయం ఉంది: automatic security updates మధ్యలో ప్రారంభమైతే అవి dpkg lock ను పట్టుకుంటాయి. అప్పుడు release upgrader Could not get lock /var/lib/dpkg/lock-frontend తో ఆగిపోతుంది. ముందుగా sudo systemctl stop unattended-upgrades అమలు చేసి, అది పూర్తయిన తర్వాత upgrade ను మళ్లీ ప్రారంభించండి.

దశ 3: third-party repositories మరియు pinned packages ను తనిఖీ చేయండి

Ubuntu కు చెందినది కాని ప్రతి apt source ను do-release-upgrade నిలిపివేస్తుంది. ఎందుకంటే noble కోసం build చేసిన package, resolute system లో సమస్యలు కలిగించవచ్చు. ఇది గుర్తించిన sourceలను తర్వాత మళ్లీ enable చేస్తుంది. మిగిలిన వాటిని commented out గానే ఉంచుతుంది. Tool మీ తరఫున నిర్ణయించే ముందు, మీరు system లో ఏమి కలిగి ఉన్నారో తెలుసుకోండి.

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 ఈ directory లో రెండు formats ను ఉపయోగిస్తుంది: పాత one-line .list files మరియు Types:, Suites: fields కలిగిన deb822 .sources files. Upgrade సమయంలో రెండూ disable అవుతాయి. ఏ Ubuntu archive అందించని installed packages ను ubuntu-security-status --thirdparty జాబితా చేస్తుంది. మీరు అదనంగా install చేసిన వాటి నిజమైన సంఖ్య ఇదే. /etc/apt/preferences.d/ లోని ఏదైనా ఒక pin. noble కోసం రాసిన pin కొత్త release లో కూడా పాత package ను ఎంచుకునేలా చేస్తుంది.

ప్రతి third-party repository కోసం, ప్రారంభించే ముందు vendor కొత్త codename కోసం విడుదల చేసిందో లేదో నిర్ధారించండి. Docker suites https://download.docker.com/linux/ubuntu/dists/ వద్ద జాబితా చేయబడ్డాయి. ఇతర vendors కూడా ఇదే directory ను అందిస్తారు. ఉనికిలో లేని suite కు చూపించే source, upgrade తర్వాత మొదటి apt update సమయంలో ఈ output ను ఇస్తుంది:

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

Vendor విడుదల చేసే వరకు ఆ source ను disabled గానే ఉంచండి. Vendor build చేసిన suite కు codename ను మార్చకుండా, ఉనికిలో లేని లేదా తప్పు suite పేరును ఉపయోగించడం వల్ల తప్పు system libraries కు link అయిన packages install అవుతాయి.

దశ 4: సాధారణ SSH shellలో కాకుండా tmuxలో upgrade ను నడపండి

సాధారణ login shellలో do-release-upgrade నడుస్తున్న సమయంలో మీ connection తెగిపోతే, ఆ processకు SIGHUP అందుతుంది. దాంతో unpacking మధ్యలోనే అది ఆగిపోతుంది. ఫలితంగా dpkg సగం మాత్రమే configure అయి ఉంటుంది. తిరిగి connect కావడానికి అవసరమైన working network stack కూడా serverలో లేకపోవచ్చు. అందువల్ల దీన్ని terminal multiplexer లో నడపండి. మీ client connection ముగిసినా process serverలో కొనసాగుతుంది.

sudo apt install -y tmux
tmux new -s upgrade

ఆ sessionలో:

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

ఏ మార్పు చేయకముందే upgrader రెండవ SSH daemon ను port 1022పై ప్రారంభిస్తుంది. అది దీన్ని స్పష్టంగా తెలియజేస్తుంది:

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ను upgrader తెరవదు. అనుమతి లేకుండా firewallలో hole చేయడం ఊహించని సమస్యలకు దారితీయవచ్చు. మీరు start చేయడానికి ముందు 1022ను స్వయంగా open చేయండి. sudo ufw delete allow 1022/tcp పూర్తయిన తర్వాత దాన్ని close చేయండి. మీ provider serverకు వెలుపల, తన control panelలో మరో firewallను అమలు చేస్తుండవచ్చని గుర్తుంచుకోండి.

అయినా connection తెగిపోతే తిరిగి login అయి tmux attach -t upgrade నడపండి. మీరు లేని సమయంలో కూడా upgrade కొనసాగుతూనే ఉంటుంది.

దశ 5: configuration file prompts కు ఉద్దేశపూర్వకంగా సమాధానం ఇవ్వండి

మీరు లేదా ఒక script మార్చిన files కోసం మాత్రమే dpkg prompt చూపిస్తుంది. అందువల్ల ప్రతి prompt మీరు ఉద్దేశపూర్వకంగా edit చేసిన file కు సంబంధించినదే. దాన్ని తొలగించడానికి enter నొక్కడం వల్ల hardened server నిశ్శబ్దంగా default server గా మారుతుంది.

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 గా ఉంటుంది. అదే సురక్షితమైన సమాధానం, ఎందుకంటే మీ file ప్రస్తుతం పనిచేస్తోంది మరియు packaged file ఈ machine పై ఇంతవరకు run కాలేదు.

మీ file ను ఉంచడానికి ఒక పరిమితి ఉంది: కొత్త defaults మీకు లభించవు. తరువాత వాటిని సరిపోల్చండి. Server అందుబాటులోకి వచ్చిన తర్వాత, సమయ ఒత్తిడి లేని సమయంలో ఈ పని చేయండి.

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

ప్రతి file కు జాబితా చూపించినప్పుడు, అది maintainer version ను సూచిస్తుంది. అది మీ version పక్కనే save అవుతుంది. వాటిని ఒక్కొక్కటిగా diff చేసి, అవసరమైన settings ను మీ file లోకి copy చేయండి. రెండు files పై ప్రత్యేక శ్రద్ధ అవసరం: /etc/ssh/sshd_config, ఎందుకంటే తప్పు సమాధానం మీ session ను ముగిస్తుంది; అలాగే మీ web server config, ఎందుకంటే తప్పు సమాధానం sites ను నిలిపివేస్తుంది.

Upgrade సమయంలో ఏ services ను restart చేయాలో కూడా needrestart ద్వారా అడుగుతుంది. మొత్తం list ను accept చేయండి. Disk నుంచి delete చేసిన shared library file ను ఉపయోగిస్తూ daemon ఇంకా run అయితే, మీరు గమనించని సమయంలో వచ్చే ఏదైనా తర్వాతి request పై అది crash కావచ్చు.

దశ 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 zero units ను చూపాలి. అది ఏదైనా unit ను చూపిస్తే, అదే మీ తదుపరి పని. చివరి apt update, release images నిర్మించిన తర్వాత విడుదలైన updates ను పొందుతుంది.

PostgreSQL 16 నుంచి 18కి: నిశ్శబ్దంగా వెనుకబడిపోయే cluster

Ubuntu 24.04లో PostgreSQL 16, Ubuntu 26.04లో PostgreSQL 18 విడుదలవుతాయి. Upgrade సమయంలో 18ను 16 పక్కనే install చేస్తారు; మీ data తరలించబడదు. Debian యొక్క postgresql-common layer కొత్త major version కోసం తదుపరి ఖాళీ portపై కొత్త, ఖాళీ clusterను సృష్టిస్తుంది. అందువల్ల 16 అన్ని dataతో port 5432ను కొనసాగిస్తుంది, 18 ఖాళీగా 5433పై ఉంటుంది. మీ application 5432తోనే మాట్లాడుతుంది, కాబట్టి ఏ సమస్యా కనిపించదు. ఈ కారణంగానే చాలామంది దీనిని నెలల తరువాత గుర్తిస్తారు.

pg_lsclusters

రెండు clusters జాబితాలో కనిపిస్తే, మీరు migration చేయలేదని అర్థం. Applicationను ఆపగలిగినప్పుడు దీన్ని చేయండి:

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

ముందుగా ఖాళీగా ఉన్న 18 clusterను తొలగించండి. ఇప్పటికే ఉన్న target clusterలో pg_upgradecluster రాయదు. Default method 16 నుంచి dump తీసుకుని, దాన్ని 18లోకి reload చేస్తుంది. అందువల్ల database పరిమాణానికి దాదాపు సమానమైన ఖాళీ disk space అవసరం. పెద్ద databaseలో -m upgrade బదులుగా pg_upgradeను ఉపయోగిస్తుంది; ఇది చాలా వేగంగా పూర్తవుతుంది. ప్రక్రియ పూర్తయిన తరువాత Port columnను చదవండి: కొత్త cluster 5432ను స్వీకరిస్తుంది, పాతది stopped స్థితిలో ఉంటుంది. analyze passను మీరే అమలు చేయండి. తాజాగా load చేసిన clusterలో statistics ఉండవు, కాబట్టి మొదటి queries నెమ్మదిగా అమలవుతాయి.

కొన్ని రోజుల పాటు కొత్త clusterకు వ్యతిరేకంగా applicationను పరీక్షించండి. ఆ తరువాత మాత్రమే పాత clusterను తొలగించండి:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

పాత cluster యొక్క data directory మీకు లభించే వేగవంతమైన rollback మార్గం. Upgrade చేసిన రోజే దాన్ని తొలగించవద్దు.

MySQL 8.0 నుంచి 8.4: server ను నిలిపివేసే తొలగించిన option

26.04 MySQL ను 8.0 నుంచి 8.4 LTS కు upgrade చేస్తుంది. ఈ మార్పుల్లో రెండు serverలను ప్రభావితం చేస్తాయి.

మొదట, కొత్త version తొలగించిన option configurationలో ఉంటే mysqld ప్రారంభం కావడానికి నిరాకరిస్తుంది. పాత guidesలో దాన్ని set చేయమని తరచుగా సూచించినందున default_authentication_plugin సాధారణంగా కనిపించే సమస్య. service విఫలమవుతుంది. journalctl -u mysql -n 50 తెలియని variable ను నేరుగా చూపిస్తుంది. /etc/mysql/mysql.conf.d/ కింద ఉన్న file నుంచి ఆ line ను తొలగించి, తరువాత sudo systemctl start mysql.

రెండవది, 8.4లో mysql_native_password plugin defaultగా enable అయి ఉండదు. అందువల్ల దాన్ని ఇంకా ఉపయోగిస్తున్న account అసలు login చేయలేరు. మీరు ఇంకా 8.0లో ఉన్నప్పుడే ఈ command ను అమలు చేయండి:

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

mysql_native_password చూపించే ప్రతి account ను upgradeకు ముందు మార్చండి. తరువాత మీ 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ను తిరిగి enable చేయవచ్చు. దీన్ని ముగింపు తేదీ ఉన్న తాత్కాలిక పరిష్కారంగా మాత్రమే పరిగణించండి. ఆ plugin పూర్తిగా తొలగించబడే దిశగా ఉంది.

PHP 8.3 నుంచి 8.5కి మారినప్పుడు: మీ vhostలు లేని socket ను సూచిస్తున్నాయి

24.04లో PHP 8.3, 26.04లో PHP 8.5 విడుదలవుతాయి. Packages version ఆధారిత pathsలో install అవుతాయి. మీ web server config ను ఏదీ స్వయంచాలకంగా మార్చదు. fastcgi_pass unix:/run/php/php8.3-fpm.sock; ను కలిగి ఉన్న nginx vhost ఇప్పుడు ఏ process సృష్టించని socket ను సూచిస్తుంది. అందువల్ల ప్రతి PHP request 502 ను తిరిగి ఇస్తుంది. nginx error log లో ఇది కనిపిస్తుంది:

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

దాన్ని కొత్త socket కు మార్చి, 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

mod_php ఉపయోగించే Apacheలో లక్షణం వేరుగా ఉంటుంది. Apache అసలు start కాదు. sudo apache2ctl -t, file ఉనికిలో లేనందున libphp8.3.so ను load చేయలేకపోతున్నట్లు చూపిస్తుంది. Enabled module అనేది ఇక లేని package కు symlink అయి ఉంటుంది.

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

మీరు Ubuntu 24.04పై LAMP stack ఉపయోగించి serverను నిర్మించి ఉంటే, ఈ రెండు pathsను తప్పక పరిశీలించండి. ఆ guide version ఆధారిత module name మరియు version ఆధారిత socketతో configurationను వదిలి ఉంటుంది.

మీ php.ini tuning కూడా కొత్త versionకు మారదు. memory_limit, upload_max_filesize మరియు మీరు సెట్ చేసిన ఇతర విలువలు /etc/php/8.3/లో ఉంటాయి. కొత్త tree defaultsతో ప్రారంభమవుతుంది. రెండు filesను diff చేసి, విలువలను చేతితో copy చేయండి. పాత file మొత్తాన్ని కొత్తదానిపై copy చేస్తే 8.3 defaults, 8.5 installలోకి వస్తాయి. తరువాత php -m అమలు చేసి compare చేయండి. php8.3-redisగా install చేసిన extensionకు దాని php8.5- package అవసరం. అది PPA నుంచి వచ్చి ఉంటే, upgrader ఆ sourceను disable చేసి ఉండవచ్చు. అప్పుడు extension పూర్తిగా missingగా ఉంటుంది.

Certificates కోసం ప్రత్యేకంగా ఒక check చేయాలి. Upgrade తర్వాత sudo certbot renew --dry-run అమలు చేయండి. ఇది live certificateను మార్చకుండా, web server reload hookతో సహా మొత్తం renewal pathను పరీక్షిస్తుంది. service name లేదా మారిపోయిన binaryను పిలిచే hook ఇక్కడ మీ ముందే fail అవుతుంది. అది 60 రోజులకు నిశ్శబ్దంగా fail కాకుండా ముందుగానే తెలుస్తుంది. nginxలో Let's Encryptతో Certbotలో ఆ hooks ఎలా ఉండాలో వివరించబడింది.

SSH: మీరు పనిచేస్తున్న session ను ముగించే వైఫల్యం

sshd_config prompt వద్దే చాలామంది తమకు తామే access ను కోల్పోతారు. Y కు సమాధానం ఇస్తే maintainer file install అవుతుంది. దాంతో మీ PermitRootLogin, PasswordAuthentication, AllowUsers, Port మరియు మీరు జోడించిన ప్రతి ఇతర line తొలగిపోతాయి. మీ firewall custom port ను మాత్రమే అనుమతిస్తే, packaged config 22 పై listen చేస్తే, తదుపరి connection తిరస్కరించబడుతుంది. మీరు ప్రస్తుతం ఉపయోగిస్తున్న session మీకు మిగిలిన చివరి session అవుతుంది.

Upgrade కు ముందు దీన్ని నివారించండి. 24.04 లో /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf తో ప్రారంభమవుతుంది. OpenSSH ప్రతి setting కోసం మొదట చదివిన value ను ఉంచుతుంది. అందువల్ల పైభాగంలో చేర్చిన drop-in, దాని కింద ఉన్న ఏ setting కంటే ముందుగా అమలవుతుంది. dpkg కు చెందని file లోకి మీ settings ను తరలించండి:

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 లో మీకు చెందినదేమీ లేకపోతే, ఆ prompt ఇక ప్రాధాన్యం ఉండదు. మీరు ఏ సమాధానం ఇచ్చినా మీ settings అలాగే ఉంటాయి, ఎందుకంటే అవి వేరే file లో ఉంటాయి.

Custom port కోసం మరో check అవసరం. అది మీరు అనుకుంటున్న చోట ఉండకపోవచ్చు:

systemctl is-enabled ssh.socket

అది enabled ను చూపిస్తే, listening port ను systemd నిర్వహిస్తోంది. sshd_config లోని Port line పట్టించుకోబడదు. Ubuntu 22.10 నుంచి sshd కోసం socket activation ను ఉపయోగిస్తోంది. అందువల్ల Port 2222 ను మార్చినా ఎలాంటి ప్రభావం కనిపించదు. sudo systemctl edit ssh.socket తో socket unit లోనే దాన్ని సెట్ చేయండి:

[Socket]
ListenStream=
ListenStream=2222

ఖాళీ ListenStream= అవసరం. ఇది inherited value ను తొలగిస్తుంది. ఇది లేకపోతే socket 2222 తో పాటు 22 పైన కూడా listen చేస్తుంది. sudo systemctl daemon-reload && sudo systemctl restart ssh.socket తో దాన్ని అమలు చేయండి.

Upgrade తర్వాత, మీరు ప్రస్తుతం ఉపయోగిస్తున్న session ను close చేయడానికి ముందు:

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

తర్వాత మీ స్వంత machine లో రెండో terminal తెరిచి, మళ్లీ login చేయండి. ఆ రెండో terminal లో పనిచేసే shell మాత్రమే తుది నిర్ధారణ. అది పనిచేసే వరకు మొదటి session ను open గా ఉంచండి. VPSలో SSHను బలోపేతం చేయడం లో ఆ drop-in లో ఉంచాల్సిన ఉపయోగకరమైన settings వివరించబడ్డాయి.

ఇప్పటికే ఆలస్యమై ఉంటే, మీ provider యొక్క web console ద్వారా SSH ను అసలు ఉపయోగించని login ను పొందవచ్చు. అక్కడ login చేసి, config ను సరిచేసి, sudo sshd -t ను అమలు చేసి, service ను restart చేయండి. Upgrade సమయంలో కాకుండా, upgrade కు ముందే console access ను test చేయడానికి ఆ console ఉండటమే కారణం.

FAQ

Ubuntu 24.04లో do-release-upgrade "No new release found" అని ఎందుకు చూపిస్తుంది?

Ubuntu Serverలో /etc/update-manager/release-upgrades లో Prompt=lts ఉండటం దీనికి కారణం. ఆ setting తదుపరి long term support release యొక్క మొదటి point release అందుబాటులోకి వచ్చిన తర్వాత మాత్రమే దాన్ని అందిస్తుంది. Ubuntu 26.04 LTS 23 April 2026న విడుదలైంది. 26.04.1 27 August 2026న విడుదల కావాల్సి ఉంది. ఆ తేదీ వరకు 24.04 serverకు ఏ కొత్త release కనిపించదు. ఈ settingను అలాగే ఉంచండి. Prompt=normal కు మార్చవద్దు. అలా చేస్తే interim releases ద్వారా upgrade చేయాల్సి వస్తుంది.

Upgrade పూర్తి చేయడానికి serverను reboot చేయాలా?

అవును. Upgrade కొత్త kernel, కొత్త C library, కొత్త init systemను install చేస్తుంది. System restart అయ్యే వరకు నడుస్తున్న system పాత వాటినే ఉపయోగిస్తుంది. చివరలో reboot చేయమని do-release-upgrade అడుగుతుంది. "తర్వాత" reboot చేస్తామని serverను అలాగే నడిపితే, అది రెండు releasesకు చెందిన భాగాల మిశ్రమంతో నడుస్తుంది. Server తిరిగి వచ్చిన తర్వాత, కొత్త kernel కోసం uname -r ను పరిశీలించండి. Upgrade తర్వాత ప్రారంభం కాని services కోసం systemctl --failed ను పరిశీలించండి.

In-place upgrade చేయాలా, లేక కొత్త 26.04 serverను నిర్మించాలా?

సాధ్యమైనప్పుడు కొత్త serverను నిర్మించండి. కొత్త VPSలో stackను install చేసి, dataను restore చేసి, పాత server ఇంకా trafficను అందిస్తున్నప్పుడే అన్నింటినీ test చేయవచ్చు. అందువల్ల rollback backup నుంచి restore చేయడం కాకుండా DNSలో మార్పు చేయడంతో పూర్తవుతుంది. Serverలో తరలించడం కష్టమైన state ఉన్నప్పుడు, provider ప్రతి machineకు billing చేస్తున్నప్పుడు, లేదా snapshot మరియు నిర్ధారిత console access ఉన్నప్పుడు in-place upgrade చేయండి. In-place విధానం సాధారణంగా బాగా పరీక్షించబడింది. అయితే అది అమలయ్యే గంటలో rollbackకు అవకాశం ఉండదు.

Upgrade సమయంలో నా SSH connection తెగిపోతే ఏమవుతుంది?

సాధారణ login shellలో process SIGHUPను స్వీకరించి మధ్యలోనే ఆగిపోతుంది. దాంతో dpkg సగం మాత్రమే configure అవుతుంది. దాన్ని tmux లేదా screen లో ప్రారంభిస్తే process కొనసాగుతుంది. మళ్లీ connect అయిన తర్వాత tmux attach -t upgrade ను అమలు చేసి upgradeను కొనసాగించవచ్చు. Upgrader రెండో మార్గంగా port 1022పై అదనపు SSH daemonను కూడా ప్రారంభిస్తుంది. అయితే ఆ port కోసం firewall ruleను తెరవదు. కాబట్టి ముందుగా 1022ను మీరే allow చేసి, తర్వాత దాన్ని close చేయండి.

Upgrade తర్వాత నా PHP site 502ను చూపిస్తోంది. ఏమి విఫలమైంది?

Version మారడంతో PHP FPM socket path మారింది. Ubuntu 24.04లో PHP 8.3, Ubuntu 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కు update చేసి, sudo nginx -t ను అమలు చేసి, తరువాత nginxను reload చేయండి. mod_phpతో Apache ఉపయోగిస్తున్నప్పుడు సమానమైన పరిష్కారం sudo a2dismod php8.3 ను అమలు చేసి, తరువాత sudo a2enmod php8.5 మరియు restartను అమలు చేయడం.