Paano I-upgrade ang Ubuntu 24.04 sa 26.04 sa VPS

Kailan maaaring i-upgrade ang Ubuntu 24.04 sa 26.04?

Maaari mong i-upgrade ang Ubuntu 24.04 sa 26.04 sa isang VPS kapag na-release na ang 26.04.1 point release, na nakatakdang ilabas sa 27 August 2026. Hanggang sa panahong iyon, hindi makikita ng 24.04 server ang bagong release, at sinadya iyon. Inilabas ang Ubuntu 26.04 LTS (Resolute Raccoon) noong 23 April 2026, pero binubuksan lamang ng Canonical ang LTS-to-LTS upgrade path sa unang point release. Isinasama kasi sa release na iyon ang mga bug sa installation at upgrade na natuklasan sa mga unang buwan. Kung bago sa iyo ang numbering, ang 26.04.1 ay hindi ibang Ubuntu kundi ang parehong 26.04 na may apat na buwang mga fix na isinama sa media, kaya iyon ang unang version na iaalok ng Canonical sa isang kasalukuyang server.

Patakbuhin ang check sa isang 24.04 box sa unang bahagi ng August 2026 at makikita mo ito:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Hindi ito error sa iyong server. Naglalaman ang /etc/update-manager/release-upgrades ng Prompt=lts sa Ubuntu Server. Ibig sabihin, ang tool ay nag-aalok lamang ng susunod na long term support release, at ginagawa lamang ito kapag mayroon na ang .1 point release nito. Kung itatakda mo ang Prompt=normal, dadaan ka naman sa 24.10, 25.04, at 25.10 nang magkakasunod. Mga interim release ang mga ito at lahat ay umabot na sa end of life. Iwan itong nakatakda sa lts at maghintay. Maaaring magbago ang mga petsa sa schedule ng Canonical, kaya suriin itong muli kung lumipas ang araw nang walang lumitaw na bagong release.

Ang bawat command sa ibaba ay ikaw mismo ang magpapatakbo sa sarili mong server, ayon sa ibinigay na pagkakasunod-sunod. Hindi maaaring magsagawa ng rehearsal ng release upgrade sa mismong machine na iyong ina-upgrade. Pinapalitan nito ang kernel at C library, at kailangan ng reboot upang makumpleto.

Dapat ka bang mag-upgrade?

Makakatanggap ang Ubuntu 24.04 ng mga standard security update hanggang 2029, kaya walang deadline ang gumaganang production server. Mag-upgrade dahil kailangan mo ang mga feature na kasama sa 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2, o ang 7.0 kernel. Hindi sapat na dahilan ang “tumaas ang numero” para galawin ang machine na nagsisilbi sa mga customer.

Huwag mag-upgrade in place kapag totoo ang alinman sa mga ito:

• Hindi mo pa kailanman nabuksan ang console ng provider mo (VNC o serial) at nakapag-login dito. Ang console na iyon ang tanging paraan para makabalik sa server kung masira ang SSH, at huli na kapag nalaman mong hindi ito gumagana habang naka-lock out ka.
• Hindi mo kayang magkaroon ng isang oras na downtime at wala kang rollback.
• Nakadepende ang stack mo sa third-party repository na hindi pa naglalabas ng package para sa resolute.
• Mano-manong binuo ang server mahigit dalawang taon na ang nakalipas, at walang nakakaalam kung ano ang naka-install dito.

Mas mainam madalas ang alternatibo: gumawa ng bagong 26.04 VPS, i-install ang stack mo at i-restore ang data, pagkatapos ay ilipat ang DNS kapag tama na ang response nito. Panatilihin mong tumatakbo ang lumang server hanggang mapatunayan ng bagong server na maaasahan ito. Sa ganitong paraan, DNS change ang rollback sa halip na restore. Kung ito ang pipiliin mo, magsimula sa unang sampung minuto sa bagong VPS at ayusin nang maayos ang bagong server.

Hakbang 1: gumawa ng backup na maaari mong i-restore

Gumamit ng dalawang layer dahil magkaiba ang paraan ng pag-fail ng mga ito. Sinasaklaw ng provider snapshot ang buong disk at nare-restore ito sa loob ng ilang minuto, pero ginagawa ito habang nagsusulat ang iyong mga database. Kaya crash consistent ito sa halip na application consistent. Sa file-level backup gamit ang restic, na naka-store sa labas ng server, makakakuha ka ng mga indibidwal na file at kopyang mananatili kahit ma-lock ang iyong account.

Manu-manong i-dump muna ang mga database. Ang dump lang ang database backup na mapagkakatiwalaan mo nang hindi ihihinto ang database.

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

Nagbibigay ang --single-transaction ng consistent dump para lamang sa mga InnoDB table. Kailangang ihinto ang database para sa mga MyISAM table. Ang /etc tarball ang aktuwal mong gagamitin dahil naglalaman ito ng lahat ng config file na itatanong sa iyo ng upgrade.

Ang backup na hindi mo pa kailanman na-restore ay hula lamang. Mag-extract ngayon ng isang file mula rito, bago mo ito kailanganin sa ilalim ng pressure.

Hakbang 2: ganap na i-patch muna ang 24.04

Tumangging tumakbo ang do-release-upgrade sa system na may sirang package state, at mas mahirap basahin ang bawat kasunod na failure kapag kalahati pa lamang ang patch ng 24.04.

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

Ang walang inilalabas na output ng dpkg --audit ay nangangahulugang walang package na bahagyang naka-configure. Ang walang inilalabas na output ng apt-mark showhold ay nangangahulugang walang package na naka-pin sa bersyong haharang sa upgrade. I-release ang anumang inililista nito gamit ang sudo apt-mark unhold at ang pangalan ng package, o tanggapin na may dahilan ang hold at huminto muna rito.

Mag-reboot kung nagbago ang kernel, upang mag-upgrade ka mula sa machine na tumatakbo gamit ang code na inaakala nitong ginagamit nito.

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

Pagkatapos, tingnan ang disk space. Ida-download ng upgrader ang buong bagong package set bago ito mag-install ng anuman, at mag-a-abort ito habang naglalabas ng mensaheng nagbabanggit sa filesystem kung kulang ang espasyo.

df -h / /boot

Kapag mas mababa sa humigit-kumulang 5 GB ang libreng espasyo sa /, dito karaniwang nagkakaproblema. Kapag mas mababa sa 300 MB ang /boot, mabibigo ito sa bandang huli, habang ini-install ang kernel, kasama ang No space left on device. Karaniwang lumang kernel ang sanhi nito, at nililinis ito ng sudo apt --purge autoremove.

May isa pang kailangang ihinto bago magsimula: kung tumakbo sa kalagitnaan ang awtomatikong security updates, hahawakan ng mga ito ang dpkg lock, at hihinto ang release upgrader na may Could not get lock /var/lib/dpkg/lock-frontend. Patakbuhin muna ang sudo systemctl stop unattended-upgrades, at simulan itong muli kapag tapos na.

Hakbang 3: suriin ang mga third-party repository at naka-pin na package

Idini-disable ng do-release-upgrade ang lahat ng apt source na hindi para sa Ubuntu, dahil maaaring makasira sa resolute system ang package na ginawa para sa noble. Muli nitong ie-enable ang mga source na kinikilala nito at iiwan na naka-comment out ang iba. Alamin muna kung ano ang kasalukuyan mong ginagamit bago magpasya ang tool para sa iyo.

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/

Gumagamit ang Ubuntu 24.04 ng dalawang format sa directory na iyon: ang lumang one-line .list files, at ang mga deb822 .sources files na may Types: at Suites: fields. Pareho silang dini-disable ng upgrade. Inililista ng ubuntu-security-status --thirdparty ang mga naka-install na package na walang ibinibigay na Ubuntu archive. Ito ang tapat na bilang ng mga package na idinagdag mo. Ang anumang nasa /etc/apt/preferences.d/ ay isang pin. Ang pin na isinulat para sa noble ay patuloy na pipili ng lumang package sa bagong release.

Para sa bawat third-party repository, tiyaking nag-publish ang vendor para sa bagong codename bago ka magsimula. Nakalista ang mga suite ng Docker sa https://download.docker.com/linux/ubuntu/dists/, at inilalantad ng ibang vendor ang parehong directory. Kapag itinuro ang source sa suite na hindi umiiral, ito ang lalabas sa unang apt update matapos ang upgrade:

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

Iwanang naka-disable ang source na iyon hanggang mag-publish ang vendor. Ang pagpapalit ng codename sa isang codename na talagang ginawan ng package ng vendor ang paraan para makapag-install ka ng mga package na naka-link sa maling system libraries.

Hakbang 4: patakbuhin ang upgrade sa tmux, hindi sa plain SSH shell

Kung maputol ang koneksyon habang tumatakbo ang do-release-upgrade sa plain login shell, makakatanggap ang proseso ng SIGHUP at hihinto habang ina-unpack ang mga package. Dahil dito, maaaring hindi ganap na ma-configure ang dpkg, at maaaring mawalan ang server ng gumaganang network stack na gagamitin para muling kumonekta. Sa halip, patakbuhin ito sa loob ng terminal multiplexer upang manatiling tumatakbo ang proseso sa server kapag nawala ang koneksyon ng client.

sudo apt install -y tmux
tmux new -s upgrade

Sa loob ng session na iyon:

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

Nagsisimula ang upgrader ng pangalawang SSH daemon sa port 1022 bago ito magbago ng anuman, at ipinapaalam nito iyon:

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.

Hindi nito binubuksan ang firewall para sa port na iyon dahil hindi magandang sorpresa ang awtomatikong pagbubukas ng firewall nang walang pahintulot. Ikaw mismo ang magbukas ng 1022 bago magsimula, at isara ito kapag tapos ka na sa sudo ufw delete allow 1022/tcp. Tandaan na maaaring may pangalawang firewall ang iyong provider sa control panel nito, sa labas ng server.

Kung maputol pa rin ang koneksyon, mag-log in muli at patakbuhin ang tmux attach -t upgrade. Nagpatuloy sa pagtakbo ang upgrade habang wala ka.

Hakbang 5: maingat na sagutin ang mga prompt para sa configuration file

Nagpapakita lang ng prompt ang dpkg para sa mga file na binago mo o ng isang script. Dahil dito, ang bawat prompt ay para sa file na sinadya mong i-edit. Kapag pinindot mo ang enter para mawala ang prompt, maaaring tahimik na bumalik ang hardened server sa mga default na setting.

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] ?

Pindutin muna ang D sa bawat pagkakataon. Basahin kung ano ang nagbago, saka panatilihin ang bersyon mo gamit ang N. Nakatakda na ang default sa N, at ito ang ligtas na sagot dahil gumagana ngayon ang file mo, samantalang hindi pa kailanman tumakbo sa machine na ito ang file mula sa package.

May kapalit ang pagpapanatili sa file mo: hindi mo makukuha ang mga bagong default. Ihambing at pagsamahin ang mga pagbabago pagkatapos, kapag gumagana na ulit ang server at wala ka nang time pressure.

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

Ang bawat file na inililista ay bersyon ng maintainer na naka-save sa tabi ng file mo. Ihambing ang mga ito nang paisa-isa at kopyahin ang mahahalagang setting. Dalawang bagay ang nangangailangan ng masusing pag-iingat: /etc/ssh/sshd_config, dahil magwawakas ang session mo kapag mali ang sagot, at ang configuration ng web server mo, dahil mawawala ang mga site kapag mali ang sagot.

Itatanong din ng upgrade kung aling mga serbisyo ang ire-restart, gamit ang needrestart. Tanggapin ang buong listahan. Maaaring mag-crash sa isang susunod na request ang daemon na patuloy na gumagamit ng shared library file na nabura na sa disk, kahit hindi mo ito mino-monitor sa oras na iyon.

Hakbang 6: i-reboot, pagkatapos ay suriin ang machine

sudo reboot

Kapag bumalik na ito:

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

Dapat i-report ng lsb_release -a ang Release: 26.04 at Codename: resolute. Dapat ipakita ng uname -r ang 7.0 kernel. Dapat maglista ang systemctl --failed ng zero units. Anumang mailista nito ang susunod mong kailangang ayusin. Kinukuha ng huling apt update ang mga update na inilabas mula nang ma-build ang release images.

PostgreSQL 16 hanggang 18: ang cluster na tahimik na naiiwan

Kasama sa Ubuntu 24.04 ang PostgreSQL 16, at kasama sa 26.04 ang PostgreSQL 18. Ini-install ng upgrade ang 18 katabi ng 16 at hindi nito inililipat ang iyong data. Gumagawa ang Debian's postgresql-common layer ng bagong walang-lamang cluster para sa bagong major version sa susunod na malayang port. Dahil dito, nananatili ang 16 sa port 5432 kasama ang lahat ng iyong data, habang walang laman ang 18 sa 5433. Patuloy na kumokonekta ang iyong application sa 5432 at walang mukhang mali. Kaya maraming nakakatuklas nito makalipas ang ilang buwan.

pg_lsclusters

Kapag dalawang cluster ang nakalista, hindi mo pa nagagawa ang migration. Gawin ito kapag maaari mong ihinto ang application:

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

I-drop muna ang walang-lamang 18 cluster, dahil hindi magsusulat ang pg_upgradecluster sa target cluster na mayroon na. Ang default na method ay nagda-dump ng 16 at nire-reload ito sa 18, kaya kailangan mo ng libreng disk space na humigit-kumulang kasinlaki ng database. Sa halip, ginagamit ng -m upgrade ang pg_upgrade, kaya mas mabilis ito sa malaking database. Kapag natapos na, basahin ang column na Port: lilipat ang bagong cluster sa 5432, at mananatiling naka-stop ang luma. Ikaw mismo ang magpatakbo ng analyze pass, dahil walang statistics ang bagong-load na cluster at magiging mabagal ang mga unang query.

Subukan ang application sa bagong cluster sa loob ng ilang araw. Pagkatapos lamang nito alisin ang luma:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Ang data directory ng lumang cluster ang pinakamabilis mong paraan para sa rollback. Huwag itong i-delete sa araw ng upgrade.

MySQL 8.0 hanggang 8.4: ang inalis na option na pumipigil sa pagsisimula ng server

Inililipat ng 26.04 ang MySQL mula 8.0 patungo sa 8.4 LTS, at may dalawang pagbabagong nakaaapekto sa mga server.

Una, tumatangging magsimula ang mysqld kapag may option sa configuration nito na inalis ng bagong version. Karaniwan ang default_authentication_plugin dahil maraming lumang guide ang nag-uutos na itakda ito. Nabibigo ang service, at direktang tinutukoy ng journalctl -u mysql -n 50 ang unknown variable. Tanggalin ang linyang iyon sa file sa ilalim ng /etc/mysql/mysql.conf.d/, pagkatapos ay sudo systemctl start mysql.

Ikalawa, hindi na naka-enable bilang default sa 8.4 ang mysql_native_password plugin, kaya hindi makakapag-log in ang account na gumagamit pa nito. Suriin ito habang nasa 8.0 ka pa:

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

Ilipat ang bawat account na nagpapakita ng mysql_native_password bago ang upgrade, pagkatapos ay i-update ang password sa application config:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Kung masyadong luma ang client library para suportahan ang caching_sha2_password, maaari mong muling i-enable ang lumang plugin sa 8.4 sa pamamagitan ng pagdaragdag ng mysql_native_password=ON sa ilalim ng [mysqld]. Ituring itong pansamantalang tulay na may itinakdang petsa ng pagtatapos dahil tuluyan nang inaalis ang plugin.

PHP 8.3 hanggang 8.5: nakaturo ang iyong vhost sa socket na wala na

May PHP 8.3 ang 24.04 at may PHP 8.5 ang 26.04. Nag-i-install ang mga package sa mga path na may bersyon, at walang awtomatikong nagre-rewrite ng configuration ng web server. Ang nginx vhost na naglalaman ng fastcgi_pass unix:/run/php/php8.3-fpm.sock; ay nakaturo na ngayon sa socket na walang prosesong gumagawa, kaya nagbabalik ng 502 ang bawat PHP request at sinasabi ng nginx error log:

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

Ituro ito sa bagong socket, i-test ang configuration, at i-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

Sa Apache na gumagamit ng mod_php, iba ang sintomas: hindi talaga magsisimula ang Apache, at nag-uulat ang sudo apache2ctl -t na hindi nito ma-load ang libphp8.3.so dahil wala ang file. Ang naka-enable na module ay symlink patungo sa package na wala na.

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

Kung binuo mo ang server gamit ang LAMP stack sa Ubuntu 24.04, sulit suriin ang dalawang path na iyon, dahil nag-iiwan ang guide ng module name at socket na may bersyon.

Hindi rin naililipat ang iyong php.ini tuning. Nasa /etc/php/8.3/ ang memory_limit, upload_max_filesize, at anumang iba pang itinakda mo, at nagsisimula ang bagong tree sa mga default. I-compare ang dalawang file at manu-manong kopyahin ang mga value. Kapag kinopya ang buong lumang file sa bago, nadadala ang 8.3 defaults sa 8.5 install. Pagkatapos, patakbuhin ang php -m at i-compare ang resulta: ang extension na naka-install bilang php8.3-redis ay nangangailangan ng php8.5- package, at kung nagmula ito sa PPA, idi-disable ng upgrader ang source na iyon kaya nawawala lang ang extension.

Kailangan ding hiwalay na suriin ang certificates. Patakbuhin ang sudo certbot renew --dry-run pagkatapos ng upgrade. Sinusubukan nito ang buong renewal path, kasama ang web server reload hook, nang hindi hinahawakan ang aktibong certificate. Kung tumatawag ang hook sa service name o binary na nagbago, mabibigo ito rito at makikita mo agad, sa halip na tahimik na mabigo pagkalipas ng 60 araw. Saklaw ng Certbot gamit ang Let's Encrypt sa nginx kung ano dapat ang hitsura ng mga hook na iyon.

SSH: ang failure na nagwawakas sa session na ginagamit mo

Ang sshd_config prompt ang lugar kung saan karaniwang naii-lock out ng mga tao ang kanilang sarili. Kapag sinagot mo ng Y, ini-install nito ang file ng maintainer, na nagtatanggal sa iyong PermitRootLogin, PasswordAuthentication, AllowUsers, Port at sa lahat ng iba pang linyang idinagdag mo. Kung custom port lang ang pinapayagan ng firewall mo at nakikinig sa 22 ang packaged config, tatanggihan ang susunod na connection, at ang session na ginagamit mo ang magiging huli mong session.

Pigilan ito bago mag-upgrade. Ang /etc/ssh/sshd_config sa 24.04 ay nagsisimula sa Include /etc/ssh/sshd_config.d/*.conf, at pinananatili ng OpenSSH ang unang value na nabasa nito para sa bawat setting. Kaya nauuna at nananaig ang drop-in na kasama sa itaas kaysa sa anumang nasa ibaba. Ilipat ang iyong mga setting sa file na hindi pagmamay-ari ng 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

Kapag wala nang iyo sa /etc/ssh/sshd_config, hindi na mahalaga ang prompt na iyon. Anuman ang sagot mo, mananatili ang iyong mga setting dahil nasa ibang file ang mga ito.

Kailangan ng custom port ng isa pang pagsusuri dahil maaaring wala ito sa lokasyong inaakala mo:

systemctl is-enabled ssh.socket

Kung mag-print ito ng enabled, systemd ang nagmamay-ari sa listening port, at binabalewala ang linyang Port sa sshd_config. Gumagamit na ang Ubuntu ng socket activation para sa sshd mula pa noong 22.10. Ito ang dahilan kung bakit tila walang epekto ang pag-edit sa Port 2222. Itakda ito sa socket unit sa halip, gamit ang sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Kinakailangan ang walang lamang ListenStream=. Nililinis nito ang minanang value. Kung wala ito, makikinig ang socket sa 22 pati na rin sa 2222. Ilapat ito gamit ang sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Pagkatapos ng upgrade, bago mo isara ang session na ginagamit mo:

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

Pagkatapos, magbukas ng pangalawang terminal sa sarili mong machine at mag-log in muli. Ang gumaganang shell sa pangalawang terminal na iyon ang tanging patunay na mahalaga. Panatilihing bukas ang unang session hanggang makapasok ka sa pangalawa. Tinatalakay ng Pag-hardening ng SSH sa isang VPS ang mga setting na dapat panatilihin sa drop-in na iyon.

Kung huli na, nagbibigay ang web console ng provider mo ng login na hindi gumagamit ng SSH. Mag-log in doon, ayusin ang config, patakbuhin ang sudo sshd -t, at i-restart ang service. Iyan mismo ang dahilan kung bakit dapat mong subukan ang console access bago mag-upgrade, hindi habang isinasagawa na ang upgrade.

FAQ

Bakit sinasabi ng do-release-upgrade na “No new release found” sa Ubuntu 24.04?

Dahil naglalaman ang /etc/update-manager/release-upgrades ng Prompt=lts sa Ubuntu Server, at iniaalok ng setting na iyon ang susunod na long term support release kapag mayroon na ang unang point release nito. Inilabas ang Ubuntu 26.04 LTS noong 23 April 2026, at nakatakdang ilabas ang 26.04.1 sa 27 August 2026. Bago ang petsang iyon, walang nakikitang bagong release ang 24.04 server. Huwag baguhin ang setting. Kung lilipat ka sa Prompt=normal, dadaan ka sa mga interim release.

Kailangan ko bang i-reboot ang server para makumpleto ang upgrade?

Oo. Nag-i-install ang upgrade ng bagong kernel, bagong C library, at bagong init system. Patuloy na ginagamit ng tumatakbong system ang mga lumang bersyon hanggang sa mag-restart ito. Humihingi ang do-release-upgrade ng reboot sa dulo. Kung patuloy na tumatakbo ang machine hanggang “mamaya,” gumagamit ito ng pinaghalong bahagi mula sa dalawang release. Pagbalik nito, suriin ang uname -r para sa bagong kernel at ang systemctl --failed para sa mga service na hindi nagsimula muli.

Mag-u-upgrade ba ako in place o gagawa ng bagong 26.04 server?

Gumawa ng bagong server kung maaari. Sa bagong VPS, mai-install mo ang stack, mare-restore ang data, at masusubukan ang lahat habang patuloy na nagsi-serve ng traffic ang lumang server. Dahil dito, DNS change lang ang rollback sa halip na pag-restore mula sa backup. Mag-upgrade in place kapag may state ang server na mahirap ilipat, kapag naniningil ang provider bawat machine, o kapag mayroon kang snapshot at napatunayang console access. Subok na ang in-place na proseso, pero hindi na ito madaling balikan habang tumatakbo ang upgrade.

Ano ang mangyayari kung maputol ang SSH connection ko habang nag-a-upgrade?

Sa karaniwang login shell, tumatanggap ang process ng SIGHUP at namamatay sa kalagitnaan ng upgrade. Dahil dito, maaaring maiwang kalahating naka-configure ang dpkg. Simulan ito sa loob ng tmux o screen upang manatiling tumatakbo ang process. Pagkatapos mong kumonekta muli, patakbuhin ang tmux attach -t upgrade upang ipagpatuloy ito. Nagsisimula rin ang upgrader ng ekstrang SSH daemon sa port 1022 bilang karagdagang paraan ng pag-access. Hindi nito awtomatikong binubuksan ang firewall para sa port na iyon, kaya payagan muna ang 1022 at isara ito pagkatapos.

Nagbabalik ng 502 ang PHP site ko matapos ang upgrade. Ano ang nasira?

Nagbago ang path ng PHP FPM socket kasabay ng bersyon. Gumagamit ang Ubuntu 24.04 ng PHP 8.3, samantalang PHP 8.5 ang gamit ng 26.04. Dahil dito, wala na ang /run/php/php8.3-fpm.sock habang iyon pa rin ang tinutukoy ng nginx vhost. Ipinapakita ng nginx error log ang connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). I-update ang fastcgi_pass upang gamitin ang 8.5 socket, patakbuhin ang sudo nginx -t, at pagkatapos ay i-reload ang nginx. Sa Apache na may mod_php, ang katumbas na pag-aayos ay sudo a2dismod php8.3, kasunod ang sudo a2enmod php8.5 at pag-restart.