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) மேம்படுத்தல்களுக்கான point release கட்டுப்பாடு, மூன்றாம் தரப்பு repositories, நிறுத்திவைக்கப்பட்ட (held) அல்லது பாதியிலேயே உள்ளமைக்கப்பட்ட packages, மற்றும் ஆதரவு காலம் முடிந்துவிட்ட ஒரு release.

இந்த வரிசையிலேயே ஒவ்வொன்றாகச் சரிபார்க்கவும். உங்கள் server-ல் எந்தக் காரணம் பொருந்தும் என்பதை உறுதிப்படுத்த ஒவ்வொரு பிரச்சினைக்கும் ஒரு கட்டளை உள்ளது; எனவே எதனால் பிரச்சினை ஏற்படுகிறது என்பதை நீங்கள் ஊகிக்க வேண்டியதில்லை.

check-only flag உண்மையில் எதைக் குறிப்பிடுகிறது

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.

Scripts-க்கு, exit code அதே பதிலை வழங்குகிறது. ஒரு release கிடைக்கும்போது இது 0 என்றும், எதுவும் கிடைக்காதபோது 1 என்றும் இருக்கும். இது வழக்கமான shell மரபுகளுக்கு நேர்மாறானது என்பதால், இதைச் சுற்றி ஒரு check-ஐ உருவாக்கும் முன் கவனமாகப் படிக்கவும்.

உங்கள் login banner இன்னும் பழைய பதிலையே காட்டினால், அது cache செய்யப்பட்டிருக்கலாம். அந்த வரி /etc/update-motd.d/91-release-upgrade-லிருந்து வருகிறது; இது network-ஐக் கேட்பதற்குப் பதிலாகச் சேமிக்கப்பட்ட முடிவை அச்சிடுகிறது. அதை sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd மூலம் புதுப்பிக்கவும், அல்லது -c-ஐ மட்டும் நம்பவும். கடைசியாக இயங்கிய check-ன் முடிவை மட்டுமே அந்த banner மீண்டும் காட்டுகிறது.

இந்த check changelogs.ubuntu.com-ஐ அடைய வேண்டியதும் அவசியம். கடுமையான outbound firewall அல்லது proxy-க்கு பின்னால் உள்ள server-ல், இந்த tool-ஆல் கேட்க முடியாது, எனவே எதையும் கண்டறிய முடியாது.

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

ஒரு HTTP/2 200 வரி என்பது server-ஆல் metadata-வைப் பார்க்க முடிகிறது என்று பொருள். curl: (28) Connection timed out என்பது உங்கள் egress விதிகள் தான் உண்மையான காரணம் என்று பொருள்; APT (advanced package tool) கோப்புகளை எவ்வளவு திருத்தினாலும் பதில் மாறாது.

இந்த command முற்றிலும் விடுபட்டிருந்தால், அது ubuntu-release-upgrader-core-ல் இருக்கும். Minimal cloud images சில நேரங்களில் அந்த package-ஐத் தவிர்த்துவிடும்.

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.

Hosting வழங்குநர்களும் configuration management கருவிகளும் never-ஐ வேண்டுமென்றே அமைக்கின்றன, இது பல server-கள் வெவ்வேறு release-களுக்கு இடையே மாறுவதைத் தடுக்கிறது. நீங்கள் அதை அங்கு கண்டால், யாரோ ஒருவரால் அது தேர்ந்தெடுக்கப்பட்டுள்ளது. நீண்ட கால ஆதரவு (LTS) பாதையில் இருக்க விரும்பும் server-க்கு அதை lts என மாற்றவும்; உங்கள் automation பழைய மதிப்பை எதிர்பார்க்கிறது என்றால், மாற்றத்திற்குப் பிறகு மீண்டும் பழைய நிலைக்குக் கொண்டு வரவும்.

அந்தக் கருத்துகளில் உள்ள ஒரு விவரம் பலரை குழப்பமடையச் செய்கிறது. Prompt=lts அமைக்கப்பட்டிருக்கும்போது, இயங்கும் release ஒரு LTS release ஆக இல்லையென்றால், upgrader அந்த அமைப்பை normal ஆகக் கருதும். ஒரு 25.10 machine-ல் இந்த இரண்டு மதிப்புகளும் ஒரே மாதிரியாகவே செயல்படும். ஆனால் 24.04 machine-ல் அவை அவ்வாறு செயல்படாது; அந்த வேறுபாடே அடுத்த பகுதியின் முழுமையான பொருளாகும்.

LTS முதல் LTS வரையிலான மேம்படுத்தல் ஏன் முதல் point release-க்காகக் காத்திருக்கிறது

Prompt, மேம்படுத்தும் கருவி (upgrader) எந்த metadata கோப்பை வாசிக்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. இதற்கான முகவரிகள் /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-ஐ வாசிக்கிறது. இரண்டு கோப்புகளும் ஒவ்வொரு வெளியீட்டையும் ஒரு சிறிய தொகுப்பு விசைகள் (keys) மூலம் விவரிக்கின்றன. ஒரு வெளியீட்டின் Supported: flag, 1 என்று இருந்தால் மட்டுமே மேம்படுத்தும் கருவி அதை வழங்குகிறது. அதே server-லிருந்து அவற்றை நீங்களே வாசித்துப் பாருங்கள்:

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 August 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 தான் நுழைவாயில். இயல்பான Prompt=lts-ஐப் பயன்படுத்தும் ஒரு 24.04 server அந்த கோப்பை வாசிக்கும்போது, புதிய LTS வெளியீடு எதுவும் கிடைக்கவில்லை என்று கண்டறிந்து, No new release found. என்று காட்டும். உங்கள் கணினியில் எந்தப் பிழையும் இல்லை. Canonical இன்னும் அந்தப் பாதையைத் திறக்கவில்லை.

முதல் point release வெளியாகும் போது அந்த flag 1 என்று மாறும். Ubuntu 26.04.1, 27 August 2026 அன்று வெளியிடத் திட்டமிடப்பட்டுள்ளது. வெளியீட்டுத் தேதிகள் மாறக்கூடும் என்பதால், நாட்காட்டியை நம்பாமல் metadata-வைச் சரிபார்க்கவும். இந்தத் தாமதம் திட்டமிட்டே செய்யப்படுகிறது: முன்கூட்டியே மேம்படுத்தும் பயனர்கள் சிக்கல்களைக் கண்டறிவார்கள், அந்தச் சிக்கல்கள் சரிசெய்யப்பட்ட பின்னரே அதிக எண்ணிக்கையிலான LTS server-கள் மேம்படுத்தப்படும்.

இப்போது இரண்டு நேர்மையான வழிகள் உள்ளன. நீங்கள் தொடர்ந்து கண்காணிக்க விரும்பாத எந்தவொரு server-க்கும், point release வரும் வரை காத்திருப்பதே சரியான முடிவாகும். அல்லது Prompt=normal-ஐ அமைக்கலாம்; இது அதே கருவியை meta-release-க்குச் சுட்டிக்காட்டும், அங்கு 26.04 ஏற்கனவே ஆதரிக்கப்படுவதாகக் குறிக்கப்பட்டுள்ளது. இரண்டாவது வழி உங்களை ஏற்கனவே வெளியிடப்பட்ட 26.04-க்கு மேம்படுத்தும், development build-க்கு அல்ல. எனவே, snapshot மூலம் மீட்டெடுக்கக்கூடிய கணினிகளில் இதைச் செய்யலாம். பணி முடிந்ததும் அந்த மதிப்பை மீண்டும் lts-க்கு மாற்றவும். இதற்கான முழுமையான வழிமுறைகள் 24.04 முதல் 26.04 வரையிலான முழுமையான server மேம்படுத்தல் வழிகாட்டி-ல் உள்ளன.

மேம்படுத்தலைத் தடுக்கும் மூன்றாம் தரப்பு களஞ்சியங்கள் (repositories) மற்றும் PPA-க்கள்

மேம்படுத்தும் கருவி (upgrader), புதிய வெளியீட்டிற்குச் சுட்டிக்காட்டும் வகையில் உங்கள் APT மூலங்களை (sources) மாற்றியமைக்கிறது. புதிய வெளியீட்டிற்கான பதிப்புகளைக் கொண்ட களஞ்சியங்களுக்கு மட்டுமே இதைச் செய்ய முடியும் என்பதால், மற்றவை அனைத்தும் comment செய்யப்படுகின்றன. இதற்கான காரணங்கள் ஒவ்வொரு வரியிலும் தனித்தனியாகக் காட்டப்படும்; அவை was disabled (unknown mirror), was disabled (unknown dist), மற்றும் was disabled (no Release file) ஆகியவையாகும்.

noble-க்காக உருவாக்கப்பட்ட ஒரு PPA (personal package archive), சர்வரில் resolute-க்கான கோப்பகத்தைக் கொண்டிருக்காது. எனவே, மேம்படுத்தும் கருவியால் புதிய தொடருக்கான Release கோப்பை எடுக்க முடியாது, அதனால் அந்த உள்ளீடு முடக்கப்படும். இது பொதுவாக நீங்கள் ஏற்றுக்கொள்ளக்கூடிய ஒரு எச்சரிக்கையாகும். புதிய வெளியீட்டில் உள்ள ஒரு தொகுப்பை (package) மூன்றாம் தரப்பு களஞ்சியமும் வழங்கும்போது, இது ஒரு தடையாக மாறுகிறது. ஏனெனில், மேம்படுத்தல் கணக்கீட்டின்போது இரண்டு விருப்பங்கள் இருப்பதால், இரண்டையும் திருப்திப்படுத்த வழியில்லை.

நீண்ட நேரம் கவனிக்கப்படாத மேம்படுத்தல் செயல்பாட்டின் போது கருவி முடிவெடுப்பதற்குப் பதிலாக, தொடங்குவதற்கு முன்பே நீங்களே முடிவெடுங்கள்.

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

apt policy கட்டளையை ஒரு தொகுப்பின் பெயருடன் பயன்படுத்தினால், நிறுவப்பட்ட ஒவ்வொரு பதிப்பும் எந்தக் களஞ்சியத்திலிருந்து வந்தது என்பதைக் காட்டும். இதன் மூலம், நீங்கள் முடக்கப்போகும் மூலத்தைச் சார்ந்திருக்கும் தொகுப்புகள் எவை என்பதைத் துல்லியமாக அறியலாம். மூலத்தை நீக்குவது எதையும் downgrade செய்யாது; எனவே PPA-விலிருந்து நிறுவப்பட்ட ஒரு தொகுப்பு அதன் PPA பதிப்பிலேயே இருக்கும், அது புதிய வெளியீட்டில் உள்ளதை விடப் புதியதாக இருக்கலாம். இது முக்கியமானதாக இருந்தால், அந்தத் தொகுப்பையும் நீக்கிவிட்டு, மேம்படுத்தலுக்குப் பிறகு களஞ்சியத்திலிருந்து மீண்டும் நிறுவவும். Tailscale போன்ற நீங்கள் மீண்டும் சேர்க்க விரும்பும் ஒரு களஞ்சியத்திற்கு, தொகுப்பை மீண்டும் நிறுவும் முன் அதன் codename-ஐ புதிய வெளியீட்டிற்கு ஏற்பப் புதுப்பிக்க வேண்டும். Ubuntu-வில் ஏற்படும் பெரும்பாலான Tailscale நிறுவல் பிழைகள் இதனால்தான் ஏற்படுகின்றன.

இதற்கு நேர்மாறான விருப்பத்திற்காக ஒரு flag உள்ளது. --allow-third-party என்பதைப் பற்றி கையேடு பக்கம் இவ்வாறு விவரிக்கிறது: "மூன்றாம் தரப்பு கண்ணாடிகள் (mirrors) மற்றும் களஞ்சியங்களை comment செய்யாமல், அவற்றை இயக்கியபடியே மேம்படுத்தலை முயற்சிக்கவும்." இலக்கு வெளியீட்டிற்காக அந்த களஞ்சியம் ஏற்கனவே பதிப்புகளை வெளியிட்டுள்ளது என்பதை உறுதிப்படுத்திய பிறகு மட்டுமே இதைப் பயன்படுத்தவும். அவ்வாறு இல்லையெனில், அந்த களஞ்சியம் இதுவரை உருவாக்காத ஒரு தொடருக்காக, சார்பு வரைபடத்தை (dependency graph) தீர்க்குமாறு நீங்கள் APT-யிடம் கேட்டுள்ளீர்கள் என்று அர்த்தம்.

Ubuntu 24.04 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், பெரும்பாலான மூலங்கள் /etc/apt/sources.list.d/ubuntu.sources-ல் deb822 வடிவமைப்பில் உள்ளன. ஒரே களஞ்சியம் பழைய மற்றும் புதிய வடிவங்கள் இரண்டிலும் எழுதப்பட்டிருப்பது ஒரு தனிப் பிழையாகும். இது deb822 வடிவமைப்பில் உள்ள நகல் மூல உள்ளீட்டுப் பிழை என்பதில் விளக்கப்பட்டுள்ளது.

நிறுத்தி வைக்கப்பட்ட மற்றும் முழுமையாக configure செய்யப்படாத packages கணக்கீட்டைத் தடுக்கின்றன

ஒரு release upgrade, system-ல் உள்ள கிட்டத்தட்ட அனைத்து packages-களையும் மாற்ற வேண்டியிருக்கும். ஒரு package-ஐ மாற்ற முடியாவிட்டால், கணக்கீடு தோல்வியடையும்; பாதியிலேயே விட்டுச் செல்வதை விட, upgrader முன்கூட்டியே நிறுத்திவிடுவது சிறந்தது. இதற்கான காரணத்தைக் கண்டறிய இரண்டு commands உள்ளன.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold, நிறுத்தி வைக்கப்பட்ட (held) packages-களை ஒவ்வொன்றாக வரிக்கு ஒன்றாகக் காட்டும்; system சரியாக இருந்தால் எதையும் காட்டாது. ஒரு package-ஐ மாற்றக்கூடாது என்று கைமுறையாக இடப்படும் கட்டளையே 'hold' ஆகும். யாரோ ஒரு kernel அல்லது database version-ஐ pin செய்துவிட்டு, அதை மறந்திருக்கலாம். உங்களுக்குத் தேவையில்லாதவற்றை sudo apt-mark unhold மற்றும் package பெயரைப் பயன்படுத்தி விடுவிக்கலாம்.

dpkg --audit, unpacked செய்யப்பட்டு ஆனால் configure செய்யப்படாத packages-களைப் பட்டியலிடும். பாதியில் நின்ற installation-ஆல் இந்த நிலை ஏற்படும்; பெரும்பாலும் session துண்டிக்கப்படுவதால் இது நிகழும். Upgrader இதைச் சரிசெய்ய முயற்சிக்கும்போது dpkg interrupted, calling dpkg --configure -a என்று காட்டும், ஆனால் நீங்களே சரிசெய்தால், error message-ஐத் தெளிவாகப் படிக்க முடியும். கருவியால் சரிசெய்ய முடியாத package Package in inconsistent state என்ற செய்தியைக் கொடுக்கும்; மீண்டும் முயற்சிக்கும் முன் அதை நீங்கள் கவனிக்க வேண்டும்.

Upgrade செய்வதற்கு முன், தற்போது இயங்கும் 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 சில updates-களை ஒரு குறிப்பிட்ட சதவீத machines-க்கு மட்டுமே வெளியிடுகிறது, எனவே சாதாரண apt upgrade சில packages-களைத் தவிர்க்கலாம்; இதனால் உங்கள் server நீங்கள் நினைப்பதை விடப் பழைய நிலையில் இருக்கும். அந்த விருப்பம் அனைத்தையும் பெற்றுவிடும். Kernel update செய்யப்பட்டிருந்தால், reboot செய்யவும்; அப்போதுதான் நீங்கள் தற்போது இயக்கும் kernel-லிருந்து upgrade செய்ய முடியும். unattended security upgrades மூலம் ஏற்கனவே patch செய்யப்படும் server-க்கு வேலை குறைவு, இருப்பினும் அந்த முறை ஒரு release எல்லையைத் தாண்டிச் செயல்படாது.

ஒரு release-ன் standard support காலம் முடிந்த பிறகு

ஒரு interim Ubuntu release ஒன்பது மாதங்களுக்கு மட்டுமே ஆதரிக்கப்படும். அந்த ஆதரவு காலம் முடிவடையும் போது, அதன் Supported: flag 0 நிலைக்குச் சென்றுவிடும், மேலும் சாதாரண வழியில் அதிலிருந்து upgrade செய்ய முடியாது. 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

அதே நேரத்தில் archive-ம் நகர்த்தப்படுகிறது. ஒரு release-ன் ஆயுட்காலம் முடிந்ததும், அதன் packages archive.ubuntu.com-லிருந்து நீக்கப்பட்டு old-releases.ubuntu.com-க்கு மாற்றப்படும். இதனால் apt update கட்டளை 404 Not Found பிழையைத் தரும், கணினியைப் புதுப்பிக்க முடியாது, மேலும் upgrader தற்போதைய system-ஐ எதிர்பார்ப்பதால், எந்தச் செயல்பாடும் முன்னெடுத்துச் செல்லப்படாது. முதலில் sources-ஐச் சரிசெய்யவும்.

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-ஐ நோக்கி மாற்றவும், உங்கள் codename-ஐ மாற்ற வேண்டாம். host name மட்டுமே மாற வேண்டும்.

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

உங்கள் server-ன் sources ஒரே கோப்பில் இருந்தால், /etc/apt/sources.list-க்கு எதிராக அதே கட்டளையை இயக்கவும். -i.bak option அசல் கோப்பிற்கு அருகிலேயே ஒரு backup-ஐ உருவாக்கும், எனவே தவறான கோப்பில் மாற்றம் செய்திருந்தால் அதை மீண்டும் பழைய நிலைக்குக் கொண்டு வரலாம். அதன் பிறகு ஒரு சுத்தமான apt update கட்டளை archive மீண்டும் அணுகக்கூடியதாக இருப்பதை உறுதி செய்யும், மேலும் do-release-upgrade இப்போது சரியாகச் செயல்படும்.

இது எந்த அளவிற்கு உதவும் என்பதில் யதார்த்தமாக இருக்கவும். Ubuntu ஒரு நேரத்தில் ஒரு release step-ஐ மட்டுமே ஆதரிக்கிறது, எனவே இரண்டு அல்லது மூன்று dead releases பின்தங்கியிருக்கும் ஒரு server-க்கு, ஒவ்வொரு நிலையையும் வரிசையாகக் கடக்க வேண்டும். ஒவ்வொரு நிலையிலும் third party repository அல்லது held package காரணமாகப் பிழைகள் ஏற்படலாம். ஒரு VPS-ல், தற்போதைய LTS-ல் புதிய server-ஐ உருவாக்கி, service-ஐ அதற்கு மாற்றி, பழையதை உறுதிப்படுத்தும் வரை வைத்திருப்பது பெரும்பாலும் வேகமான முறையாகும். இது உங்களுக்கு ஒரு rollback வசதியையும் தருகிறது, இது in-place upgrade-ல் கிடைக்காது. இதற்குப் பிறகு எந்தத் தடத்தில் (track) இருக்க வேண்டும் என்று நீங்கள் முடிவு செய்யும்போது, server-ல் LTS மற்றும் interim releases-க்கு இடையிலான வேறுபாடு குறித்த கட்டுரையை வாசிப்பது பயனுள்ளதாக இருக்கும்.

development release flag உண்மையில் என்ன செய்கிறது

-d, அல்லது --devel-release, upgrader-ஐ Prompt தேர்ந்தெடுத்த கோப்பிற்குப் பதிலாக meta-release-development-ஐ வாசிக்கச் செய்கிறது. இதன் கையேடு பக்கம் (manual page) இதை இவ்வாறு விவரிக்கிறது: "சமீபத்திய ஆதரவுள்ள release-ஐப் பயன்படுத்தினால், development release-க்கு மேம்படுத்தவும்."

13 August 2026 அன்று சரிபார்க்கப்பட்டதில், அந்தக் கோப்பில் உள்ள புதிய entry 26.04 அல்ல:

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

எனவே, -d ஒரு 24.04 server-க்கு வெளியிடப்பட்ட 26.04-ஐ வழங்காது. இது இன்னும் உருவாக்கத்தில் இருக்கும் 26.10 release-ஐ இலக்காகக் கொண்டுள்ளது. "வெறுமனே -d-ஐச் சேர்க்கவும்" என்ற பழைய அறிவுரை, ஒரு LTS வெளியாவதற்கு முந்தைய காலக்கட்டத்திற்காக எழுதப்பட்டது. அதை இப்போது மீண்டும் பயன்படுத்துவது, உங்கள் server-ஐ நீங்கள் விரும்பாத இடத்திற்கு இட்டுச் செல்லும். Prompt=lts இன்னும் செயல்பாட்டில் இருக்கும்போது, இந்த flag ஒரு செய்தியுடன் நின்றுவிடும்:

There is no development version of an LTS available.

Ubuntu-வின் server ஆவணங்கள் இந்த flag குறித்து நேரடியாகக் கூறுகின்றன: "development release-ஐ (அல்லது -d flag-ஐ) பயன்படுத்துவது production சூழல்களுக்குப் பரிந்துரைக்கப்படுவதில்லை". ஒரு development release தினசரி மாறக்கூடியது மற்றும் அதற்குப் பாதுகாப்பு ஆதரவு (security support) உறுதிமொழி ஏதுமில்லை. எனவே, காலையில் வேலை செய்யும் ஒரு package, மதியத்திற்குள் ஒரு service-ஐ முடக்கக்கூடும். இதை உங்கள் configuration-ஐச் சோதிக்க நீங்கள் உருவாக்கிய ஒரு scratch virtual machine-ல் மட்டும் பயன்படுத்தவும். எவரும் சார்ந்திருக்கும் எந்தவொரு server-லும் இதைப் பயன்படுத்த வேண்டாம். LTS gate திறப்பதற்கு முன்பே நீங்கள் வெளியிடப்பட்ட 26.04-ஐப் பெற விரும்பினால், Prompt=normal என்பதே சரியான வழியாகும்.

SSH session துண்டிக்கப்பட்டாலும் upgrade தடைபடாமல் இருக்க அதை இயக்குதல்

ஒரு release upgrade, openssh-server மற்றும் systemd உள்ளிட்ட கணினியின் பெரும்பாலான பகுதிகளை மாற்றியமைக்கிறது. openssh-server செயல்படும்போது உங்கள் SSH (secure shell) session துண்டிக்கப்பட்டால், அந்தச் செயல்முறை (process) பாதியிலேயே நிறுத்தப்படும்; packages unpacked மற்றும் unconfigured நிலையில் இருக்கும். இதுவே அடுத்தமுறை நீங்கள் upgrade செய்ய முயலும்போது சிக்கலை ஏற்படுத்தும். எனவே, ஒவ்வொரு முறையும் ஒரு terminal multiplexer-க்குள் upgrade-ஐத் தொடங்கவும்.

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

இணைப்பு துண்டிக்கப்பட்டால், மீண்டும் login செய்து tmux attach -t upgrade-ஐ இயக்கவும். Upgrade தொடர்ந்து இயங்கிக்கொண்டிருக்கும், ஏனெனில் அது உங்கள் SSH session-ன் கீழ் இல்லாமல், tmux server-ன் child process-ஆக இயங்குகிறது. நீங்கள் விரும்பினால் screen -S upgrade மற்றும் screen -r upgrade ஆகியவற்றையும் இதற்காகப் பயன்படுத்தலாம்.

Multiplexer பயன்படுத்தாதவர்களுக்காக, upgrader ஒரு பாதுகாப்பு வசதியைக் கொண்டுள்ளது. அது SSH-ன் கீழ் இயங்குவதைக் கண்டறிந்தால், port 1022-ல் இரண்டாவது sshd-ஐத் தொடங்க அனுமதி கேட்கும். இதனால் முதன்மை session துண்டிக்கப்பட்டாலும், server-க்குள் நுழைய ஒரு வழி இருக்கும். இது தனது parent processes-ஐச் சரிபார்த்து, sshd என்ற பெயரில் ஏதேனும் உள்ளதா என்று பார்க்கும். நீங்கள் tmux அல்லது screen-க்குள் இருந்தால், அது multiplexer server-ஐக் கண்டறியும்; எனவே அந்த அனுமதி கோரும் செய்தி வராது. மேலும், அந்த கூடுதல் daemon உண்மையில் தொடங்கப்படும்போது மட்டுமே /var/run/release-upgrader-sshd.pid என்ற pid file உருவாக்கப்படும். அந்த prompt உங்களுக்குத் தெரியவில்லை என்றால் கவலைப்பட வேண்டாம்; நீங்கள் ஏற்கனவே சிறந்த பாதுகாப்பைக் கொண்டுள்ளீர்கள் என்று அர்த்தம்.

நீங்கள் அந்த அனுமதியை வழங்கினால், port தானாகவே திறக்கப்படாது. அந்த tool இதைத் தெளிவாகக் கூறும், ஏனெனில் port-ஐத் திறப்பது என்பது ஒரு பாதுகாப்பு சார்ந்த முடிவு; அதை உங்கள் சார்பாக அந்த tool எடுக்காது. Upgrade முடியும் வரை மட்டும் port-ஐத் திறந்து வைத்துவிட்டு, பிறகு அதை மூடிவிடவும்.

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

பெரும்பாலான VPS நிறுவனங்கள், operating system-க்கு வெளியே தங்கள் control panel-ல் இரண்டாவது firewall-ஐ வைத்திருக்கும். Port 1022-ஐ அங்கேயும் திறக்க வேண்டும்; இல்லையெனில் fallback listener இயங்கிக்கொண்டிருக்கும், ஆனால் அதை அணுக முடியாது. இது மிகவும் ஆபத்தான நிலை.

கட்டளையைத் தட்டச்சு செய்வதற்கு முன் பின்வரும் நான்கு விஷயங்களை உறுதிப்படுத்தவும்:

• Snapshot அல்லது முழுமையான backup எடுக்கவும். In-place release upgrade-ஐத் திரும்பப் பெற முடியாது; இதுவே உங்களுக்கான ஒரே வாய்ப்பு.
• தேவைப்படும்போது உங்கள் provider-ன் console-ஐ அணுக முடியும் என்பதை உறுதிப்படுத்தவும். Reboot-க்குப் பிறகு server மீண்டும் வரவில்லை என்றால், SSH மூலம் உங்களால் நுழைய முடியாது. Kernel boot ஆகவில்லை என்றால் அது வேறு பிரச்சினை, அதற்கான மீட்பு வழிமுறைகள் a VPS that will not boot after a kernel update பகுதியில் கொடுக்கப்பட்டுள்ளன.
• df -h / /boot மூலம் போதிய அளவு free space உள்ளதா என்று சரிபார்க்கவும். Upgrade-ன் போது முழுமையான packages தரவிறக்கம் செய்யப்படும். பல பழைய kernels இருக்கும் /boot partition-ல் இடம் பற்றாக்குறை ஏற்படுவது பொதுவானது.
• நீங்கள் இயக்கும் services-க்கான release notes-ஐப் படிக்கவும். PostgreSQL அல்லது PHP-ன் major version மாற்றம், நீங்கள் திட்டமிட்டிருந்தாலும் இல்லாவிட்டாலும், இந்த release-உடன் சேர்ந்து வந்துவிடும்.

FAQ

Ubuntu 24.04-ல் do-release-upgrade ஏன் புதிய release எதையும் கண்டறியவில்லை?

Prompt=lts-ல் உள்ள இயல்புநிலை /etc/update-manager/release-upgrades அமைப்பானது, https://changelogs.ubuntu.com/meta-release-lts-ஐ வாசிக்குமாறு கருவியை இயக்குகிறது. Ubuntu 26.04-ன் முதல் point release வெளியாகும் வரை, அந்த கோப்பில் Supported: 0 என்றே இருக்கும். மேம்படுத்தும் கருவி (upgrader) புதிய LTS release எதையும் கிடைக்கக்கூடியதாகக் கண்டறியாததால், அது நின்றுவிடுகிறது. curl -s https://changelogs.ubuntu.com/meta-release-lts கட்டளையைப் பயன்படுத்தி நீங்களே அந்த கோப்பைச் சரிபார்த்து, கடைசி பகுதியை வாசிக்கவும். 13 August 2026 அன்று சரிபார்க்கப்பட்டபோது, அந்த flag 0 என்றே இருந்தது; Ubuntu 26.04.1 பதிப்பு 27 August 2026 அன்று வெளியிட திட்டமிடப்பட்டுள்ளது.

Point release-க்காகக் காத்திருக்காமல் Prompt=normal என்று அமைப்பது பாதுகாப்பானதா?

இது உங்களை ஏற்கனவே வெளியிடப்பட்ட 26.04 பதிப்பிற்குத்தான் மேம்படுத்தும், development build-க்கு அல்ல. ஏனெனில் Prompt=normal ஆனது meta-release-ஐ வாசிக்கிறது, அதில் 26.04 ஏற்கனவே Supported: 1 என்று குறிப்பிடப்பட்டுள்ளது. இதில் உள்ள ஆபத்து நேரத்தைப் பொறுத்தது. ஆரம்பகால மேம்படுத்தல்களில் கண்டறியப்பட்ட சிக்கல்கள் சரிசெய்யப்படுவதற்கு முன்பே நீங்கள் மேம்படுத்துகிறீர்கள். எனவே, snapshot மூலம் மீட்டெடுக்கக்கூடிய வசதி கொண்ட server-ல் இதைச் செய்யவும்; reboot தோல்வியுற்றால் provider console-ஐ அணுகும் வசதி இருப்பதை உறுதி செய்யவும். மேம்படுத்திய பிறகு அந்த மதிப்பை மீண்டும் lts என மாற்றவும்.

-d flag என்னைப் 26.04 பதிப்பிற்கு மேம்படுத்துமா?

இல்லை. -d ஆனது meta-release-development-ஐ வாசிக்கிறது. 13 August 2026 அன்று அதில் இருந்த புதிய பதிவு Ubuntu 26.10 ஆகும், இது இன்னும் development நிலையிலேயே உள்ளது. Prompt=lts அமைப்பைக் கொண்ட LTS கணினியில், இந்த flag There is no development version of an LTS available. என்று காட்டி நின்றுவிடும். Ubuntu-வின் அதிகாரப்பூர்வ server ஆவணங்களின்படி, development release-ஐ production சூழலில் பயன்படுத்த பரிந்துரைக்கப்படுவதில்லை. எனவே, 26.04 பதிப்பை முன்கூட்டியே பெற விரும்பினால் Prompt=normal-ஐப் பயன்படுத்தவும்.

பழைய release-ல் apt update செய்யும்போது 404 பிழைகள் வருகின்றன. அதை எப்படி மேம்படுத்துவது?

அந்த release-ன் ஆயுட்காலம் முடிந்துவிட்டதால், அதன் தொகுப்புகள் (packages) archive.ubuntu.com-லிருந்து old-releases.ubuntu.com-க்கு மாற்றப்பட்டுவிட்டன. /etc/apt/sources.list.d/ubuntu.sources-ல் உள்ள host பெயர்களை மட்டும் மாற்றவும் (பழைய அமைப்புகளில் /etc/apt/sources.list-ல் மாற்றவும்), உங்கள் codename-ஐ அப்படியே வைத்திருக்கவும். பிறகு sudo apt update மற்றும் sudo apt full-upgrade கட்டளைகளை இயக்கவும். கணினி தற்போதைய நிலைக்கு வந்தவுடன், do-release-upgrade மூலம் ஒவ்வொரு release-ஆக மேம்படுத்தலாம்.

do-release-upgrade இயக்கும் முன் PPAs-ஐ நீக்க வேண்டுமா?

அவசியமில்லை. புதிய release-க்குத் தேவையான தொகுப்புகளை வெளியிடாத எந்தவொரு source-ஐயும் மேம்படுத்தும் கருவி தானாகவே comment செய்துவிடும், மேலும் ஒவ்வொரு வரிக்கும் was disabled (no Release file) போன்ற செய்தியைக் காட்டும். நீங்களே முன்கூட்டியே அவற்றை நீக்குவது சிறந்தது, ஏனெனில் நீங்களே வரிசையைத் தீர்மானிக்கலாம் மற்றும் முடிவுகளைக் கண்காணிக்கலாம். உங்களுக்குத் தேவையான தொகுப்புகள் எந்த PPA-விலிருந்து வந்தன என்பதைக் கண்டறிய, அந்த தொகுப்புகளுக்கு apt policy கட்டளையை இயக்கவும். புதிய release-ல் உள்ளதை விட PPA பதிப்பு புதியதாக இருந்தால், அவற்றை archive-லிருந்து மீண்டும் நிறுவவும்.