Ubuntu 24.04-ஐ 26.04-க்கு 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 அன்று வெளியிடப்பட்டது. ஆனால், Canonical நிறுவனம் முதல் point release-ன் போதுதான் LTS-லிருந்து LTS-க்கு upgrade செய்யும் பாதையைத் திறக்கும். ஏனெனில், முதல் சில மாதங்களில் கண்டறியப்பட்ட நிறுவல் மற்றும் upgrade பிழைகளை அந்த release சரிசெய்கிறது. இந்த numbering முறை உங்களுக்குப் புதியது என்றால், 26.04.1 என்பது வேறொரு Ubuntu அல்ல, அது அதே 26.04 தான்; நான்கு மாத கால பிழைத்திருத்தங்கள் அதில் இணைக்கப்பட்டுள்ளன. இதனால்தான், ஏற்கனவே இயங்கிக்கொண்டிருக்கும் ஒரு server-க்கு Canonical வழங்கும் முதல் பதிப்பாக இது இருக்கும்.

August 2026 தொடக்கத்தில் 24.04 box-ல் சரிபார்ப்பைச் செய்தால், உங்களுக்குக் கிடைப்பது இதுதான்:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

இது உங்கள் server-ல் உள்ள பிழை அல்ல. /etc/update-manager/release-upgrades-ல் Ubuntu Server-க்கான Prompt=lts உள்ளது. அதாவது, இந்த tool அடுத்த long term support release-ஐ மட்டுமே காட்டும், அதுவும் அதன் .1 point release வெளியான பிறகுதான் காட்டும். Prompt=normal என்று அமைத்தால், அது 24.10, 25.04 மற்றும் 25.10 என வரிசையாக interim releases வழியாக உங்களை அழைத்துச் செல்லும்; இவை அனைத்தும் ஏற்கனவே காலாவதியாகிவிட்டன (end of life). இதை lts நிலையிலேயே விட்டுவிட்டு காத்திருக்கவும். Canonical-ன் கால அட்டவணையில் உள்ள தேதிகள் மாறக்கூடும், எனவே குறிப்பிட்ட நாள் அமைதியாகக் கடந்தால் மீண்டும் சரிபார்க்கவும்.

கீழே உள்ள ஒவ்வொரு கட்டளையையும் உங்கள் server-ல், கொடுக்கப்பட்டுள்ள வரிசையில் நீங்களே இயக்க வேண்டும். நீங்கள் upgrade செய்யும் machine-ல் release upgrade-ஐ ஒத்திகை பார்க்க முடியாது. இது kernel மற்றும் C library-ஐ மாற்றியமைக்கும், மேலும் முடிப்பதற்கு ஒரு reboot தேவைப்படும்.

நீங்கள் மேம்படுத்த வேண்டுமா?

Ubuntu 24.04-க்கான தரமான பாதுகாப்பு மேம்படுத்தல்கள் 2029 வரை கிடைக்கும். எனவே, சரியாக இயங்கும் production server-க்கு எந்த அவசரமும் இல்லை. 26.04-ல் உள்ள PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 அல்லது 7.0 kernel போன்ற புதிய அம்சங்கள் தேவைப்பட்டால் மட்டுமே மேம்படுத்தவும். வாடிக்கையாளர்களுக்குச் சேவை வழங்கும் ஒரு இயந்திரத்தை, வெறும் "பதிப்பு எண் அதிகரித்துள்ளது" என்பதற்காக மாற்ற வேண்டிய அவசியமில்லை.

கீழ்க்கண்ட சூழல்களில் in-place மேம்படுத்தலைத் தவிர்க்கவும்:

• உங்கள் provider-ன் console-ஐ (VNC அல்லது serial) நீங்கள் இதுவரை பயன்படுத்தியதில்லை என்றால். SSH இணைப்பு துண்டிக்கப்பட்டால், அந்த console மட்டுமே மீண்டும் உள்ளே நுழைய உதவும் ஒரே வழி. நீங்கள் வெளியேற்றப்பட்ட பிறகு அது வேலை செய்யவில்லை என்று கண்டறிவது மிகவும் தாமதமாகும்.
• ஒரு மணிநேரம் downtime-ஐ உங்களால் தாங்க முடியாது மற்றும் உங்களிடம் rollback வசதி இல்லை என்றால்.
• உங்கள் stack, resolute-க்கு இன்னும் வெளியிடப்படாத ஒரு third-party repository-ஐச் சார்ந்திருந்தால்.
• அந்த server இரண்டு ஆண்டுகளாகக் கையால் கட்டமைக்கப்பட்டு, அதில் என்னென்ன உள்ளது என்பது யாருக்கும் தெரியவில்லை என்றால்.

இதற்குப் பதிலாக, புதிய 26.04 VPS-ஐ உருவாக்கி, உங்கள் stack-ஐ நிறுவி, தரவுகளை restore செய்து, அது சரியாக இயங்கிய பிறகு DNS-ஐ மாற்றுவது சிறந்த முறையாகும். புதிய server சரியாகச் செயல்படும் வரை பழைய server-ஐ இயங்க விடலாம்; ஏதேனும் சிக்கல் ஏற்பட்டால், restore செய்வதற்குப் பதிலாக DNS-ஐ மீண்டும் பழைய நிலைக்கு மாற்றுவது எளிது. நீங்கள் இந்த வழியைத் தேர்ந்தெடுக்க விரும்பினால், புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியிலிருந்து தொடங்கி, புதிய server-ஐச் சரியாகக் கட்டமைக்கவும்.

படி 1: மீட்டெடுக்கக்கூடிய வகையில் backup எடுக்கவும்

இரண்டு அடுக்குகளைப் பயன்படுத்தவும், ஏனெனில் அவை வெவ்வேறு வழிகளில் தோல்வியடையக்கூடும். ஒரு provider snapshot முழு வட்டுக்கும் (disk) பாதுகாப்பு அளிக்கிறது மற்றும் சில நிமிடங்களில் மீட்டெடுக்க முடியும். ஆனால், இது உங்கள் databases தரவுகளை எழுதும்போதே எடுக்கப்படுவதால், இது application consistent-ஆக இருக்காது, மாறாக crash consistent-ஆக மட்டுமே இருக்கும். restic, server-க்கு வெளியே சேமிக்கப்படும் கோப்பு அளவிலான (file-level) backup, தனிப்பட்ட கோப்புகளை மீட்டெடுக்கவும், உங்கள் கணக்கு முடக்கப்பட்டாலும் தரவுகளைப் பாதுகாக்கவும் உதவுகிறது.

முதலில் 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 அட்டவணைகளுக்கு மட்டுமே சீரான (consistent) dump-ஐ வழங்குகிறது. MyISAM அட்டவணைகளுக்கு database-ஐ நிறுத்த வேண்டியது அவசியம். /etc tarball-தான் நீங்கள் உண்மையில் பயன்படுத்த வேண்டியது, ஏனெனில் upgrade-ன் போது கேட்கப்படும் அனைத்து configuration கோப்புகளும் அதில் இருக்கும்.

நீங்கள் ஒருமுறை கூட மீட்டெடுத்துப் பார்க்காத backup என்பது வெறும் ஊகம் மட்டுமே. அவசர காலத்தில் தேவைப்படும் முன், இப்போதே அதிலிருந்து ஒரு கோப்பை எடுத்துச் சோதிக்கவும்.

படி 2: முதலில் 24.04-ஐ முழுமையாக patch செய்யவும்

do-release-upgrade சிதைந்த package நிலையைக் கொண்ட ஒரு system-ல் இயங்க மறுக்கும். முழுமையடையாத 24.04 patch, பிற்காலத்தில் ஏற்படும் பிழைகளைக் கண்டறிவதை கடினமாக்கும்.

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

dpkg --audit எதையும் அச்சிடவில்லை என்றால், எந்த package-ம் பாதியிலேயே கட்டமைக்கப்படவில்லை என்று அர்த்தம். apt-mark showhold எதையும் அச்சிடவில்லை என்றால், upgrade-ஐத் தடுக்கும் வகையில் எந்த package-ம் ஒரு குறிப்பிட்ட version-ல் முடக்கப்படவில்லை (pinned) என்று அர்த்தம். அது பட்டியலிடும் எதையும் sudo apt-mark unhold மற்றும் package பெயரைப் பயன்படுத்தி விடுவிக்கவும், அல்லது அந்தத் தடை ஒரு காரணத்திற்காகவே உள்ளது என்பதை ஏற்றுக்கொண்டு இங்கேயே நிறுத்திவிடவும்.

Kernel மாறியிருந்தால், கணினியை reboot செய்யவும். அப்போதுதான், இயங்கிக்கொண்டிருக்கும் code-க்கும் system கருதும் code-க்கும் இடையே ஒற்றுமை இருக்கும்.

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

பிறகு disk space-ஐச் சரிபார்க்கவும். Upgrader புதிய package தொகுப்பு முழுவதையும் பதிவிறக்கம் செய்த பின்னரே எதையும் நிறுவும். போதிய இடவசதி இல்லையெனில், எந்த filesystem-ல் இடம் பற்றாக்குறை உள்ளது என்பதைக் குறிப்பிட்டு அது நின்றுவிடும்.

df -h / /boot

/-ல் சுமார் 5 GB-க்கும் குறைவாக இடம் இருந்தால், சிக்கல்கள் ஏற்படும். /boot-ல் 300 MB-க்கும் குறைவாக இடம் இருந்தால், kernel நிறுவலின் போது No space left on device பிழையுடன் அது தோல்வியடையும். பழைய kernel-களே இதற்கு முக்கியக் காரணம், sudo apt --purge autoremove அவற்றை நீக்கி இடத்தைச் சுத்தம் செய்யும்.

தொடங்குவதற்கு முன் கவனிக்க வேண்டிய மற்றொரு விஷயம்: தானியங்கி பாதுகாப்பு மேம்படுத்தல்கள் (automatic security updates) இடையில் இயங்கினால், அவை dpkg lock-ஐப் பிடித்துக்கொள்ளும். இதனால் release upgrader Could not get lock /var/lib/dpkg/lock-frontend பிழையுடன் நின்றுவிடும். முதலில் sudo systemctl stop unattended-upgrades-ஐ இயக்கவும், அது முடிந்த பிறகு மீண்டும் தொடங்கவும்.

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

do-release-upgrade, Ubuntu-வினுடையது அல்லாத அனைத்து apt source-களையும் முடக்குகிறது. ஏனெனில், noble-க்காக உருவாக்கப்பட்ட ஒரு package, resolute அமைப்பைச் சிதைக்கக்கூடும். இது தனக்குத் தெரிந்த source-களைப் பின்னர் மீண்டும் செயல்படுத்துகிறது, மற்றவற்றை comment செய்து விடுகிறது. கருவி உங்களுக்காக முடிவெடுக்கும் முன், நீங்கள் எதைப் பயன்படுத்துகிறீர்கள் என்பதைத் தெரிந்துகொள்ளுங்கள்.

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-யில் இரண்டு வடிவங்களைப் பயன்படுத்துகிறது: பழைய ஒரு வரி .list கோப்புகள், மற்றும் Types:, Suites: புலங்களைக் கொண்ட deb822 .sources கோப்புகள். மேம்படுத்தலின் போது இவை இரண்டும் முடக்கப்படுகின்றன. ubuntu-security-status --thirdparty, Ubuntu archive-ல் இல்லாத, நீங்கள் நிறுவியுள்ள packages-களின் பட்டியலைக் காட்டுகிறது; இது நீங்கள் கூடுதலாக இணைத்துள்ளவற்றின் உண்மையான எண்ணிக்கையாகும். /etc/apt/preferences.d/-ல் உள்ளவை அனைத்தும் pins ஆகும். noble-க்காக எழுதப்பட்ட ஒரு pin, புதிய release-லும் பழைய package-ஐயே தேர்ந்தெடுக்கச் செய்யும்.

ஒவ்வொரு மூன்றாம் தரப்பு களஞ்சியத்திற்கும், நீங்கள் தொடங்குவதற்கு முன்பே அந்த vendor புதிய codename-க்கான பதிப்பை வெளியிட்டுள்ளாரா என்பதை உறுதிப்படுத்தவும். Docker-ன் suites https://download.docker.com/linux/ubuntu/dists/-ல் பட்டியலிடப்பட்டுள்ளன; பிற vendor-களும் இதே போன்ற directory-யையே வழங்குகிறார்கள். மேம்படுத்தலுக்குப் பிறகு முதல் apt update-ன் போது, இல்லாத ஒரு suite-ஐக் குறிக்கும் source பின்வரும் பிழையைக் காட்டும்:

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

vendor வெளியிடும் வரை அந்த source-ஐ முடக்கப்பட்ட நிலையிலேயே வைத்திருக்கவும். vendor உருவாக்காத ஒரு codename-க்கு மாற்றுவது, தவறான system libraries-உடன் இணைக்கப்பட்ட packages-களை நிறுவுவதற்கு வழிவகுக்கும்.

படி 4: plain SSH shell-க்கு பதிலாக tmux-ல் upgrade-ஐ இயக்கவும்

நீங்கள் plain login shell-ல் do-release-upgrade-ஐ இயக்கும்போது உங்கள் connection துண்டிக்கப்பட்டால், அந்த process SIGHUP சிக்னலைப் பெற்று பாதியிலேயே நின்றுவிடும். இதனால் dpkg பாதியிலேயே configuration நிலையில் இருக்கும்; மேலும், மீண்டும் இணைக்கத் தேவையான network stack கூட அந்த server-ல் வேலை செய்யாமல் போகலாம். எனவே, ஒரு terminal multiplexer-க்குள் இதை இயக்கவும். அப்போதுதான் உங்கள் client துண்டிக்கப்பட்டாலும், server-ல் அந்த process தொடர்ந்து இயங்கும்.

sudo apt install -y tmux
tmux new -s upgrade

அந்த session-க்குள்:

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

எந்த மாற்றத்தையும் செய்வதற்கு முன்பாக, upgrader ஆனது port 1022-ல் இரண்டாவது SSH daemon-ஐத் தொடங்கும். அது குறித்த தகவலைக் காட்டும்:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

அது உங்கள் firewall-ல் அந்த port-ஐத் தானாகத் திறக்காது. ஏனெனில், அனுமதி இன்றி firewall-ல் துளையிடுவது பாதுகாப்பற்றது. எனவே, தொடங்குவதற்கு முன்பாக 1022 port-ஐ நீங்களே திறந்து வைத்துக்கொள்ளுங்கள், sudo ufw delete allow 1022/tcp முடிந்ததும் அதை மூடிவிடவும். உங்கள் provider-ன் control panel-ல் server-க்கு வெளியே மற்றொரு firewall இருக்கலாம் என்பதையும் நினைவில் கொள்ளுங்கள்.

ஒருவேளை connection துண்டிக்கப்பட்டால், மீண்டும் login செய்து tmux attach -t upgrade-ஐ இயக்கவும். நீங்கள் இல்லாதபோதும் upgrade தொடர்ந்து இயங்கிக்கொண்டிருந்திருக்கும்.

படி 5: configuration file கேட்கும் கேள்விகளுக்கு கவனமாக பதிலளிக்கவும்

நீங்கள் அல்லது ஒரு script மாற்றியமைத்த கோப்புகளுக்கு மட்டுமே dpkg கேள்விகளை எழுப்பும். எனவே, ஒவ்வொரு கேள்வியும் நீங்கள் வேண்டுமென்றே மாற்றியமைத்த ஒரு கோப்பைக் குறிக்கிறது. கேள்வியைத் தவிர்க்க Enter அழுத்துவது, பாதுகாப்பான server-ஐ இயல்புநிலை அமைப்புகளுக்குத் தள்ளும் செயலாகிவிடும்.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

ஒவ்வொரு முறையும் முதலில் D அழுத்தவும். என்ன மாற்றங்கள் செய்யப்பட்டுள்ளன என்பதைப் படித்துவிட்டு, உங்கள் பதிப்பைத் தக்கவைக்க N என்பதைத் தேர்ந்தெடுக்கவும். இயல்புநிலையாக N தேர்ந்தெடுக்கப்பட்டிருக்கும், இதுவே பாதுகாப்பான பதில். ஏனெனில், உங்கள் கோப்பு தற்போது சரியாகச் செயல்படுகிறது, ஆனால் தொகுக்கப்பட்ட புதிய கோப்பு இந்த machine-ல் இதுவரை இயங்கியதில்லை.

உங்கள் கோப்பைத் தக்கவைப்பதில் ஒரு குறைபாடு உள்ளது: புதிய இயல்புநிலை அமைப்புகள் உங்களுக்குக் கிடைக்காது. server இயங்கத் தொடங்கிய பிறகு, அவசரமில்லாத நேரத்தில் அவற்றைச் சரிசெய்து கொள்ளவும்.

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

பட்டியலிடப்படும் ஒவ்வொரு கோப்பும் பராமரிப்பாளரின் (maintainer) பதிப்பாகும், அது உங்கள் கோப்பிற்கு அருகிலேயே சேமிக்கப்படும். ஒவ்வொன்றாக diff செய்து பார்த்து, தேவையான அமைப்புகளை மட்டும் நகலெடுக்கவும். இரண்டு கோப்புகளில் கூடுதல் கவனம் தேவை: /etc/ssh/sshd_config, ஏனெனில் தவறான பதில் உங்கள் session-ஐ முடித்துவிடும்; மற்றொன்று உங்கள் web server config, ஏனெனில் தவறான பதில் தளங்களை முடக்கிவிடும்.

மேம்படுத்தலின் போது, எந்தெந்த services-ஐ restart செய்ய வேண்டும் என்று needrestart கேட்கும். முழுப் பட்டியலையும் ஏற்கவும். வட்டில் (disk) நீக்கப்பட்ட shared library கோப்பைப் பயன்படுத்தி ஒரு daemon தொடர்ந்து இயங்கினால், அது பிற்காலத்தில் எதிர்பாராத நேரத்தில் செயலிழக்கக்கூடும்.

படி 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 கட்டளை எந்த unit-களையும் காட்டக்கூடாது; அது எதையேனும் காட்டினால், அதைச் சரிசெய்வதே உங்கள் அடுத்த பணி. இறுதியாக, apt update கட்டளை release images உருவாக்கப்பட்ட பிறகு வெளியிடப்பட்ட அனைத்து updates-களையும் பதிவிறக்கம் செய்யும்.

PostgreSQL 16 முதல் 18 வரை: அமைதியாகப் பின்தங்கியிருக்கும் cluster

Ubuntu 24.04-ல் PostgreSQL 16-ம், 26.04-ல் PostgreSQL 18-ம் வழங்கப்படுகின்றன. மேம்படுத்தல் (upgrade) செயல்முறை 18-ஐ 16-க்கு அருகிலேயே நிறுவும், ஆனால் உங்கள் தரவுகளை நகர்த்தாது. Debian-ன் postgresql-common அடுக்கு, புதிய major version-க்காக அடுத்த காலியாக உள்ள port-ல் ஒரு புதிய cluster-ஐ உருவாக்கும். எனவே, 16 உங்கள் தரவுகளுடன் 5432 port-ல் தொடர்ந்து இயங்கும், 18 காலியாக 5433 port-ல் அமர்ந்திருக்கும். உங்கள் application தொடர்ந்து 5432-உடன் தொடர்புகொள்வதால், எந்தப் பிரச்சினையும் இல்லாதது போலத் தோன்றும்; இதனால்தான் பல மாதங்களுக்குப் பிறகு மக்கள் இதைக் கவனிக்கிறார்கள்.

pg_lsclusters

இரண்டு cluster-கள் பட்டியலிடப்பட்டால், நீங்கள் இன்னும் தரவுகளை மாற்றவில்லை (migrate) என்று அர்த்தம். application-ஐ நிறுத்தக்கூடிய நேரத்தில் இதைச் செய்யுங்கள்:

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

முதலில் காலியாக உள்ள 18 cluster-ஐ நீக்கவும், ஏனெனில் pg_upgradecluster ஏற்கனவே உள்ள ஒரு target cluster-ல் தரவுகளை எழுதாது. இயல்பான முறையில் 16-ல் உள்ள தரவுகள் dump செய்யப்பட்டு 18-ல் ஏற்றப்படும், எனவே database-ன் அளவுக்கு இணையான காலி வட்டு இடம் (disk space) தேவைப்படும். -m upgrade இதற்குப் பதிலாக pg_upgrade-ஐப் பயன்படுத்துகிறது, இது பெரிய database-களுக்கு மிக வேகமானது. இது முடிந்ததும், Port நெடுவரிசையைப் பார்க்கவும்: புதிய cluster 5432-ஐ எடுத்துக்கொள்ளும், பழையது நிறுத்தப்பட்ட நிலையில் இருக்கும். analyze கட்டளையை நீங்களே இயக்கவும், ஏனெனில் புதிதாக ஏற்றப்பட்ட cluster-ல் புள்ளிவிவரங்கள் (statistics) இருக்காது, இதனால் முதல் queries மெதுவாக இருக்கும்.

புதிய cluster-ல் சில நாட்களுக்கு application-ஐச் சோதிக்கவும். அதன் பிறகு பழையதை நீக்கவும்:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

பழைய cluster-ன் தரவு அடைவு (data directory) தான் மிக வேகமான rollback வழி. மேம்படுத்தல் நாளில் அதை நீக்க வேண்டாம்.

MySQL 8.0 முதல் 8.4 வரை: சர்வரை நிறுத்தும் நீக்கப்பட்ட விருப்பத்தேர்வு

26.04 பதிப்பில் MySQL 8.0-லிருந்து 8.4 LTS-க்கு மாறுகிறது. இதில் இரண்டு மாற்றங்கள் சர்வர்களைப் பாதிக்கின்றன.

முதலில், புதிய பதிப்பில் நீக்கப்பட்ட ஒரு விருப்பத்தேர்வு (option) config கோப்பில் இருந்தால், mysqld தொடங்க மறுக்கும். default_authentication_plugin என்பது பொதுவாகப் பயன்படுத்தப்படும் ஒன்று, ஏனெனில் பல பழைய வழிகாட்டிகள் இதை அமைக்கச் சொல்கின்றன. இதனால் service தோல்வியடையும், மேலும் journalctl -u mysql -n 50 தெரியாத மாறியை (variable) நேரடியாகக் குறிப்பிடும். /etc/mysql/mysql.conf.d/-க்குக் கீழே உள்ள கோப்பிலிருந்து அந்த வரியை நீக்கிவிட்டு, பின் sudo systemctl start mysql செய்யவும்.

இரண்டாவதாக, 8.4 பதிப்பில் mysql_native_password plugin இயல்பாகவே (default) இயக்கப்படுவதில்லை. எனவே, அதைப் பயன்படுத்தும் கணக்குகள் எதிலும் உள்நுழைய முடியாது. நீங்கள் இன்னும் 8.0 பதிப்பில் இருக்கும்போதே இதைச் சரிபார்க்கவும்:

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

மேம்படுத்தலுக்கு (upgrade) முன்பே mysql_native_password என்று காட்டும் ஒவ்வொரு கணக்கையும் மாற்றவும், பிறகு உங்கள் application config-ல் கடவுச்சொல்லைப் புதுப்பிக்கவும்:

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-ஐ மீண்டும் இயக்கலாம். இது ஒரு தற்காலிக ஏற்பாடு மட்டுமே, ஏனெனில் இந்த plugin முழுமையாக நீக்கப்பட உள்ளது.

PHP 8.3 முதல் 8.5 வரை: உங்கள் vhosts குறிப்பிடும் socket நீக்கப்பட்டுவிட்டது

24.04 பதிப்பில் PHP 8.3-ம், 26.04 பதிப்பில் PHP 8.5-ம் வருகின்றன. இந்த packages பதிப்பு சார்ந்த பாதைகளில் (versioned paths) நிறுவப்படுகின்றன, உங்கள் web server configuration-ஐ எவையும் தானாக மாற்றாது. fastcgi_pass unix:/run/php/php8.3-fpm.sock;-ஐக் கொண்ட ஒரு nginx vhost தற்போது எந்த process-உம் உருவாக்காத ஒரு socket-ஐக் குறிப்பிடுகிறது. எனவே, ஒவ்வொரு PHP கோரிக்கையும் 502 பிழையைத் தருகிறது மற்றும் nginx error log பின்வருமாறு காட்டுகிறது:

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

இதை புதிய socket-க்கு மாற்றி, configuration-ஐச் சோதித்து, 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

Apache-ல் mod_php பயன்படுத்தினால் அறிகுறி வேறாக இருக்கும்: Apache தொடங்கவே செய்யாது, மேலும் sudo apache2ctl -t, libphp8.3.so கோப்பு இல்லாததால் அதை ஏற்ற முடியவில்லை என்று தெரிவிக்கும். இயக்கப்பட்ட module, நீக்கப்பட்ட ஒரு package-க்கான symlink ஆக இருக்கும்.

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

நீங்கள் Ubuntu 24.04-ல் ஒரு LAMP stack மூலம் இந்த server-ஐ உருவாக்கியிருந்தால், அந்த இரண்டு பாதைகளையும் சரிபார்க்க வேண்டும், ஏனெனில் அந்த வழிகாட்டி உங்களை ஒரு பதிப்பு சார்ந்த module பெயர் மற்றும் பதிப்பு சார்ந்த socket-உடன் விட்டுவிடும்.

உங்கள் php.ini மாற்றங்களும் தானாக மாறாது. memory_limit, upload_max_filesize மற்றும் நீங்கள் அமைத்த பிற அனைத்தும் /etc/php/8.3/-ல் உள்ளன, புதிய பதிப்பு இயல்புநிலை அமைப்புகளுடன் (defaults) தொடங்குகிறது. இரண்டு கோப்புகளையும் diff செய்து, மதிப்புகளைக் கையால் நகலெடுக்கவும். பழைய கோப்பை அப்படியே புதிய கோப்பின் மேல் நகலெடுத்தால், 8.3-ன் இயல்புநிலை அமைப்புகள் 8.5 நிறுவலில் சிக்கலை ஏற்படுத்தும். பிறகு php -m-ஐ இயக்கி ஒப்பிடவும்: php8.3-redis என நிறுவப்பட்ட ஒரு extension-க்கு அதன் php8.5- package தேவைப்படும். அது ஒரு PPA-விலிருந்து வந்திருந்தால், மேம்படுத்தும் போது அந்த source முடக்கப்பட்டிருக்கும், எனவே அந்த extension விடுபட்டிருக்கும்.

Certificates-ஐத் தனியாக ஒருமுறை சரிபார்க்க வேண்டும். மேம்படுத்தலுக்குப் பிறகு sudo certbot renew --dry-run-ஐ இயக்கவும். இது நேரடி certificate-ஐப் பாதிக்காமல், web server reload hook உட்பட முழு புதுப்பித்தல் பாதையையும் (renewal path) சோதிக்கும். மாறிய ஒரு service பெயர் அல்லது binary-ஐ அழைக்கும் hook, 60 நாட்களுக்குப் பிறகு அமைதியாகத் தோல்வியடைவதற்குப் பதிலாக, இப்போதே உங்கள் கண்முன்னே தோல்வியடையும். Certbot with Let's Encrypt on nginx அந்த hooks எப்படி இருக்க வேண்டும் என்பதை விளக்குகிறது.

SSH: நீங்கள் பணிபுரியும் அமர்வை முடிவுக்குக் கொண்டுவரும் தோல்வி

sshd_config prompt என்பது மக்கள் தங்களைத் தாங்களே வெளியேற்றிக்கொள்ளும் இடமாகும். Y என்பதற்குப் பதிலளிப்பது, பராமரிப்பாளரின் கோப்பை நிறுவுகிறது; இது உங்கள் PermitRootLogin, PasswordAuthentication, AllowUsers, Port மற்றும் நீங்கள் சேர்த்த மற்ற அனைத்து வரிகளையும் நீக்கிவிடும். உங்கள் firewall ஒரு custom port-ஐ மட்டுமே அனுமதித்து, தொகுக்கப்பட்ட configuration 22-ல் இயங்கினால், அடுத்த இணைப்பு மறுக்கப்படும்; நீங்கள் தற்போது அமர்ந்திருக்கும் அமர்வே உங்களின் கடைசி அமர்வாகிவிடும்.

Upgrade செய்வதற்கு முன்பே இதைத் தடுக்கவும். 24.04-ல் உள்ள /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf உடன் தொடங்குகிறது. OpenSSH ஒவ்வொரு அமைப்பிற்கும் அது முதலில் வாசிக்கும் மதிப்பையே வைத்திருக்கும், எனவே மேலே சேர்க்கப்படும் drop-in கோப்பு கீழே உள்ள எதையும் விட முன்னுரிமை பெறும். உங்கள் அமைப்புகளை dpkg-க்குச் சொந்தமில்லாத ஒரு கோப்பிற்கு மாற்றவும்:

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 முக்கியத்துவத்தை இழக்கிறது: எந்தப் பதிலைத் தேர்ந்தெடுத்தாலும் உங்கள் அமைப்புகள் மாறாது, ஏனெனில் அவை வேறொரு கோப்பில் உள்ளன.

Custom port-க்கு கூடுதல் சரிபார்ப்பு தேவை, ஏனெனில் அது நீங்கள் நினைக்கும் இடத்தில் இல்லாமல் இருக்கலாம்:

systemctl is-enabled ssh.socket

இது enabled என்று காட்டினால், listening port-ஐ systemd நிர்வகிக்கிறது மற்றும் sshd_config-ல் உள்ள Port வரி புறக்கணிக்கப்படுகிறது. Ubuntu 22.10 முதல் sshd-க்கு socket activation-ஐப் பயன்படுத்துகிறது, இதனால்தான் Port 2222-ல் செய்யப்படும் மாற்றம் எதையும் செய்யாதது போல் தோன்றுகிறது. அதற்குப் பதிலாக, sudo systemctl edit ssh.socket மூலம் socket unit-ல் அதை அமைக்கவும்:

[Socket]
ListenStream=
ListenStream=2222

வெற்று ListenStream= அவசியம். இது பெறப்பட்ட மதிப்பை நீக்குகிறது, இது இல்லையெனில் socket 22 மற்றும் 2222 ஆகிய இரண்டிலும் கேட்கும். sudo systemctl daemon-reload && sudo systemctl restart ssh.socket மூலம் இதைச் செயல்படுத்தவும்.

Upgrade செய்த பிறகு, நீங்கள் இருக்கும் அமர்வை மூடுவதற்கு முன்:

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

பிறகு உங்கள் கணினியில் இரண்டாவது terminal-ஐத் திறந்து மீண்டும் login செய்யவும். அந்த இரண்டாவது terminal-ல் கிடைக்கும் working shell மட்டுமே உண்மையான சான்றாகும். அது கிடைக்கும் வரை முதல் அமர்வைத் திறந்து வைத்திருக்கவும். VPS-ல் SSH-ஐப் பாதுகாத்தல் அந்த drop-in கோப்பில் வைத்திருக்க வேண்டிய அமைப்புகளை விளக்குகிறது.

ஏற்கனவே தாமதமாகிவிட்டால், உங்கள் provider-ன் web console உங்களுக்கு SSH-ஐப் பயன்படுத்தாத login-ஐ வழங்குகிறது. அங்கு login செய்து, config-ஐச் சரிசெய்து, sudo sshd -t-ஐ இயக்கி, service-ஐ restart செய்யவும். அந்த console-ஐப் பயன்படுத்துவதுதான், upgrade-ன் போது அல்லாமல், அதற்கு முன்பே console access-ஐச் சோதிக்க வேண்டியதற்கான காரணம்.

FAQ

Ubuntu 24.04-ல் do-release-upgrade ஏன் "No new release found" என்று காட்டுகிறது?

ஏனெனில் /etc/update-manager/release-upgrades-ல் Prompt=lts என்ற அமைப்பு உள்ளது. இந்த அமைப்பு, அடுத்த நீண்டகால ஆதரவு (LTS) பதிப்பை அதன் முதல் point release வெளியான பிறகு மட்டுமே வழங்கும். Ubuntu 26.04 LTS பதிப்பு 23 ஏப்ரல் 2026 அன்று வெளியானது, அதன் 26.04.1 பதிப்பு 27 ஆகஸ்ட் 2026 அன்று வெளியாகத் திட்டமிடப்பட்டுள்ளது. அந்த நாள் வரை, 24.04 server எந்தப் புதிய பதிப்பையும் கண்டறியாது. Prompt=normal-க்கு மாற்றுவதற்குப் பதிலாக, இந்த அமைப்பை அப்படியே விடுவது சிறந்தது; ஏனெனில் அது உங்களை இடைக்கால (interim) பதிப்புகள் வழியாக அழைத்துச் செல்லும்.

மேம்படுத்தலை முடிக்க server-ஐ reboot செய்ய வேண்டுமா?

ஆம். இந்த மேம்படுத்தல் புதிய kernel, புதிய C library மற்றும் புதிய init system ஆகியவற்றை நிறுவுகிறது. கணினி மறுதொடக்கம் செய்யப்படும் வரை, இயங்கிக்கொண்டிருக்கும் system பழையவற்றையே பயன்படுத்தும். do-release-upgrade மேம்படுத்தலின் இறுதியில் reboot செய்யக் கேட்கும். "பிறகு" செய்யலாம் என்று விட்டுவிட்டால், அந்த machine இரண்டு பதிப்புகளின் கலவையில் இயங்கும். கணினி மீண்டும் வந்த பிறகு, புதிய kernel-ஐச் சரிபார்க்க uname -r-ஐயும், இயங்காத சேவைகளைக் கண்டறிய systemctl --failed-ஐயும் பயன்படுத்தவும்.

நான் in-place மேம்படுத்தல் செய்ய வேண்டுமா அல்லது புதிய 26.04 server-ஐ உருவாக்க வேண்டுமா?

முடிந்தவரை புதிய server-ஐ உருவாக்கவும். புதிய VPS-ல் stack-ஐ நிறுவி, தரவுகளை மீட்டெடுத்து, பழைய server traffic-ஐக் கையாண்டுகொண்டிருக்கும்போதே அனைத்தையும் சோதிக்கலாம். இதனால், ஏதேனும் சிக்கல் ஏற்பட்டால் DNS மாற்றத்தின் மூலம் எளிதாக rollback செய்ய முடியும்; backup-லிருந்து மீட்டெடுக்க வேண்டிய அவசியமில்லை. தரவுகளை நகர்த்துவது கடினமாக இருக்கும்போதோ, ஒவ்வொரு machine-க்கும் கட்டணம் வசூலிக்கும் சூழலிலோ, அல்லது உங்களிடம் snapshot மற்றும் console access இருக்கும்போதோ மட்டும் in-place மேம்படுத்தலைத் தேர்ந்தெடுக்கவும். In-place முறை நன்கு சோதிக்கப்பட்டதுதான், ஆனால் அது நடக்கும் ஒரு மணி நேரத்திற்கு அது ஒரு ஒருவழிப் பாதையாகவே இருக்கும்.

மேம்படுத்தலின் போது SSH இணைப்பு துண்டிக்கப்பட்டால் என்னவாகும்?

சாதாரண login shell-ல் மேம்படுத்தல் நடக்கும்போது, இணைப்பு துண்டிக்கப்பட்டால் process SIGHUP சமிக்ஞையைப் பெற்று பாதியிலேயே நின்றுவிடும். இது dpkg-ஐ அரைகுறையாக உள்ளமைக்கப்பட்ட நிலையில் விட்டுவிடும். எனவே, tmux அல்லது screen-க்குள் மேம்படுத்தலைத் தொடங்கவும். அப்போதுதான் இணைப்பு துண்டிக்கப்பட்டாலும் process இயங்கும்; நீங்கள் மீண்டும் இணைந்து tmux attach -t upgrade கட்டளையைப் பயன்படுத்தி மேம்படுத்தலைத் தொடரலாம். மேம்படுத்தல் கருவி, port 1022-ல் ஒரு கூடுதல் SSH daemon-ஐயும் தொடங்கும். ஆனால் அது firewall-ஐத் தானாகத் திறக்காது, எனவே நீங்களே முன்கூட்டியே 1022 port-ஐத் திறந்துவிட்டு, பிறகு அதை மூடிவிடவும்.

மேம்படுத்தலுக்குப் பிறகு எனது PHP தளம் 502 பிழையைக் காட்டுகிறது. என்ன பிரச்சினை?

பதிப்பு மாறியதால் PHP FPM socket பாதை மாறிவிட்டது. Ubuntu 24.04-ல் PHP 8.3 இயங்குகிறது, 26.04-ல் PHP 8.5 இயங்குகிறது. எனவே, உங்கள் nginx vhost-ல் குறிப்பிடப்பட்டுள்ள /run/php/php8.3-fpm.sock இப்போது இல்லை. 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 செய்யவும். Apache-ல் mod_php பயன்படுத்தினால், sudo a2dismod php8.3 கட்டளையைப் பயன்படுத்தி, பின் sudo a2enmod php8.5 மற்றும் ஒரு restart செய்வதன் மூலம் இதைச் சரிசெய்யலாம்.