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 ఆ విడుదలలో చేర్చబడతాయి. ఈ numbering మీకు కొత్తగా ఉంటే, 26.04.1 వేరే Ubuntu కాదు; నాలుగు నెలల fixesను mediaలో చేర్చిన అదే 26.04, అందుకే ఇప్పటికే ఉన్న serverకు Canonical అందించే మొదటి version ఇది.

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

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

అది మీ server లోని లోపం కాదు. 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 విడుదలల ద్వారా వరుసగా వెళ్లమని సూచిస్తుంది. ఇవన్నీ interim releases కాగా, వాటి support కాలం ఇప్పటికే ముగిసింది. lts గానే ఉంచి వేచి ఉండండి. Canonical schedule లోని తేదీలు మారవచ్చు. ఆ రోజు ఎటువంటి మార్పు లేకుండా గడిచిపోతే మళ్లీ పరిశీలించండి. ఇంకా 22.04 పై ఉన్న server ఈ upgrade ను నేరుగా చేయలేడు. upgrader ఎల్లప్పుడూ తదుపరి LTS ను మాత్రమే అందిస్తుంది. అందువల్ల 24.04 ద్వారా 22.04 ను 26.04 కు upgrade చేయడం లో మొదటి దశతో పాటు రెండో దశకు ముందు తీసుకోవాల్సిన snapshot వివరించబడింది.

కింద ఉన్న ప్రతి commandను మీరు స్వయంగా, మీ స్వంత serverపై, ఇచ్చిన క్రమంలో run చేయాలి. మీరు upgrade చేస్తున్న machineపైనే release upgradeను rehearsal చేయలేరు. ఇది 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. "సంఖ్య పెరిగింది" అనేది customers కు సేవలందిస్తున్న machine ను మార్చడానికి కారణం కాదు.

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

• మీరు మీ provider console (VNC లేదా serial) ను ఎప్పుడూ తెరిచి, దాని ద్వారా login చేయలేదు. SSH పనిచేయకపోతే server కు తిరిగి చేరడానికి ఆ console మాత్రమే మార్గం. మీరు access కోల్పోయిన తర్వాత అది పనిచేయదని తెలుసుకోవడం చాలా ఆలస్యం.
• మీరు ఒక గంట 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 ను కవర్ చేసి నిమిషాల్లో పునరుద్ధరిస్తుంది. అయితే databaseలు write చేస్తున్న సమయంలో snapshot తీసుకోబడుతుంది. అందువల్ల అది application-consistent కాకుండా crash-consistent గా ఉంటుంది. సర్వర్ వెలుపల నిల్వ చేసిన restic తో తీసుకునే file-level backup ద్వారా వ్యక్తిగత 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 ను ఆపాలి. /etc tarball ను మీరు వాస్తవంగా ఉపయోగిస్తారు, ఎందుకంటే upgrade అడగబోయే ప్రతి config file అందులో ఉంటుంది.

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

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

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

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 కూడా pin కాలేదని అర్థం. అది జాబితా చేసే ప్రతి package పై package name తో sudo apt-mark unhold అమలు చేసి hold ను తొలగించండి. లేదా ఆ hold కు కారణం ఉందని అంగీకరించి ఇక్కడే ఆపండి.

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

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

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

df -h / /boot

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

మీరు ప్రారంభించే ముందు ఆపాల్సిన మరో విషయం ఉంది: స్వయంచాలక 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 తనిఖీ చేయండి

do-release-upgrade Ubuntu కి చెందని ప్రతి apt source ను నిలిపివేస్తుంది. ఎందుకంటే noble కోసం build చేసిన package, resolute system ను దెబ్బతీయవచ్చు. ఇది గుర్తించిన source లను తరువాత మళ్లీ ప్రారంభిస్తుంది. మిగిలిన వాటిని 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 సమయంలో రెండూ disabled అవుతాయి. ఏ Ubuntu archive అందించని installed packages ను ubuntu-security-status --thirdparty జాబితా చేస్తుంది. మీరు అదనంగా install చేసిన packages యొక్క వాస్తవ సంఖ్య ఇదే. /etc/apt/preferences.d/ లోని ఏదైనా entry ఒక pin. noble కోసం రాసిన pin, కొత్త release లో కూడా పాత package ను ఎంచుకునేలా చేస్తుంది.

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

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

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

దశ 4: సాధారణ SSH shellలో కాకుండా tmuxలో upgrade అమలు చేయండి

సాధారణ login shellలో do-release-upgrade నడుస్తున్నప్పుడు మీ connection తెగిపోతే, processకు SIGHUP అందుతుంది. Unpacking పూర్తికాకముందే process ఆగిపోతుంది. దాంతో dpkg సగం మాత్రమే configure అవుతుంది. మళ్లీ connection ఏర్పాటు చేసుకోవడానికి అవసరమైన 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.

ఆ port కోసం ఇది మీ firewallలో ruleను స్వయంగా తెరవదు. అనుమతి లేకుండా firewallలో రంధ్రం తెరవడం ఊహించని సమస్యలకు దారితీయవచ్చు. ప్రారంభించే ముందు మీరు స్వయంగా 1022ను తెరవండి. sudo ufw delete allow 1022/tcp పూర్తయిన తర్వాత ఆ portను మూసివేయండి. మీ provider server వెలుపల, తన control panelలో రెండవ firewallను నిర్వహిస్తూ ఉండవచ్చు.

కనెక్షన్ ఎలాగైనా తెగిపోతే, మళ్లీ login చేసి tmux attach -t upgrade ను అమలు చేయండి. మీరు లేని సమయంలో upgrade కొనసాగి ఉండవచ్చు. అది కొనసాగకపోతే, తిరిగి వచ్చినప్పుడు dpkg సగం మాత్రమే configure అయి ఉండవచ్చు లేదా apt sources లో కొంత భాగం noble లో, మిగిలిన భాగం resolute లో ఉండవచ్చు. విఫలమైన release upgrade ను పునరుద్ధరించడం అనే విభాగంలో package state ను సరిచేయడం, ఎప్పుడు repair చేయడం ఆపి snapshot ను restore చేయాలో తెలుసుకోవడం గురించి వివరించారు.

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

మీరు లేదా ఏదైనా script మార్చిన files కు మాత్రమే dpkg prompt చూపిస్తుంది. కాబట్టి ప్రతి prompt మీరు ఉద్దేశపూర్వకంగా సవరించిన file కు సంబంధించినదే. దాన్ని తొలగించడానికి Enter నొక్కడం వల్ల hardened server నిశ్శబ్దంగా default configuration కు మారుతుంది.

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 పై ఎప్పుడూ అమలు కాలేదు.

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

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

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

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

దశ 6: reboot చేసి, machine ను పరిశీలించండి

sudo reboot

machine మళ్లీ ప్రారంభమైన తర్వాత:

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 సమయంలో PostgreSQL 18ను 16 పక్కనే install చేస్తుంది; మీ data తరలించబడదు. Debian యొక్క postgresql-common layer కొత్త major version కోసం తదుపరి ఖాళీ portపై కొత్త empty clusterను సృష్టిస్తుంది. అందువల్ల 16 మీ మొత్తం dataతో port 5432ను కొనసాగిస్తుంది, 18 మాత్రం ఖాళీగా port 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 పద్ధతి 16లోని dataను dump చేసి, దాన్ని 18లోకి reload చేస్తుంది. అందువల్ల database పరిమాణానికి దాదాపు సమానమైన ఖాళీ disk space అవసరం. పెద్ద databaseపై -m upgrade బదులుగా pg_upgrade ఉపయోగిస్తుంది. ఇది చాలా వేగంగా పూర్తవుతుంది. ప్రక్రియ పూర్తైన తర్వాత Port columnను పరిశీలించండి. కొత్త cluster 5432ను స్వీకరిస్తుంది. పాత cluster 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 కు మారుస్తుంది. ఈ మార్పులో రెండు విషయాలు serverలను ప్రభావితం చేస్తాయి.

మొదట, configలో కొత్త version తొలగించిన option ఉంటే mysqld ప్రారంభం కావడానికి నిరాకరిస్తుంది. పాత guidesలో దీన్ని సెట్ చేయమని తరచుగా చెప్పడం వల్ల 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గా enabled ఉండదు. అందువల్ల దాన్ని ఇంకా ఉపయోగిస్తున్న account login చేయలేను. మీరు ఇంకా 8.0లో ఉన్నప్పుడే పరిశీలించండి:

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 కు symbolic link అయి ఉంటుంది.

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

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

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

sshd_config prompt వద్ద users తమను తాము system నుంచి బయటకు లాక్ చేసుకుంటారు. 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 edit చేసినా ప్రభావం కనిపించదు. sudo systemctl edit ssh.socket తో socket unit పై setting ను అమలు చేయండి:

[Socket]
ListenStream=
ListenStream=2222

ఖాళీ ListenStream= అవసరం. ఇది inherited value ను తొలగిస్తుంది. ఇది లేకపోతే socket 22 తో పాటు 2222 పై కూడా 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 ను run చేసి, 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కు చెందిన భాగాల మిశ్రమంతో system నడుస్తుంది. 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 విధానం విస్తృతంగా ఉపయోగించబడింది. అయితే అది అమలులో ఉన్న గంటలో తిరిగి మార్చలేని మార్గం.

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

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

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

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