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

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

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.

Prompt=lts கொண்ட ஒரு LTS release-ல், முதல் பதில் வேறுவிதமாக இருக்கும். நீங்கள் -d-ஐப் பயன்படுத்தாவிட்டாலும், Prompt=lts அமைக்கப்பட்டிருந்து, எதுவும் கண்டறியப்படவில்லை என்றால், upgrader-ன் source There is no development version of an LTS available.-ஐ அச்சிடும். இது No new release found. என்பதையே குறிக்கிறது.

scripts-க்கு, exit code அதே பதிலை வழங்குகிறது. ஒரு release கிடைக்கும்போது அது 0 என்றும், எதுவும் கிடைக்காதபோது 1 என்றும் இருக்கும். இது வெற்றிக்கான பூஜ்ஜியம் (zero) என்ற வழக்கமான shell மரபைப் பின்பற்றுவதால், ஒரு script பூஜ்ஜியத்தை "புதிய release கிடைக்கிறது" என்று எடுத்துக்கொள்ளலாம்.

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

இந்தச் சரிபார்ப்பிற்கு 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-வைப் பார்க்க முடிகிறது என்று பொருள். எந்த வெளியீடும் இல்லை என்றால், கோரிக்கை தோல்வியடைந்தது என்று பொருள், ஏனெனில் -s என்பது curl-ன் பிழைச் செய்தியை மறைத்துவிடும், எனவே உடனடியாக echo $?-ஐ இயக்கவும். Exit code 6 என்பது பெயர் (name) resolve ஆகவில்லை என்று பொருள். Exit code 7 (இணைக்கத் தவறியது) அல்லது 28 (நேரம் முடிந்தது) பொதுவாக உங்கள் egress விதிகள் அல்லது proxy-யைக் குறிக்கும், இருப்பினும் மெதுவான DNS lookup-ம் curl-ன் connect timeout-க்கு எதிராகக் கணக்கிடப்படும். எதுவாக இருந்தாலும், APT (advanced package tool) கோப்புகளைத் திருத்துவதால் எந்த மாற்றமும் ஏற்படாது.

இந்தக் கட்டளை முற்றிலும் விடுபட்டிருந்தால், அது 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: தற்போது இயங்கும் பதிப்பைத் தொடர்ந்து வரும் ஆதரவுள்ள (supported) பதிப்பை வழங்கவும்.
• lts: தற்போது இயங்கும் பதிப்பைத் தொடர்ந்து வரும் முதல் LTS பதிப்பை வழங்கவும்.

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-கள் பதிப்புகளுக்கு இடையே மாறிக்கொண்டே இருப்பதைத் தடுக்கிறது. நீங்கள் அதை அங்கு கண்டால், யாரோ ஒருவரால் அது தேர்ந்தெடுக்கப்பட்டிருக்கிறது என்று அர்த்தம். நீண்ட கால ஆதரவு (long term support) தேவைப்படும் server-க்கு அதை lts என மாற்றவும்; உங்கள் automation கருவி பழைய மதிப்பையே எதிர்பார்க்கிறது என்றால், வேலையை முடித்த பிறகு மீண்டும் பழையபடியே மாற்றிவிடவும்.

அந்தக் குறிப்புகளில் உள்ள ஒரு விவரம் பலரை குழப்பமடையச் செய்கிறது. Prompt=lts அமைக்கப்பட்டிருக்கும்போது, இயங்கும் பதிப்பு LTS பதிப்பாக இல்லையென்றால், மேம்படுத்தும் கருவி அந்த அமைப்பை 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

21 அக்டோபர் 2026 அன்று சரிபார்க்கப்பட்டபோது, Ubuntu 26.04 குறித்து இந்த இரண்டு கோப்புகளும் ஒரே தகவலைக் கொண்டிருந்தன. LTS கோப்பு இவ்வாறு கூறுகிறது:

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

சாதாரண கோப்பு இவ்வாறு கூறுகிறது:

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

இவை எப்போதும் ஒரே மாதிரியாக இருந்ததில்லை. 13 ஆகஸ்ட் 2026 அன்று, LTS கோப்பு Version: 26.04 LTS-ஐ Supported: 0 உடன் பட்டியலிட்டிருந்தது, ஆனால் சாதாரண கோப்பில் ஏற்கனவே Supported: 1 இருந்தது. LTS கோப்பில் இருந்த அந்த 0 தான் தடையாக (gate) இருந்தது. இயல்புநிலை Prompt=lts-ஐப் பயன்படுத்தும் ஒரு 24.04 server அந்த கோப்பை வாசித்து, புதிய LTS வெளியீடு எதுவும் கிடைக்கவில்லை என்று கண்டறிந்து, மேம்படுத்த ஏதுமில்லை என்று தெரிவித்தது. அந்த machine-ல் எந்தப் பிழையும் இல்லை. Canonical இன்னும் அந்தப் பாதையைத் திறக்கவில்லை.

Canonical LTS மேம்படுத்தல்களைச் செயல்படுத்தும்போது, அந்தக் கொடி 1 என மாறும். இது வெளியீடு வந்த நாளன்று நடக்காது, முதல் point release வந்த பிறகுதான் நடக்கும். 26.04-க்கு இது நடந்துவிட்டது. Ubuntu 26.04.1, 27 ஆகஸ்ட் 2026 அன்று வெளியிடப்பட்டது. 29 செப்டம்பர் 2026 அன்று, 24.04-லிருந்து மேம்படுத்தல்கள் "இப்போது செயல்படுத்தப்பட்டுள்ளன" என்று Canonical அறிவித்தது. LTS கோப்பு இப்போது 26.04.1-ஐ ஆதரிக்கப்படும் வெளியீடாகக் குறிக்கிறது. எனவே, Prompt=lts-ல் உள்ள 24.04 server-க்கு 26.04.1 பரிந்துரைக்கப்படுகிறது, மேலும் அந்தத் தடை இப்போது இல்லை. உங்கள் 24.04 server இன்னும் எதையும் கண்டறியவில்லை என்றால், அதற்கான காரணம் இந்தப் பக்கத்தில் உள்ள வேறு ஏதேனும் ஒன்றாக இருக்கலாம்: cache செய்யப்பட்ட login banner, changelogs.ubuntu.com-க்கான அணுகல் தடுக்கப்பட்டிருப்பது, அல்லது Prompt=never. ஒரு point release என்பது Ubuntu-வின் புதிய பதிப்பு அல்ல; அது வெளியீட்டிற்குப் பிறகு வந்த அனைத்து மேம்படுத்தல்களையும் உள்ளடக்கிய புதிய install media மட்டுமே. எனவே, இயங்கிக்கொண்டிருக்கும் server-க்கு media-வை விட, அதற்குப் பிறகு திறக்கப்படும் அந்தத் தடைதான் முக்கியமானது. இந்தத் தாமதம் திட்டமிட்டே செய்யப்படுகிறது: முன்கூட்டியே மேம்படுத்தும் பயனர்கள் சிக்கல்களைக் கண்டறிவார்கள், LTS server-களைப் பயன்படுத்தும் பெரும் எண்ணிக்கையிலான பயனர்களுக்கு அந்தச் சிக்கல்கள் சரிசெய்யப்பட்டுவிடும். Canonical-ன் 26.04.1 அறிவிப்பின்படி, Update Manager மூலம் தானியங்கி மேம்படுத்தல் "இந்த வெளியீட்டிற்குப் பிறகு சில வாரங்களில், rust-coreutils-ன் சமீபத்திய பதிப்பில் உள்ள சிக்கல்களைச் சரிசெய்யத் திட்டமிடப்பட்ட backports-க்கு பிறகு" வரும் என்று கூறப்பட்டுள்ளது. கூடுதல் விவரங்களுக்கு, 26.04.1 எதனுடன் வெளியிடப்பட்டது மற்றும் அது 24.04 server-க்கு என்ன அர்த்தம் என்பதைப் பார்க்கவும்.

தடை நீக்கப்பட்ட நிலையில், காத்திருப்பதற்கும் Prompt=normal-க்கு மாறுவதற்கும் இடையிலான பழைய தேர்வு இந்த மேம்படுத்தலுக்குப் பொருந்தாது. Prompt=lts-ஐ அப்படியே விட்டுவிட்டு, sudo do-release-upgrade-ஐ இயக்கவும்; இது இப்போது வெளியிடப்பட்ட 26.04.1-ஐ இலக்காகக் கொண்டுள்ளது. தடை இருந்தபோது நீங்கள் normal-க்கு மாறியிருந்தால், server நீண்டகால ஆதரவு (long term support) பாதையிலேயே இருக்க, மதிப்பை மீண்டும் lts என மாற்றவும். மேம்படுத்தும் செயல்முறை குறித்த முழுமையான வழிமுறைகள் 24.04-லிருந்து 26.04-க்கு server-ஐ மேம்படுத்தும் முழுமையான வழிகாட்டி-ல் உள்ளன. இன்னும் 22.04-ல் இருக்கும் server-க்கு ஒரு கூடுதல் படி தேவைப்படுகிறது, ஏனெனில் Prompt=lts எப்போதும் அடுத்த LTS வெளியீட்டை மட்டுமே பரிந்துரைக்கும். எனவே, 22.04-லிருந்து 26.04-க்கான பாதை முதலில் 24.04 வழியாகச் செல்லும்.

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

மேம்படுத்தும் கருவி (upgrader), உங்கள் APT sources-ஐ புதிய release-ஐச் சுட்டிக்காட்டும் வகையில் மாற்றியமைக்கும். இயல்பாக, இது Ubuntu-வின் சொந்த archive மற்றும் mirrors-ஐ மட்டும் வைத்துக்கொண்டு, மூன்றாம் தரப்பு களஞ்சியங்களை comment செய்துவிடும்; புதிய release-க்கு அவை ஏற்கனவே ஆதரவு அளித்தாலும் இதுவே நடக்கும். புதிய series-க்குத் தேவையான Release கோப்பு இல்லாதபோது, ஒரு entry அப்படியே இருந்தாலும் அது முடக்கப்படும். இதற்கான காரணங்கள் திரையில் காட்டப்படாமல், மேம்படுத்தும் கருவியின் log-ல் ஒவ்வொரு வரிக்கும் ஒன்றாகப் பதிவாகும். அவை was disabled (unknown mirror), was disabled (unknown dist), மற்றும் was disabled (no Release file) எனத் துல்லியமாகக் குறிப்பிடப்பட்டிருக்கும்.

noble-க்காக உருவாக்கப்பட்ட ஒரு PPA (personal package archive), சர்வரில் resolute-க்கான directory-ஐக் கொண்டிருக்காது. எனவே, மூன்றாம் தரப்பு sources அனுமதிக்கப்பட்டாலும், மேம்படுத்தும் கருவியால் புதிய series-க்கான Release கோப்பை எடுக்க முடியாது, அதனால் அந்த entry முடக்கப்படும். இது பொதுவாக நீங்கள் ஏற்றுக்கொள்ளக்கூடிய ஒரு எச்சரிக்கை மட்டுமே. ஆனால், அந்த களஞ்சியத்திலிருந்து நீங்கள் நிறுவிய ஒரு package, கணினியின் மற்ற பகுதிகளுடன் இணைந்து மேம்படுத்த முடியாதபோது இது ஒரு தடையாக மாறுகிறது. APT ஒவ்வொரு package-க்கும் ஒரு பதிப்பை மட்டுமே வைத்திருக்கும்; dependency கட்டுப்பாடுகளுக்கு உட்பட்டு முன்னுரிமை அடிப்படையில் அது தேர்ந்தெடுக்கப்படும். இயல்பாக, இது நிறுவப்பட்ட ஒரு package-ஐ downgrade செய்யாது. புதிய release-ல் இருப்பதை விட PPA-வில் உள்ள package பதிப்பு புதியதாக இருந்தால், அது அப்படியே இருக்கும். புதிய release-ல் இல்லாத library பதிப்புகள் அதற்குத் தேவைப்பட்டால், மேம்படுத்தும் கணக்கீடு தோல்வியடையும்.

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

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

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

இதற்கு நேர்மாறான விருப்பத்திற்கு ஒரு flag உள்ளது. --allow-third-party-ஐப் பற்றி manual பக்கம் இவ்வாறு விவரிக்கிறது: "மூன்றாம் தரப்பு mirrors மற்றும் களஞ்சியங்களை comment செய்வதற்குப் பதிலாக, அவற்றை இயக்கியபடியே மேம்படுத்தலை முயற்சிக்கவும்." இலக்கு release-க்கு அந்த களஞ்சியம் ஏற்கனவே ஆதரவு அளிக்கிறது என்பதை உறுதிப்படுத்திய பிறகு மட்டுமே இதைப் பயன்படுத்தவும். இல்லையெனில், புதிய series-க்கான Release கோப்பு இல்லாத entry-கள் எப்படியும் முடக்கப்படுவதால் இந்த flag-ஆல் எந்தப் பயனும் இருக்காது, அல்லது அந்த release-க்காக உருவாக்கப்படாத package-கள் அப்படியே இயங்கிக்கொண்டிருக்கும்.

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

Held மற்றும் half configured தொகுப்புகள் கணக்கீட்டைத் தடுக்கின்றன

ஒரு release upgrade-ன் போது கணினியில் உள்ள ஏறக்குறைய அனைத்து தொகுப்புகளும் மாற்றப்பட வேண்டும். ஏதேனும் ஒரு தொகுப்பை மாற்ற முடியாவிட்டால், கணக்கீடு தோல்வியடையும். பாதியிலேயே நிறுத்தி வைப்பதை விட, முன்கூட்டியே நிறுத்துவதையே upgrader விரும்புகிறது. இதற்கான காரணத்தைக் கண்டறிய இரண்டு கட்டளைகள் உள்ளன.

apt-mark showhold
sudo dpkg --audit

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

dpkg --audit கட்டளையானது, unpacked செய்யப்பட்ட ஆனால் configure செய்யப்படாத தொகுப்புகளைப் பட்டியலிடும். பாதியில் துண்டிக்கப்பட்ட install செயல்முறையினால் இந்த நிலை ஏற்படுகிறது. Upgrader இதைச் சரிசெய்ய முயற்சிக்கும், மேலும் dpkg interrupted, calling dpkg --configure -a என்று log செய்யும். ஆனால், நீங்களே அதைச் சரிசெய்தால், பிழையைத் தேடுவதற்குப் பதிலாக அதை நேரடியாகப் படிக்க முடியும். கருவியால் சரிசெய்ய முடியாத தொகுப்பு 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 சில புதுப்பிப்புகளை ஒரு நேரத்தில் குறிப்பிட்ட சதவீத இயந்திரங்களுக்கு மட்டுமே வழங்குகிறது. எனவே, சாதாரண apt upgrade கட்டளை சில தொகுப்புகளைத் தவிர்க்கலாம்; இதனால் உங்கள் server நீங்கள் நினைப்பதை விடப் பழைய நிலையில் இருக்கலாம். அந்த விருப்பம் அனைத்தையும் பெற்றுவிடும். Kernel புதுப்பிப்பு இருந்தால், அதன் பிறகு reboot செய்யவும்; அப்போதுதான் நீங்கள் தற்போது இயக்கும் kernel-லிருந்து upgrade செய்ய முடியும். unattended security upgrades மூலம் ஏற்கனவே patch செய்யப்படும் கணினிகளுக்கு வேலை குறைவாகவே இருக்கும், இருப்பினும் அந்த வசதி ஒரு release-லிருந்து அடுத்ததற்குத் தானாக மாறாது.

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

ஒரு interim Ubuntu release ஒன்பது மாதங்களுக்கு ஆதரிக்கப்படும். அந்த ஆதரவு முடிவடையும் போது அதன் Supported: flag 0 நிலைக்குச் செல்லும், ஆனால் அது மட்டுமே அந்த release-லிருந்து வெளியேறும் பாதையை அடைப்பதில்லை. Upgrader unsupported release-களை இலக்குகளாக (targets) மட்டுமே தவிர்க்கிறது. Ubuntu 25.10-ன் ஆதரவு காலம் 9 ஜூலை 2026 அன்று முடிவடைந்ததாக Canonical அறிவித்த அறிவிப்பில்: "Ubuntu 25.10-லிருந்து Ubuntu 26.04 LTS-க்கு மேம்படுத்த அங்கீகரிக்கப்பட்ட பாதை உள்ளது" என்று குறிப்பிடப்பட்டுள்ளது. 21 அக்டோபர் 2026 அன்று சரிபார்க்கப்பட்டபோது, meta-release 25.10 பற்றி இவ்வாறு கூறுகிறது:

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

ஒரு பாதையை அடைப்பது archive ஆகும், இது end of life தேதியை விடப் பிந்தைய காலத்தில் நகர்த்தப்படும். அதே அறிவிப்பில் 25.10 "வரும் வாரங்களில்" old-releases.ubuntu.com-க்கு archive செய்யப்படும் என்று கூறப்பட்டிருந்தது. 21 அக்டோபர் 2026 அன்று சரிபார்க்கப்பட்டபோது, questing இன்னும் archive.ubuntu.com-ல் இருந்தது, old-releases.ubuntu.com-க்கு மாறவில்லை. எனவே, ஒரு 25.10 server இன்னும் நேரடியாக 26.04 LTS-க்கு update மற்றும் upgrade செய்ய முடியும். ஒரு release நகர்த்தப்பட்டவுடன், அதன் packages archive.ubuntu.com-லிருந்து நீக்கப்பட்டு old-releases.ubuntu.com-ல் வைக்கப்படும். அதன் பிறகு apt update 404 Not Found-ஐத் தரத் தொடங்கும், கணினியைத் தற்போதைய நிலைக்குக் கொண்டுவர முடியாது. Upgrader ஒரு தற்போதைய கணினியை எதிர்பார்ப்பதால், எந்தச் செயல்பாடும் தொடராது. முதலில் 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-க்கு எதிராக அதே command-ஐ இயக்கவும். -i.bak option அசல் கோப்பிற்கு அருகிலேயே ஒரு backup-ஐ உருவாக்கும், எனவே தவறான கோப்பில் திருத்தம் செய்திருந்தால் அதை மீண்டும் பழைய நிலைக்கு மாற்றலாம். அதன் பிறகு ஒரு சுத்தமான apt update என்பது archive மீண்டும் அணுகக்கூடியதாக உள்ளது என்று பொருள், மேலும் do-release-upgrade இப்போது உங்களுடன் தொடர்பு கொள்ளும்.

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

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

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

21 அக்டோபர் 2026 அன்று சரிபார்க்கப்பட்டபோது, meta-release-development-ல் உள்ள புதிய பதிவு 26.04 அல்ல:

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

இருப்பினும், புதிய பதிவு என்பது upgrader தேர்ந்தெடுப்பது அல்ல. அது கோப்பை வரிசையாகப் படித்து, நீங்கள் தற்போது இயக்கும் release-க்கு அடுத்த தேதியிட்ட முதல் release-ஐ எடுத்துக்கொள்ளும். 24.04 server-ல் இரண்டு development கோப்புகளும் resolute என்று இருப்பதால், 24.04-ல் -d என்பது வெளியிடப்பட்ட 26.04.1-க்குச் செல்லும். Canonical-ன் சொந்த 26.04.1 அறிவிப்பு, "தாவிச் செல்ல ஆர்வமாக" இருக்கும் 24.04 பயனர்களை do-release-upgrade -d-ஐ இயக்கச் சொல்கிறது. இப்போது LTS gate திறக்கப்பட்டுள்ளதால், flag இல்லாமலேயே ஒரு சாதாரண do-release-upgrade அதே release-ஐ அடையும். 26.04 server-ல், அடுத்த புதிய பதிவு 26.10 ஆகும். Ubuntu 26.10-ஐ 15 அக்டோபர் 2026 அன்று வெளியிட்டது, ஆனால் 21 அக்டோபர் 2026 அன்று சரிபார்க்கப்பட்டபோது meta-release இன்னும் resolute-லேயே முடிவடைந்தது. எனவே, Prompt=normal-ல் உள்ள 26.04 server, சாதாரண சரிபார்ப்பின் மூலம் No new release found.-ஐப் பெறும். Canonical-ன் 26.10 அறிவிப்பு, அனைத்து release-கள் குறித்தும் அறிவிப்புகளைப் பெறத் தேர்ந்தெடுத்த 26.04 பயனர்களுக்கு, தேதி குறிப்பிடாமல் "26.10-க்கு தானியங்கி மேம்படுத்தல் வழங்கப்படும்" என்று கூறுகிறது. அந்தப் பதிவு தோன்றும் வரை, 26.04-ல் -d என்பது development கோப்பின் வழியாக மட்டுமே வெளியிடப்பட்ட 26.10-ஐ அடையும்; அங்கு அது இன்னும் Supported: 0 என்று குறிக்கப்பட்டுள்ளது, இது Canonical திறந்த பாதையை விட முன்னதாக உள்ளது. TPM-backed full disk encryption-ல் இயங்கும் கணினிகள் 26.04-லிருந்து 26.10-க்கு வெளியீட்டின் போது மேம்படுத்த முடியாது என்று 26.10 release notes குறிப்பிடுகிறது. 26.04-ல் Prompt=lts இருக்கும்போது, meta-release-lts-development என்பது resolute-க்கு பிறகு எதையும் பட்டியலிடாது, மேலும் அந்த flag அதன் சொந்த செய்தியுடன் நின்றுவிடும்:

There is no development version of an LTS available.

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

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

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

இணைப்பு துண்டிக்கப்பட்டால், மீண்டும் 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 துண்டிக்கப்பட்டாலும், உள்ளே நுழைய ஒரு வழி இருக்கும். இது தனது parent processes-ஐ ஆய்வு செய்து, sshd என்ற பெயரில் ஏதேனும் உள்ளதா என்று பார்க்கும். Tmux அல்லது screen-க்குள் இருக்கும்போது, அந்த ஆய்வு multiplexer server-ஐக் கண்டறியும், எனவே இந்த அனுமதி கேட்கும் திரை தோன்றாது. மேலும், கூடுதல் daemon தொடங்கும் போது மட்டுமே /var/run/release-upgrader-sshd.pid என்ற pid file உருவாக்கப்படும். அந்தத் திரை உங்களுக்குத் தோன்றவில்லை என்றால் கவலைப்பட வேண்டாம்; நீங்கள் ஏற்கனவே சிறந்த பாதுகாப்பைக் கொண்டுள்ளீர்கள்.

நீங்கள் அந்த அனுமதியை ஏற்றுக்கொண்டால், port தானாகவே திறக்கப்படாது. அந்தத் தளம் இதைத் தெளிவாகக் குறிப்பிடும், ஏனெனில் ஒரு port-ஐத் திறப்பது என்பது பாதுகாப்பு தொடர்பான முடிவு, அதை உங்கள் சார்பாக அந்தத் கருவி எடுக்காது. 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-ஐத் திரும்பப் பெற முடியாது, இதுவே உங்களுக்கான ஒரே வாய்ப்பு.
• தேவைப்படுவதற்கு முன்பே உங்கள் வழங்குநரின் console-ஐ அணுக முடிகிறதா என்று உறுதிப்படுத்தவும். Reboot செய்த பிறகு server மீண்டும் வரவில்லை என்றால், SSH மூலம் உங்களால் நுழைய முடியாது. Kernel boot ஆகத் தவறினால், அது தனிப்பட்ட சிக்கல்; அதற்கான மீட்பு வழிமுறைகள் kernel update-க்குப் பிறகு boot ஆகாத VPS பகுதியில் கொடுக்கப்பட்டுள்ளன.
• df -h / /boot மூலம் போதிய இடவசதி உள்ளதா என்று சரிபார்க்கவும். Upgrade-ன் போது முழுமையான packages தரவிறக்கம் செய்யப்படும். பல பழைய kernels இருக்கும் /boot partition-ல் இடமில்லாமல் upgrade பாதியில் நிற்க வாய்ப்புள்ளது.
• நீங்கள் இயக்கும் services-க்கான release notes-ஐப் படிக்கவும். PostgreSQL அல்லது PHP-ன் major version மாற்றம், நீங்கள் திட்டமிட்டிருந்தாலும் இல்லாவிட்டாலும், இந்த release-உடன் சேர்ந்து வந்துவிடும்.

FAQ

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

LTS point release கட்டுப்பாடுகள் இதற்கு காரணமல்ல. Ubuntu 26.04.1, 27 August 2026 அன்று வெளியான பிறகு, 29 September 2026 அன்று Canonical LTS மேம்படுத்தல்களை அனுமதிக்கும் வரை, 26.04 பதிப்பானது Supported: 0-ஐ https://changelogs.ubuntu.com/meta-release-lts கோப்பில் கொண்டிருந்தது. இதுவே இயல்புநிலை Prompt=lts வாசிக்கும் கோப்பாகும், எனவே கருவி எதையும் கண்டறியவில்லை. 21 October 2026 அன்று சரிபார்த்தபோது அந்த flag 1 என இருந்தது, இப்போது 24.04 server-க்கு 26.04.1 வழங்கப்படுகிறது. உங்கள் server இன்னும் எதையும் கண்டறியவில்லை என்றால், login banner-ஐ நம்புவதற்கு பதிலாக sudo do-release-upgrade -c-ஐ இயக்கவும், server changelogs.ubuntu.com-ஐ அணுக முடிகிறதா என்று உறுதிப்படுத்தவும், மேலும் Prompt என்பது never என அமைக்கப்படவில்லை என்பதைச் சரிபார்க்கவும். Prompt=lts இருக்கும்போது, காலியான பதில் There is no development version of an LTS available. என்று வரும், இதுவும் அதே பொருளையே குறிக்கிறது.

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

24.04-லிருந்து 26.04-க்கு மாற இனி காத்திருக்க வேண்டியதில்லை. 27 August 2026 அன்று point release வெளியான பிறகு, 29 September 2026 அன்று Canonical மேம்படுத்தலை அனுமதித்தது. 21 October 2026 அன்று சரிபார்த்தபோது meta-release மற்றும் meta-release-lts ஆகிய இரண்டுமே 26.04-ஐ Supported: 1 எனக் குறிக்கின்றன. எனவே Prompt=lts ஏற்கனவே அதை வழங்குகிறது, அமைப்பை மாற்றுவதால் கூடுதல் பலன் ஏதுமில்லை. மேம்படுத்தல்கள் அனுமதிக்கப்படுவதற்கு முன்பு, Prompt=normal உங்களை development build-க்கு பதிலாக வெளியான 26.04-க்கு மேம்படுத்தியது, ஆனால் ஆரம்பக்கால பயனர்கள் கண்டறிந்த சிக்கல்கள் சரிசெய்யப்படுவதற்கு முன்பே நீங்கள் மேம்படுத்த வேண்டியிருந்தது. காத்திருந்தபோது நீங்கள் அமைப்பை மாற்றியிருந்தால், அதன் மதிப்பை மீண்டும் lts என மாற்றவும்.

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

24.04-லிருந்து ஆம். -d நீங்கள் இயக்கும் பதிப்பிற்கு அடுத்ததாக உள்ள முதல் release-ஐ எடுத்துக்கொள்ளும். அந்த இரண்டு development கோப்புகளிலும் 26.04 (தற்போது 26.04.1) உள்ளது. இதனால்தான் Canonical-ன் 26.04.1 அறிவிப்பு, ஆர்வமுள்ள 24.04 பயனர்களை do-release-upgrade -d-ஐ இயக்கச் சொல்கிறது. 21 October 2026 அன்று சரிபார்க்கப்பட்ட meta-release-development-ன் புதிய பதிவு Ubuntu 26.10 ஆகும். இது 15 October 2026 அன்று வெளியானது, ஆனால் இன்னும் Supported: 0 எனக் குறிக்கப்பட்டுள்ளது மற்றும் meta-release-ல் பட்டியலிடப்படவில்லை. 26.04 server-லிருந்து -d அதைத்தான் சுட்டிக்காட்டுகிறது. Ubuntu-வின் server ஆவணங்களின்படி, development release (அல்லது -d flag) production பயன்பாட்டிற்கு பரிந்துரைக்கப்படுவதில்லை. LTS கட்டுப்பாடு நீக்கப்பட்டுள்ளதால், flag இல்லாமலேயே சாதாரண do-release-upgrade மூலம் 26.04.1-ஐ அடையலாம்.

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

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

do-release-upgrade இயக்கும் முன் எனது PPA-க்களை நீக்க வேண்டுமா?

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