Paano Mag-upgrade ng Ubuntu 24.04 sa 26.04 VPS

Kailan maaaring mag-upgrade mula Ubuntu 24.04 patungong 26.04?

Maaari kang mag-upgrade mula Ubuntu 24.04 patungong 26.04 sa isang VPS kapag na-release na ang 26.04.1 point release, na nakatakda sa 27 August 2026. Bago iyon, hindi makikita ng 24.04 server ang bagong release, at sinadya iyon. Na-release 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 dahil kasama na rito ang mga bug sa installation at upgrade na natuklasan sa mga unang buwan.

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. Ang /etc/update-manager/release-upgrades ay naglalaman ng Prompt=lts sa Ubuntu Server, kaya ang iniaalok lamang ng tool ay ang susunod na long term support release, at kapag mayroon na ang .1 point release nito. Kung itatakda ang Prompt=normal, gagabayan ka naman nito sa 24.10, 25.04, at 25.10 nang sunod-sunod. 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 pagbabago.

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 ina-upgrade. Pinapalitan nito ang kernel at ang C library, at kailangan nito ng reboot upang makumpleto.

Dapat ka bang mag-upgrade?

Makakatanggap ang Ubuntu 24.04 ng standard security updates hanggang 2029, kaya walang deadline ang gumaganang production server. Mag-upgrade dahil kailangan mo ang mga 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 pakialaman ang machine na nagsisilbi sa mga customer.

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

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

Madalas na mas mabuting alternatibo ang gumawa ng bagong 26.04 VPS, i-install ang iyong stack, i-restore ang data, at saka ilipat ang DNS kapag tama na ang response nito. Maaari mong panatilihing tumatakbo ang lumang server hanggang mapatunayan ng bagong server na maayos 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 maayos na buuin ang bagong server.

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

Gumamit ng dalawang layer dahil magkakaiba ang paraan ng pag-fail ng mga ito. Sinasaklaw ng provider snapshot ang buong disk at ilang minuto lang ang kailangan para sa restore, pero kinukuha ito habang nagsusulat ang iyong mga database. Dahil dito, crash-consistent ito sa halip na application-consistent. Ang file-level backup gamit ang restic, na naka-store sa labas ng server ay nagbibigay sa iyo ng mga indibidwal na file at kopyang mananatili kahit ma-lock ang iyong account.

I-dump muna nang manu-mano ang mga database. Ang dump lamang ang backup ng database na mapagkakatiwalaan mo nang hindi ito ihihinto.

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 ay nagbibigay 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 bawat config file na itatanong sa iyo ng upgrade.

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

Hakbang 2: i-patch muna nang kumpleto 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 hindi kumpleto 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 hahadlang sa upgrade. I-release ang bawat package na 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, para mag-upgrade mula sa machine na nagpapatakbo ng code na inaakala nitong kasalukuyan nitong pinapatakbo.

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

Pagkatapos, tingnan ang available na disk space. Dina-download ng upgrader ang buong bagong package set bago ito mag-install ng anuman, at mag-a-abort ito na may mensaheng nagsasaad kung aling filesystem ang kulang sa espasyo.

df -h / /boot

Kapag mas mababa sa humigit-kumulang 5 GB ang libre sa /, dito karaniwang nagkakaroon ng problema. Kapag mas mababa sa 300 MB ang /boot, mabibigo ito sa kalaunan habang ini-install ang kernel, na may No space left on device. Karaniwang mga lumang kernel ang sanhi nito, at nililinis ng sudo apt --purge autoremove ang mga ito.

May isa pang kailangang ihinto bago magsimula: kung tumakbo ang mga awtomatikong security update habang isinasagawa ang proseso, 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

Ang do-release-upgrade ay nagdi-disable sa bawat apt source na hindi para sa Ubuntu, dahil maaaring masira ng package na ginawa para sa noble ang resolute system. Muli nitong ini-enable ang mga source na nakikilala nito at iniiwang naka-comment out ang iba. Alamin muna kung ano ang ginagamit mo bago ang tool ang magpasya 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 deb822 .sources files na may mga field na Types: at Suites:. Parehong dini-disable ang mga ito ng upgrade. Inililista ng ubuntu-security-status --thirdparty ang mga naka-install na package na walang ibinibigay na Ubuntu archive, kaya ito ang tapat na bilang ng mga idinagdag mong package. Ang anumang nasa /etc/apt/preferences.d/ ay isang pin, at ang pin na ginawa para sa noble ay patuloy na pipili ng lumang package sa bagong release.

Para sa bawat third-party repository, tiyaking may inilabas ang vendor para sa bagong codename bago ka magsimula. Nakalista ang mga suite ng Docker sa https://download.docker.com/linux/ubuntu/dists/, at naglalabas din ang ibang vendor ng kaparehong directory. Kapag nakaturo ang isang source sa suite na hindi umiiral, ito ang lalabas sa unang apt update pagkatapos ng upgrade:

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

Panatilihing disabled ang source na iyon hanggang sa maglabas ang vendor ng package. Ang pagpapalit ng codename sa isang codename na ginawa nga ng vendor ay maaaring mag-install ng mga package na naka-link sa maling system libraries.

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

Kung maputol ang connection mo habang tumatakbo ang do-release-upgrade sa isang ordinaryong login shell, makakatanggap ang process ng SIGHUP at mamamatay habang nag-u-unpack pa. Dahil dito, maaaring kalahating ma-configure ang dpkg, at maaaring mawalan ang server ng gumaganang network stack na gagamitin sana sa muling pag-connect. Sa halip, patakbuhin ito sa loob ng terminal multiplexer para manatiling tumatakbo ang process sa server kahit mawala ang client mo.

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 ikalawang 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 ligtas na awtomatikong magbukas ng firewall port nang hindi nagpapaalam. Ikaw mismo ang magbukas ng port 1022 bago magsimula, at isara ito kapag tapos ka na sa sudo ufw delete allow 1022/tcp. Tandaan na maaaring may ikalawang firewall ang provider mo sa control panel nito, sa labas ng server.

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

Hakbang 5: Sadyang sagutin ang mga prompt para sa configuration file

Nagpapakita lang ang dpkg ng prompt para sa mga file na binago mo o ng isang script. Dahil dito, bawat prompt ay para sa file na sinadya mong i-edit. Kapag pinindot mo ang enter para mawala ito, maaaring tahimik na bumalik sa default ang isang hardened 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] ?

Pindutin muna ang D sa bawat pagkakataon. Basahin kung ano ang nagbago, pagkatapos ay panatilihin ang bersyon mo gamit ang N. Naka-N na ang default, at ito ang ligtas na sagot dahil gumagana ngayon ang file mo, samantalang hindi pa tumatakbo sa machine na ito ang packaged na file.

May kapalit ang pagpapanatili sa file mo: hindi mo makukuha ang mga bagong default. I-reconcile ang mga file pagkatapos, kapag gumagana na ang server at hindi ka nagmamadali.

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. I-diff ang mga ito nang paisa-isa at kopyahin ang mahahalagang setting. Dalawang file ang nangangailangan ng higit na pag-iingat: /etc/ssh/sshd_config, dahil maaaring maputol ang session mo kapag mali ang sagot, at ang configuration ng web server mo, dahil maaaring bumagsak ang mga site kapag mali ang sagot.

Itinatanong 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 isang daemon na patuloy na gumagamit ng shared library file na nabura na sa disk, sa panahong hindi mo ito mino-monitor.

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

sudo reboot

Kapag muli na itong nag-start:

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 magpakita ang uname -r ng 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 i-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 kasabay ng 16 at hindi nito inililipat ang data mo. Gumagawa ang Debian's postgresql-common layer ng bagong walang-lamang cluster para sa bagong major version sa susunod na available na port. Kaya nananatili ang 16 sa port 5432 kasama ang lahat ng data mo, habang walang laman ang 18 sa 5433. Patuloy na kumokonekta ang application mo sa 5432 at walang mukhang mali. Dahil dito, ilang buwan pa bago ito karaniwang napapansin.

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 kasinglaki ng database. Sa halip, ginagamit ng -m upgrade ang pg_upgrade at mas mabilis ito para sa malaking database. Kapag natapos ito, basahin ang Port column: gagamitin na ng bagong cluster ang 5432 at mananatiling stopped ang luma. Isagawa mo mismo ang analyze pass, dahil walang statistics ang bagong na-load na cluster at magiging mabagal ang mga unang query.

I-test ang application laban 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 rollback option. Huwag itong i-delete sa araw ng upgrade.

MySQL 8.0 hanggang 8.4: ang inalis na option na nagpapatigil sa server

Inia-upgrade ng 26.04 ang MySQL mula 8.0 tungo sa 8.4 LTS, at may dalawang pagbabagong nakaaapekto sa mga server.

Una, mysqld ay hindi magsisimula kapag may option sa configuration nito na inalis sa bagong version. Karaniwan ang default_authentication_plugin, dahil marami sa mga mas 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 talaga makakapag-login ang account na gumagamit pa rin nito. Suriin ito habang nasa 8.0 ka pa:

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

Ilipat muna ang lahat ng 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 makagamit ng 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 takdang petsa ng pagtatapos, dahil tuluyan nang inaalis ang plugin.

PHP 8.3 hanggang 8.5: ang iyong mga vhost ay nakaturo 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 version, at walang awtomatikong nagre-rewrite ng configuration ng web server. Ang nginx vhost na may fastcgi_pass unix:/run/php/php8.3-fpm.sock; ay nakaturo ngayon sa socket na walang prosesong gumagawa, kaya 502 ang ibinabalik sa bawat PHP request at ganito ang nakalagay sa 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 may mod_php, iba ang sintomas: hindi talaga magsisimula ang Apache, at iniuulat ng sudo apache2ctl -t na hindi nito ma-load ang libphp8.3.so dahil wala ang file. Ang naka-enable na module ay symlink sa package na wala na.

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

Kung ginawa mo ang server gamit ang LAMP stack sa Ubuntu 24.04, mahalagang suriin ang dalawang path na iyon, dahil nag-iiwan ang guide ng pangalan ng module at socket na may version.

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

Kailangang suriin nang hiwalay ang mga certificate. Patakbuhin ang sudo certbot renew --dry-run pagkatapos ng upgrade. Sinusubukan nito ang buong renewal path, kabilang ang reload hook ng web server, nang hindi ina-update ang aktuwal na certificate. Kung ang hook ay tumatawag sa service name o binary na nagbago, makikita agad ang failure dito sa halip na tahimik na mangyari makalipas ang 60 araw. Sinasaklaw ng Certbot gamit ang Let's Encrypt sa nginx kung ano dapat ang hitsura ng mga hook na iyon.

SSH: ang failure na nagtatapos sa session na ginagamit mo

Sa sshd_config prompt madalas nalala-lock out ng mga user ang sarili nila. Kapag sinagot mo ito ng Y, ini-install nito ang file ng maintainer at binubura ang iyong PermitRootLogin, PasswordAuthentication, AllowUsers, Port, pati ang bawat iba pang line na idinagdag mo. Kung custom port lang ang pinapayagan ng firewall mo at nakikinig sa port 22 ang packaged config, tatanggihan ang susunod na connection at ang session na ginagamit mo ang magiging huli mong session.

Pigilan ito bago ka mag-upgrade. Sa 24.04, nagsisimula ang /etc/ssh/sshd_config sa Include /etc/ssh/sshd_config.d/*.conf, at ginagamit ng OpenSSH ang unang value na nabasa nito para sa bawat setting. Kaya mauuna ang drop-in na naka-include sa itaas 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 file sa /etc/ssh/sshd_config ang pagmamay-ari mo, hindi na mahalaga ang prompt na iyon: alinman sa dalawang sagot ang piliin mo, mananatili ang iyong mga setting dahil nasa ibang file ang mga ito.

May isa pang kailangang tingnan kapag custom port ang ginagamit, dahil maaaring wala ito sa lugar na inaakala mo:

systemctl is-enabled ssh.socket

Kung enabled ang output nito, systemd ang namamahala sa listening port at hindi ginagamit ang Port line sa sshd_config. Gumagamit na ang Ubuntu ng socket activation para sa sshd mula pa noong 22.10. Ito ang dahilan kung bakit mukhang walang epekto ang pag-edit sa Port 2222. Sa socket unit ito itakda gamit ang sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Kailangang walang laman ang ListenStream=. Nililinis nito ang inherited value. Kung wala ito, makikinig ang socket sa 22 pati 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)'

Magbukas ng pangalawang terminal sa sarili mong machine at mag-log in ulit. Ang gumaganang shell sa pangalawang terminal na iyon ang tanging sapat na patunay. Panatilihing bukas ang unang session hanggang makapasok ka rito. Ipinapakita sa Pag-hardening ng SSH sa VPS ang mga setting na dapat panatilihin sa drop-in na iyon.

Kung huli na ang lahat, nagbibigay ang web console ng iyong provider 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 ang dahilan kung bakit dapat mong subukan ang console access bago ang upgrade, hindi habang isinasagawa ito.

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 lang ng setting na iyon ang susunod na long term support release kapag available 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. Hanggang sa araw na iyon, walang nakikitang bagong release ang 24.04 server. Huwag baguhin ang setting; sa halip, iwan ito sa kasalukuyang halaga. Kung lilipat ka sa Prompt=normal, dadaan ang upgrade sa mga interim release.

Kailangan ko bang i-reboot ang server para matapos 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. Humihiling ang do-release-upgrade ng reboot sa dulo ng proseso. Kung hahayaan mong tumakbo ang machine hanggang sa "later", magpapatakbo ito ng halo ng dalawang release. Pagbalik nito, tingnan ang uname -r para sa bagong kernel at ang systemctl --failed para sa mga service na hindi nakabalik.

Dapat ba akong mag-upgrade in place o gumawa ng bagong 26.04 server?

Gumawa ng bagong server kung maaari. Sa bagong VPS, mai-install mo ang stack, maibabalik ang data, at masusuri ang lahat habang patuloy na nagseserve ng traffic ang lumang server. Dahil dito, DNS change lang ang rollback sa halip na restore mula sa backup. Mag-upgrade in place kapag may state ang server na mahirap ilipat, kapag per machine ang singil ng provider, o kapag mayroon kang snapshot at napatunayang console access. Subok na ang in-place na proseso, pero one-way door ito habang tumatakbo sa loob ng isang oras.

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

Sa isang plain login shell, tumatanggap ang process ng SIGHUP at namamatay sa kalagitnaan ng proseso. Dahil dito, maaaring maiwang half-configured 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 ikalawang paraan ng pag-access. Hindi nito awtomatikong binubuksan ang firewall para sa port na iyon, kaya ikaw mismo ang mag-allow sa 1022 bago ang upgrade at isara ito pagkatapos.

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

Nagbago ang PHP FPM socket path kasabay ng bersyon. Gumagamit ang Ubuntu 24.04 ng PHP 8.3, samantalang PHP 8.5 ang ginagamit ng 26.04. Dahil dito, wala na ang /run/php/php8.3-fpm.sock habang iyon pa rin ang tinutukoy ng nginx vhost. Makikita sa 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 ayos ay sudo a2dismod php8.3, kasunod ang sudo a2enmod php8.5 at isang restart.