do-release-upgrade: no new release found పరిష్కారం

do-release-upgrade ఎందుకు కొత్త release దొరకలేదని చెబుతుంది

do-release-upgrade తో ముగిసే No new release found. అనేది దాదాపు ఎప్పుడూ పాడైపోయిన సాధనం కాదు. మీరు అడిగిన మార్గం ఆ సమయంలో మూసివేయబడింది, మరియు ఆ సాధనం దానిని సాధ్యమైనంత క్లుప్తంగా తెలియజేస్తుంది. దీనిని ఐదు అంశాలు మూసివేస్తాయి: /etc/update-manager/release-upgrades లోని Prompt సెట్టింగ్, LTS (long term support) అప్‌గ్రేడ్‌లపై పాయింట్ రిలీజ్ గేట్, థర్డ్ పార్టీ రిపోజిటరీలు, హోల్డ్ చేయబడిన లేదా సగం కాన్ఫిగర్ చేయబడిన ప్యాకేజీలు, మరియు సపోర్ట్ ముగిసిన రిలీజ్.

వాటిని ఈ క్రమంలో తనిఖీ చేయండి. ప్రతి అంశానికి మీ సర్వర్‌కు అది వర్తిస్తుందో లేదో నిరూపించే ఒక కమాండ్ ఉంది, కాబట్టి మీరు ఈ ఐదింటిలో ఏది సమస్యగా ఉందో ఊహించాల్సిన అవసరం లేదు.

check-only ఫ్లాగ్ వాస్తవానికి ఏమి తెలియజేస్తుంది

sudo do-release-upgrade -c
echo $?

-c అనేది check-only కోసం. ఇది Canonical యొక్క release metadata ను HTTPS (hypertext transfer protocol secure) ద్వారా చదివి, సమాధానాన్ని ప్రింట్ చేస్తుంది. ఇది ఎటువంటి upgrade tool ను డౌన్‌లోడ్ చేయదు మరియు ఎటువంటి source file ను మార్చదు. రెండు అవుట్‌పుట్‌లు ముఖ్యమైనవి:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

స్క్రిప్ట్‌ల కోసం exit code అదే సమాధానాన్ని కలిగి ఉంటుంది. ఒక release అందుబాటులో ఉన్నప్పుడు ఇది 0 గా ఉంటుంది మరియు ఏదీ లేనప్పుడు 1 గా ఉంటుంది. ఇది సాధారణ shell పద్ధతికి విరుద్ధంగా ఉంటుంది, కాబట్టి దీని చుట్టూ ఏదైనా స్క్రిప్ట్ నిర్మించే ముందు జాగ్రత్తగా చదవండి.

మీ login banner ఇప్పటికీ పాత సమాధానాన్ని చూపిస్తుంటే, అది cache చేయబడినది. ఆ లైన్ /etc/update-motd.d/91-release-upgrade నుండి వస్తుంది, ఇది నెట్‌వర్క్‌ను అడగడానికి బదులుగా నిల్వ చేసిన ఫలితాన్ని ప్రింట్ చేస్తుంది. దీన్ని sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd తో రిఫ్రెష్ చేయండి, లేదా కేవలం -c ని నమ్మండి. ఆ banner చివరిగా జరిగిన చెక్ ఫలితాన్ని మాత్రమే పునరావృతం చేస్తుంది.

ఈ చెక్ changelogs.ubuntu.com ని చేరుకోవాల్సి ఉంటుంది. కఠినమైన outbound firewall లేదా proxy వెనుక ఉన్న సర్వర్‌లో ఈ టూల్ అడగలేదు, కాబట్టి అది ఏమీ కనుగొనలేదు.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

HTTP/2 200 లైన్ అంటే సర్వర్ metadata ను చూడగలదని అర్థం. curl: (28) Connection timed out అంటే మీ egress నియమాలే అసలు కారణమని అర్థం, మరియు APT (advanced package tool) ఫైళ్లను ఎంత ఎడిట్ చేసినా సమాధానం మారదు.

ఒకవేళ కమాండ్ పూర్తిగా లేకపోతే, అది ubuntu-release-upgrader-core లో ఉంటుంది. Minimal cloud images కొన్నిసార్లు ఆ ప్యాకేజీని వదిలివేస్తాయి.

sudo apt install ubuntu-release-upgrader-core

ఏదైనా మార్చే ముందు /etc/update-manager/release-upgrades ఫైల్‌ను చదవండి

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

ఈ ఫైల్‌లో దాని డాక్యుమెంటేషన్ వ్యాఖ్యల (comments) రూపంలో ఉంటుంది. ఇందులో మూడు విలువలు చెల్లుబాటు అవుతాయి:

• never: కొత్త release కు అప్‌గ్రేడ్‌ను ఎప్పటికీ తనిఖీ చేయవద్దు మరియు అనుమతించవద్దు.
• normal: ప్రస్తుతం నడుస్తున్న release తర్వాత వెంటనే వచ్చే supported release ను ఆఫర్ చేయండి.
• lts: ప్రస్తుతం నడుస్తున్న release తర్వాత వచ్చే మొదటి LTS release ను ఆఫర్ చేయండి.

Prompt=never ఈ మూడింటిలో దేనినైనా నిర్ధారించడం సులభం, ఎందుకంటే ఈ టూల్ తన అవుట్‌పుట్‌లో ఫైల్ పేరును మరియు సెట్టింగ్‌ను రెండింటినీ పేర్కొంటుంది:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

హోస్టింగ్ ప్రొవైడర్లు మరియు కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ టూల్స్ never ను ఉద్దేశపూర్వకంగా సెట్ చేస్తాయి, దీనివల్ల సర్వర్ల సమూహం (fleet) వేర్వేరు release ల మధ్య మారిపోకుండా ఉంటుంది. ఒకవేళ మీరు దీన్ని అక్కడ చూస్తే, ఎవరో ఒకరు దీన్ని ఎంచుకున్నారని అర్థం. మీరు లాంగ్ టర్మ్ సపోర్ట్ ట్రాక్‌లో ఉండాలనుకునే సర్వర్ కోసం దీన్ని lts కి మార్చండి, ఒకవేళ మీ ఆటోమేషన్ పాత విలువను ఆశిస్తుంటే పని పూర్తయ్యాక తిరిగి పాత విలువకే మార్చండి.

ఆ వ్యాఖ్యలలోని ఒక చిన్న విషయం చాలామందిని అయోమయానికి గురి చేస్తుంది. Prompt=lts సెట్ చేయబడి, ప్రస్తుతం నడుస్తున్న release స్వయంగా LTS release కానప్పుడు, అప్‌గ్రేడర్ ఆ సెట్టింగ్‌ను normal గా పరిగణిస్తుంది. 25.10 మెషీన్‌పై ఈ రెండు విలువలు ఒకేలా పనిచేస్తాయి. కానీ 24.04 మెషీన్‌పై అలా జరగదు, ఆ వ్యత్యాసమే తదుపరి విభాగం మొత్తం.

LTS నుండి LTS అప్‌గ్రేడ్ మొదటి పాయింట్ రిలీజ్ కోసం ఎందుకు వేచి ఉంటుంది

Prompt అప్‌గ్రేడర్ ఏ మెటాడేటా ఫైల్‌ను చదవాలో నిర్ణయిస్తుంది. ఈ చిరునామాలు /etc/update-manager/meta-release లో ఉంటాయి:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts అనేది meta-release-lts ని చదువుతుంది. Prompt=normal అనేది meta-release ని చదువుతుంది. ఈ రెండు ఫైళ్లు ప్రతి రిలీజ్ వివరాలను చిన్న కీ బ్లాక్‌లలో వివరిస్తాయి. ఒక రిలీజ్ యొక్క Supported: ఫ్లాగ్ 1 గా ఉన్నప్పుడు మాత్రమే అప్‌గ్రేడర్ ఆ రిలీజ్‌ను ఆఫర్ చేస్తుంది. వీటిని మీరు అదే సర్వర్ నుండి ఇలా చూడవచ్చు:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

13 ఆగస్టు 2026న పరిశీలించినప్పుడు, Ubuntu 26.04 విషయంలో ఈ రెండు ఫైళ్లు భిన్నమైన సమాచారాన్ని చూపుతున్నాయి. LTS ఫైల్ ఇలా చెబుతోంది:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

సాధారణ ఫైల్ ఇలా చెబుతోంది:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

LTS ఫైల్‌లోని ఆ Supported: 0 అనేది ఒక అడ్డంకి (gate). డిఫాల్ట్ Prompt=lts ని ఉపయోగిస్తున్న 24.04 సర్వర్ ఆ ఫైల్‌ను చదివినప్పుడు, అందుబాటులో ఉన్న కొత్త LTS రిలీజ్ ఏదీ కనిపించదు, కాబట్టి అది No new release found. అని చూపిస్తుంది. మీ మెషీన్‌లో ఎటువంటి లోపం లేదు. Canonical ఇంకా ఆ మార్గాన్ని తెరవలేదు.

మొదటి point release విడుదలైనప్పుడు flag 1 కు మారుతుంది. Ubuntu 26.04.1 ను 27 August 2026న విడుదల చేయాలని షెడ్యూల్ చేశారు. అయితే release schedules మారవచ్చు. అందువల్ల calendar ను కాకుండా metadata ను పరిశీలించండి. Point release అనేది Ubuntu యొక్క కొత్త version కాదు. ఇది launch నుంచి వచ్చిన ప్రతి update ను తాజా install mediaలో చేర్చిన అదే release మాత్రమే. కాబట్టి నడుస్తున్న serverకు ముఖ్యమైనది media కాదు, అది తెరవగల gate. ఈ ఆలస్యం ఉద్దేశపూర్వకమే. ముందుగా upgrade చేసే వారు ఎదురయ్యే blockers ను గుర్తిస్తారు. పెద్ద సంఖ్యలో LTS servers upgrade చేయడానికి ముందు ఆ సమస్యలు పరిష్కరించబడతాయి. మీరు ఇది చదివే సమయానికి ఆ తేదీ దాటిపోయి ఉంటే, 26.04.1లో ఏమి విడుదలైంది, అది 24.04 serverకు ఏమి సూచిస్తుంది అనే విభాగం అక్కడి నుంచి వివరిస్తుంది.

దాంతో నిజాయితీగా పరిగణించగల రెండు ఎంపికలు మాత్రమే మిగులుతాయి. మీరు నిరంతరం పర్యవేక్షించాల్సిన అవసరం లేని ఏ server‌కైనా సరైన నిర్ణయం point release కోసం వేచి ఉండటం. లేదా Prompt=normal ను సెట్ చేయండి. ఇది అదే tool ను meta-release వద్దకు సూచిస్తుంది. అక్కడ 26.04 ఇప్పటికే supported గా గుర్తించబడింది. రెండవ మార్గం released 26.04 కు upgrade చేస్తుంది. ఇది development build కు upgrade చేయదు. అందువల్ల snapshot నుంచి restore చేయగల machine పై ఈ విధానాన్ని సమర్థించవచ్చు. పని పూర్తయిన తర్వాత విలువను తిరిగి lts కు సెట్ చేయండి. ఈ ప్రక్రియలోని ప్రతి దశ 24.04 నుంచి 26.04 server upgrade చేసే పూర్తి మార్గదర్శకంలో ఉంది. ఇంకా 22.04 పై ఉన్న server కు అదనపు దశ అవసరం. ఎందుకంటే Prompt=lts ఎల్లప్పుడూ తదుపరి LTS release ను మాత్రమే అందిస్తుంది. కాబట్టి 22.04 నుంచి 26.04 కు వెళ్లే మార్గం ముందుగా 24.04 గుండా వెళుతుంది.

అప్‌గ్రేడ్‌ను నిరోధించే థర్డ్ పార్టీ రిపోజిటరీలు మరియు PPAలు

అప్‌గ్రేడర్ మీ APT సోర్స్‌లను కొత్త రిలీజ్‌కు అనుగుణంగా మారుస్తుంది. కొత్త రిలీజ్ కోసం అందుబాటులో ఉన్న రిపోజిటరీలకు మాత్రమే ఇది సాధ్యమవుతుంది, కాబట్టి మిగిలిన వాటిని కామెంట్ చేస్తుంది. దీనికి గల కారణాలు ఒక్కో ఎంట్రీకి ఒక లైన్ చొప్పున ముద్రించబడతాయి, అవి: was disabled (unknown mirror), was disabled (unknown dist), మరియు was disabled (no Release file).

noble కోసం రూపొందించిన PPAకు, సర్వర్‌లో resolute కోసం డైరెక్టరీ ఉండదు. కాబట్టి అప్‌గ్రేడర్ కొత్త సిరీస్ కోసం Release ఫైల్‌ను పొందలేదు మరియు ఆ ఎంట్రీని డిసేబుల్ చేస్తుంది. ఇది సాధారణంగా మీరు అంగీకరించదగ్గ హెచ్చరిక. అయితే, కొత్త రిలీజ్‌లో కూడా ఉన్న ప్యాకేజీని ఒక థర్డ్ పార్టీ రిపోజిటరీ అందిస్తున్నప్పుడు ఇది అప్‌గ్రేడ్‌ను నిలిపివేస్తుంది. ఎందుకంటే అప్‌గ్రేడ్ గణనలో రెండు అభ్యర్థులు ఉంటారు మరియు రెండింటినీ సంతృప్తిపరిచే మార్గం ఉండదు.

దీనిని టూల్ నిర్ణయించే వరకు వేచి ఉండకుండా, సుదీర్ఘమైన అప్‌గ్రేడ్ ప్రక్రియను ప్రారంభించే ముందే మీరే నిర్ణయించుకోండి.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

ప్యాకేజీ పేరుపై apt policy వాడటం ద్వారా, ఇన్‌స్టాల్ చేసిన ప్రతి వెర్షన్ ఏ రిపోజిటరీ నుండి వచ్చిందో తెలుస్తుంది. దీనివల్ల మీరు డిసేబుల్ చేయబోయే సోర్స్‌పై ఏ ప్యాకేజీలు ఆధారపడి ఉన్నాయో ఖచ్చితంగా చూడవచ్చు. సోర్స్‌ను తొలగించడం వల్ల ప్యాకేజీలు డౌన్‌గ్రేడ్ కావు; కాబట్టి PPA నుండి ఇన్‌స్టాల్ చేసిన ప్యాకేజీ అదే వెర్షన్‌లో ఉంటుంది మరియు కొత్త రిలీజ్ కంటే కొత్తదిగా ఉండవచ్చు. ఇది సమస్యగా మారితే, ఆ ప్యాకేజీని కూడా తొలగించి, అప్‌గ్రేడ్ తర్వాత ఆర్కైవ్ నుండి తిరిగి ఇన్‌స్టాల్ చేయండి. Tailscale వంటి మీరు తిరిగి ఉపయోగించాలనుకునే రిపోజిటరీల కోసం, ప్యాకేజీ మళ్లీ ఇన్‌స్టాల్ కావాలంటే వాటి కోడ్‌నేమ్‌ను కొత్త రిలీజ్‌కు అప్‌డేట్ చేయాలి. Ubuntuలో వచ్చే చాలా Tailscale ఇన్‌స్టాల్ లోపాలు దీని వల్లే సంభవిస్తాయి.

దీనికి విరుద్ధమైన ఎంపిక కోసం ఒక ఫ్లాగ్ ఉంది. మాన్యువల్ పేజీ --allow-third-party గురించి ఇలా వివరిస్తుంది: "థర్డ్ పార్టీ మిర్రర్స్ మరియు రిపోజిటరీలను కామెంట్ చేయకుండా, వాటిని ఎనేబుల్ చేసి అప్‌గ్రేడ్ ప్రయత్నించండి." ఆ రిపోజిటరీ ఇప్పటికే టార్గెట్ రిలీజ్ కోసం పబ్లిష్ అయిందని నిర్ధారించుకున్నప్పుడు మాత్రమే దీనిని ఉపయోగించండి. ఒకవేళ అది పబ్లిష్ కాకపోతే, ఆ రిపోజిటరీ ఎప్పుడూ బిల్డ్ చేయని సిరీస్‌కు వ్యతిరేకంగా డిపెండెన్సీ గ్రాఫ్‌ను పరిష్కరించమని మీరు APTని కోరినట్లు అవుతుంది.

Ubuntu 24.04 మరియు ఆ తర్వాత వెర్షన్లలో, చాలా సోర్స్‌లు /etc/apt/sources.list.d/ubuntu.sources లో deb822 ఫార్మాట్‌లో ఉంటాయి. పాత మరియు కొత్త ఫార్మాట్లలో ఒకే రిపోజిటరీ ఉండటం అనేది ఒక ప్రత్యేక లోపం. దీని గురించి deb822 ఫార్మాట్‌లో డూప్లికేట్ సోర్స్ ఎంట్రీ లోపంలో వివరించబడింది.

Held మరియు సగం కాన్ఫిగర్ అయిన ప్యాకేజీలు అప్‌గ్రేడ్ ప్రక్రియను ఆపివేస్తాయి

ఒక release upgrade సమయంలో సిస్టమ్‌లోని దాదాపు ప్రతి ప్యాకేజీని అప్‌డేట్ చేయాల్సి ఉంటుంది. ఏదైనా ఒక ప్యాకేజీ అప్‌డేట్ కాకపోతే, ఆ ప్రక్రియ విఫలమవుతుంది. సిస్టమ్‌ను సగం అప్‌గ్రేడ్ చేసిన స్థితిలో వదిలేయడం కంటే, అప్‌గ్రేడర్ ప్రక్రియను ముందే ఆపివేయడం మంచిది. దీనికి కారణాన్ని కనుగొనడానికి రెండు కమాండ్లు ఉన్నాయి.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold కమాండ్, హోల్డ్ (held) చేయబడిన ప్యాకేజీలను ఒక్కో లైన్‌లో చూపిస్తుంది. సిస్టమ్ క్లీన్‌గా ఉంటే, ఇది ఏమీ చూపదు. ఒక ప్యాకేజీని మార్చవద్దని మాన్యువల్‌గా ఇచ్చిన సూచననే 'hold' అంటారు. ఎవరైనా ఒక kernel లేదా database వెర్షన్‌ను పిన్ చేసి, ఆ విషయాన్ని మర్చిపోయి ఉండవచ్చు. మీకు అవసరం లేని ప్యాకేజీలను sudo apt-mark unhold కమాండ్ మరియు ప్యాకేజీ పేరును ఉపయోగించి రిలీజ్ చేయండి.

dpkg --audit కమాండ్, అన్‌ప్యాక్ అయ్యి కానీ కాన్ఫిగర్ కాని ప్యాకేజీల జాబితాను చూపిస్తుంది. ఇన్‌స్టాలేషన్ మధ్యలో ఆగిపోయినప్పుడు (ఉదాహరణకు సెషన్ డిస్‌కనెక్ట్ అయినప్పుడు) ఇలా జరుగుతుంది. అప్‌గ్రేడర్ వీటిని సరిచేయడానికి ప్రయత్నించి dpkg interrupted, calling dpkg --configure -a అని చూపిస్తుంది, కానీ మీరే స్వయంగా ఆ రిపేర్ చేయడం వల్ల, ఎర్రర్ మెసేజ్ వేగంగా వెళ్ళిపోకుండా మీరు స్పష్టంగా చదవవచ్చు. టూల్ సరిచేయలేని ప్యాకేజీ Package in inconsistent state అనే మెసేజ్‌ను ఇస్తుంది; మీరు మళ్ళీ ప్రయత్నించే ముందు ఆ ప్యాకేజీని సరిచేయాలి.

అప్‌గ్రేడ్ చేసే ముందు, ప్రస్తుతం నడుస్తున్న release ను పూర్తిగా అప్‌డేట్ చేయండి.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

Phased updates ఆప్షన్ చాలా ముఖ్యమైనది. Ubuntu కొన్ని అప్‌డేట్‌లను ఒకేసారి కాకుండా, కొంత శాతం మెషీన్లకు మాత్రమే విడుదల చేస్తుంది. కాబట్టి, సాధారణ apt upgrade కమాండ్ కొన్ని ప్యాకేజీలను వదిలేయవచ్చు, దీనివల్ల మీ సర్వర్ మీరు అనుకున్నంత అప్‌డేట్‌గా ఉండకపోవచ్చు. ఆ ఆప్షన్ అన్ని ప్యాకేజీలను తీసుకుంటుంది. ఒకవేళ kernel అప్‌డేట్ అయితే, ఆ తర్వాత రీబూట్ చేయండి, తద్వారా మీరు ప్రస్తుతం రన్ అవుతున్న kernel నుండే అప్‌గ్రేడ్ అవుతారు. unattended security upgrades ద్వారా ఇప్పటికే ప్యాచ్ అవుతున్న సర్వర్‌కు ఇక్కడ తక్కువ పని ఉంటుంది, అయితే ఆ మెకానిజం డిజైన్ ప్రకారం ఎప్పుడూ release పరిధిని దాటదు.

సాధారణ మద్దతు గడువు ముగిసిన తర్వాత

ఒక interim Ubuntu release తొమ్మిది నెలల పాటు మద్దతును కలిగి ఉంటుంది. ఆ మద్దతు ముగిసినప్పుడు దాని Supported: ఫ్లాగ్ 0 కి మారుతుంది, మరియు సాధారణ మార్గంలో దీని నుంచి ఎటువంటి అప్‌గ్రేడ్ లభించదు. 13 August 2026 న తనిఖీ చేసినప్పుడు, 25.10 గురించి meta-release ఇలా చెబుతోంది:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

అదే సమయంలో ఆర్కైవ్ కూడా మారుతుంది. end of life release కి సంబంధించిన ప్యాకేజీలు archive.ubuntu.com నుంచి తొలగించబడి, old-releases.ubuntu.com లో ఉంచబడతాయి. కాబట్టి apt update అనేది 404 Not Found ని తిరిగి ఇవ్వడం ప్రారంభిస్తుంది, సిస్టమ్‌ను ఇకపై అప్‌డేట్ చేయలేము, మరియు అప్‌గ్రేడర్ ప్రస్తుత సిస్టమ్ ఉండాలని కోరుకుంటుంది కాబట్టి, ఏ ప్రక్రియ ముందుకు సాగదు. ముందుగా సోర్స్‌లను సరిచేయండి.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

archive.ubuntu.com మరియు security.ubuntu.com రెండింటినీ old-releases.ubuntu.com కి పాయింట్ చేయండి, మరియు మీ కోడ్‌నేమ్‌ను అలాగే ఉంచండి. హోస్ట్ పేరు మాత్రమే మారుతుంది.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

మీ సర్వర్ సోర్స్‌లను ఇంకా ఒకే ఫైల్‌లో ఉంచినట్లయితే, దానికి బదులుగా /etc/apt/sources.list పై అదే కమాండ్‌ను రన్ చేయండి. -i.bak ఆప్షన్ ఒరిజినల్ ఫైల్ పక్కనే ఒక బ్యాకప్‌ను రాస్తుంది, కాబట్టి మీరు తప్పుడు ఫైల్‌ను ఎడిట్ చేసినట్లయితే దానిని తిరిగి పునరుద్ధరించవచ్చు. ఆ తర్వాత ఒక క్లీన్ apt update అంటే ఆర్కైవ్ మళ్ళీ అందుబాటులోకి వచ్చిందని అర్థం, మరియు do-release-upgrade ఇప్పుడు మీతో కమ్యూనికేట్ అవుతుంది.

ఇది మిమ్మల్ని ఎంతవరకు తీసుకెళ్తుందో వాస్తవికంగా ఆలోచించండి. Ubuntu ఒక సమయంలో ఒక రిలీజ్ స్టెప్‌కు మాత్రమే మద్దతు ఇస్తుంది, కాబట్టి రెండు లేదా మూడు పాత రిలీజ్‌ల వెనుక ఉన్న సర్వర్‌కు ప్రతి దశను వరుసగా పూర్తి చేయాల్సి ఉంటుంది, మరియు ప్రతి దశలోనూ థర్డ్ పార్టీ రిపోజిటరీ లేదా ప్యాకేజీల వల్ల సమస్యలు రావచ్చు. VPS లో అయితే, ప్రస్తుత LTS వెర్షన్‌తో కొత్త సర్వర్‌ను నిర్మించి, సేవలను అక్కడికి మార్చడం మరియు పాత సర్వర్‌ను మీరు ఖచ్చితంగా నిర్ధారించుకునే వరకు ఉంచడం వేగవంతమైన మార్గం. ఇది మీకు రోల్‌బ్యాక్ అవకాశాన్ని కూడా ఇస్తుంది, ఇది in place upgrade లో సాధ్యం కాదు. ఆ తర్వాత ఏ ట్రాక్‌లో ఉండాలో మీరు నిర్ణయించుకోవాలనుకుంటే, సర్వర్‌లో LTS మరియు interim releases మధ్య వ్యత్యాసం గురించి చదవడం మంచిది.

development release ఫ్లాగ్ నిజానికి ఏమి చేస్తుంది

-d, లేదా --devel-release, అప్‌గ్రేడర్ Prompt ఎంచుకున్న ఫైల్‌కు బదులుగా meta-release-developmentని చదివేలా చేస్తుంది. మ్యాన్యువల్ పేజీ దీనిని ఇలా వివరిస్తుంది: "తాజా మద్దతు ఉన్న రిలీజ్‌ను ఉపయోగిస్తుంటే, డెవలప్‌మెంట్ రిలీజ్‌కు అప్‌గ్రేడ్ చేయండి."

13 ఆగస్టు 2026న తనిఖీ చేసినప్పుడు, ఆ ఫైల్‌లోని తాజా ఎంట్రీ 26.04 కాదు:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

కాబట్టి -d అనేది 24.04 సర్వర్‌కు విడుదలైన 26.04ని అందించదు. ఇది ఇంకా తయారీ దశలో ఉన్న 26.10 రిలీజ్‌ను లక్ష్యంగా చేసుకుంటుంది. "కేవలం -dని జోడించండి" అనే పాత సలహా LTS విడుదల కావడానికి ముందు ఉన్న సమయం కోసం రాసినది. ఇప్పుడు దానిని మళ్ళీ చెప్పడం వల్ల మీ సర్వర్ మీరు ఉద్దేశించని చోటికి వెళ్తుంది. Prompt=lts ఇంకా అమల్లో ఉన్నప్పుడు, ఈ ఫ్లాగ్ తన సొంత సందేశంతో ఆగిపోతుంది:

There is no development version of an LTS available.

Ubuntu సర్వర్ డాక్యుమెంటేషన్ ఈ ఫ్లాగ్ గురించి స్పష్టంగా చెబుతోంది: "డెవలప్‌మెంట్ రిలీజ్‌ను (లేదా -d ఫ్లాగ్‌ను) ప్రొడక్షన్ ఎన్విరాన్‌మెంట్‌ల కోసం ఉపయోగించడం సిఫార్సు చేయబడదు". డెవలప్‌మెంట్ రిలీజ్ ప్రతిరోజూ మారుతూ ఉంటుంది మరియు దీనికి ఎటువంటి భద్రతా మద్దతు హామీ ఉండదు. కాబట్టి ఉదయం పనిచేసే ప్యాకేజీ మధ్యాహ్నానికి ఒక సేవను నిలిపివేయవచ్చు. దీనిని మీరు మీ కాన్ఫిగరేషన్‌ను పరీక్షించడానికి నిర్మించుకున్న స్క్రాచ్ వర్చువల్ మెషీన్‌పై మాత్రమే ఉపయోగించండి. ఎవరైనా ఆధారపడే సర్వర్‌పై దీనిని ఉపయోగించవద్దు. LTS గేట్ తెరవకముందే మీరు విడుదలైన 26.04ని పొందాలనుకుంటే, Prompt=normal సరైన మార్గం.

SSH సెషన్ కట్ అయినా అప్‌గ్రేడ్ ఆగకుండా ఉండేలా చేయడం

release upgrade సమయంలో openssh-server మరియు systemd సహా system లోని ఎక్కువ భాగం భర్తీ అవుతుంది. dpkg పనిచేస్తున్న సమయంలో మీ SSH (secure shell) session నిలిచిపోతే, packages unpacked మరియు unconfigured స్థితిలోనే process ఆగిపోతుంది. ఇదే స్థితి మీ తదుపరి ప్రయత్నం కూడా ఆగిపోయేలా చేస్తుంది. ఇది ఇప్పటికే జరిగి ఉంటే, మధ్యలో ఆగిపోయిన upgrade ను పునరుద్ధరించడం ప్రత్యేక పని. రెండో ప్రయత్నానికి ముందు దానినే పూర్తి చేయాలి. ప్రతిసారీ terminal multiplexer లో upgrade ప్రారంభించండి.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

ఒకవేళ కనెక్షన్ కట్ అయితే, మళ్ళీ లాగిన్ అయ్యి tmux attach -t upgrade రన్ చేయండి. అప్‌గ్రేడ్ ఆగిపోదు, ఎందుకంటే అది మీ SSH సెషన్‌కు బదులుగా tmux సర్వర్‌కు అనుబంధంగా నడుస్తుంది. మీరు screen వాడాలనుకుంటే screen -S upgrade మరియు screen -r upgrade కూడా అదే పనిని చేస్తాయి.

మల్టీప్లెక్సర్ వాడని వారి కోసం అప్‌గ్రేడర్ తన సొంత రక్షణ వ్యవస్థను కలిగి ఉంటుంది. ఇది SSH ద్వారా నడుస్తున్నట్లు గుర్తిస్తే, పోర్ట్ 1022 పై రెండవ sshd ను ప్రారంభించమని అడుగుతుంది. దీనివల్ల ప్రధాన సెషన్ కట్ అయినా, సర్వర్‌లోకి ప్రవేశించడానికి మరొక మార్గం ఉంటుంది. ఇది తన పేరెంట్ ప్రాసెస్‌లను పరిశీలించి, sshd అనే పేరుతో ఉన్న ప్రాసెస్ కోసం వెతుకుతుంది. tmux లేదా screen లోపల ఉంటే, ఆ సెర్చ్ మల్టీప్లెక్సర్ సర్వర్‌ను కనుగొంటుంది, కాబట్టి ఆ ఆఫర్ కనిపించదు. అదనపు డెమోన్ నిజంగా ప్రారంభమైనప్పుడు మాత్రమే pid ఫైల్ /var/run/release-upgrader-sshd.pid రాయబడుతుంది. ఆ ప్రాంప్ట్ కనిపించకపోతే ఏమీ తప్పు జరగనట్లు అర్థం. మీకు ఇప్పటికే మెరుగైన రక్షణ ఉంది.

ఒకవేళ మీరు ఆ ఆఫర్‌ను అంగీకరిస్తే, పోర్ట్ మీ కోసం ఆటోమేటిక్‌గా ఓపెన్ అవ్వదు. పోర్ట్ ఓపెన్ చేయడం అనేది భద్రతకు సంబంధించిన నిర్ణయం కాబట్టి, మీ తరపున అది ఆ పని చేయదు. అప్‌గ్రేడ్ జరిగేంత వరకు ఆ పోర్ట్‌ను ఓపెన్ చేసి, ఆ తర్వాత మళ్ళీ క్లోజ్ చేయండి.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

చాలా VPS ప్రొవైడర్లు ఆపరేటింగ్ సిస్టమ్ వెలుపల, వారి కంట్రోల్ ప్యానెల్‌లో రెండవ ఫైర్‌వాల్‌ను నిర్వహిస్తారు. అక్కడ కూడా పోర్ట్ 1022 ఓపెన్ చేసి ఉండాలి, లేకపోతే ఫాల్‌బ్యాక్ లిజనర్ రన్ అవుతున్నా అది అందుబాటులోకి రాదు; ఇది రెండింటిలోనూ చెత్త పరిస్థితి.

కమాండ్ టైప్ చేసే ముందు ఈ నాలుగు విషయాలను నిర్ధారించుకోండి:

• స్నాప్‌షాట్ లేదా పూర్తి బ్యాకప్ తీసుకోండి. ఇన్-ప్లేస్ రిలీజ్ అప్‌గ్రేడ్‌ను వెనక్కి తీసుకోవడం (undo) సాధ్యం కాదు, కాబట్టి ఇదే మీకు ఉన్న ఏకైక అవకాశం.
• అవసరానికి ముందే మీ ప్రొవైడర్ కన్సోల్‌ను ఓపెన్ చేయగలరో లేదో సరిచూసుకోండి. రీబూట్ తర్వాత సర్వర్ తిరిగి రాకపోతే, SSH ద్వారా కనెక్ట్ అవ్వడం సాధ్యం కాదు. బూట్ అవ్వని కెర్నల్ అనేది వేరే సమస్య, దీనికి సంబంధించిన రికవరీ దశలు కెర్నల్ అప్‌డేట్ తర్వాత బూట్ అవ్వని VPS లో వివరించబడ్డాయి.
• df -h / /boot తో ఖాళీ స్థలాన్ని తనిఖీ చేయండి. అప్‌గ్రేడ్ కోసం ప్యాకేజీల పూర్తి సెట్‌ను డౌన్‌లోడ్ చేయాల్సి ఉంటుంది, పాత కెర్నల్స్‌తో నిండిన /boot పార్టిషన్ వల్ల అప్‌గ్రేడ్ ఆగిపోయే అవకాశం ఉంది.
• మీరు రన్ చేసే సేవల కోసం రిలీజ్ నోట్స్‌ను చదవండి. మీరు ప్లాన్ చేసినా చేయకపోయినా, PostgreSQL లేదా PHP లోని మేజర్ వెర్షన్ మార్పులు ఈ రిలీజ్‌తో పాటు వస్తాయి.

FAQ

Why does do-release-upgrade say no new release found on Ubuntu 24.04?

The default Prompt=lts in /etc/update-manager/release-upgrades makes the tool read https://changelogs.ubuntu.com/meta-release-lts, and Ubuntu 26.04 carries Supported: 0 in that file until its first point release. The upgrader finds no newer LTS release marked available, so it stops. Check the file yourself with curl -s https://changelogs.ubuntu.com/meta-release-lts and read the last block. Checked on 13 August 2026 the flag was still 0, with Ubuntu 26.04.1 scheduled for 27 August 2026.

Is it safe to set Prompt=normal instead of waiting for the point release?

It upgrades you to the released 26.04, not to a development build, because Prompt=normal reads meta-release, where 26.04 already carries Supported: 1. The timing is the risk. You are going before the blockers found by early upgraders have been fixed. Do it on a server you can restore from a snapshot, and where you can reach the provider console if the reboot goes wrong. Set the value back to lts afterwards.

Does the -d flag upgrade me to 26.04?

No. -d reads meta-release-development, whose newest entry on 13 August 2026 was Ubuntu 26.10, a release still in development. On an LTS machine with Prompt=lts the flag prints There is no development version of an LTS available. and stops. Ubuntu's own server documentation says the development release is not recommended for production, so use Prompt=normal when you want a released 26.04 early.

apt update returns 404 errors on an old release. How do I upgrade it?

That release has reached end of life, so its packages were moved from archive.ubuntu.com to old-releases.ubuntu.com. Change only the host names in /etc/apt/sources.list.d/ubuntu.sources, or in /etc/apt/sources.list on older layouts, and keep your codename as it is. Then run sudo apt update and sudo apt full-upgrade. Once the system is current again, do-release-upgrade can move it forward one release at a time.

Do I need to remove my PPAs before running do-release-upgrade?

You do not have to, because the upgrader comments out any source that does not publish for the new release and prints a line such as was disabled (no Release file) for each one. Doing it yourself first is better, since you choose the order and you see the result. Run apt policy on the packages you care about to find which ones came from each PPA, then reinstall those from the archive if the PPA version is newer than the new release carries.