Cara Naik Taraf Ubuntu 24.04 ke 26.04 di VPS

Bilakah anda boleh menaik taraf Ubuntu 24.04 kepada 26.04?

Anda boleh menaik taraf Ubuntu 24.04 kepada 26.04 pada VPS sebaik sahaja point release 26.04.1 dilancarkan, yang dijadualkan pada 27 Ogos 2026. Sehingga tarikh tersebut, pelayan 24.04 tidak akan mengesan keluaran baharu tersebut, secara sengaja. Ubuntu 26.04 LTS (Resolute Raccoon) telah dikeluarkan pada 23 April 2026, namun Canonical hanya membuka laluan naik taraf LTS ke LTS pada point release pertama, kerana keluaran tersebut merangkumi pepijat pemasangan dan naik taraf yang ditemui dalam bulan-bulan awal.

Jalankan semakan pada mesin 24.04 pada awal Ogos 2026 dan anda akan mendapat hasil ini:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Itu bukan ralat pada pelayan anda. /etc/update-manager/release-upgrades mengandungi Prompt=lts pada Ubuntu Server, yang bermaksud alat tersebut hanya menawarkan keluaran sokongan jangka panjang (LTS) seterusnya, dan hanya selepas point release .1 wujud. Menetapkan Prompt=normal sebaliknya akan membawa anda melalui 24.10, 25.04 dan 25.10 secara bergilir, iaitu keluaran interim yang kesemuanya telah mencapai penghujung hayat (end of life). Biarkan ia pada lts dan tunggu. Tarikh pada jadual Canonical boleh berubah, jadi semak semula jika tarikh tersebut berlalu tanpa sebarang perubahan.

Setiap arahan di bawah perlu dijalankan sendiri oleh anda, pada pelayan anda sendiri, mengikut urutan yang diberikan. Naik taraf keluaran tidak boleh diuji (rehearse) pada mesin yang sedang anda naik taraf. Ia menggantikan kernel dan pustaka C, serta memerlukan but semula (reboot) untuk diselesaikan.

Adakah anda perlu melakukan naik taraf?

Ubuntu 24.04 menerima kemas kini keselamatan standard sehingga tahun 2029, jadi pelayan pengeluaran yang berfungsi tidak mempunyai tarikh akhir. Lakukan naik taraf kerana anda mahukan sesuatu yang dibawa oleh 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 atau kernel 7.0. "Nombor versi meningkat" bukanlah alasan untuk menyentuh mesin yang sedang melayani pelanggan.

Jangan lakukan naik taraf secara terus (in-place) apabila mana-mana perkara berikut benar:

• Anda tidak pernah membuka konsol pembekal anda (VNC atau bersiri) dan log masuk melaluinya. Konsol tersebut adalah satu-satunya cara untuk kembali ke dalam pelayan jika SSH terputus, dan mengetahui ia tidak berfungsi semasa anda terkunci keluar adalah sudah terlambat.
• Anda tidak mampu menanggung satu jam waktu henti (downtime) dan tidak mempunyai cara untuk kembali ke keadaan asal (rollback).
• Stak perisian anda bergantung pada repositori pihak ketiga yang belum menerbitkan pakej untuk resolute lagi.
• Pelayan tersebut dibina secara manual selama lebih dua tahun dan tiada sesiapa yang tahu apa yang terkandung di dalamnya.

Alternatifnya sering kali lebih baik: bina VPS 26.04 yang baharu, pasang stak anda dan pulihkan data, kemudian tukar DNS sebaik sahaja ia menjawab dengan betul. Anda mengekalkan pelayan lama sehingga pelayan baharu terbukti stabil, dan proses kembali ke keadaan asal hanyalah satu perubahan DNS dan bukannya pemulihan sistem. Jika anda memilih cara ini, mulakan dengan sepuluh minit pertama pada VPS baharu dan bina mesin baharu tersebut dengan betul.

Langkah 1: ambil sandaran yang boleh dipulihkan

Gunakan dua lapisan, kerana kedua-duanya gagal dengan cara yang berbeza. Snapshot penyedia meliputi keseluruhan cakera dan dipulihkan dalam beberapa minit, namun ia diambil semasa pangkalan data anda sedang menulis, jadi ia bersifat crash consistent dan bukannya application consistent. Sandaran peringkat fail dengan restic, disimpan di luar pelayan memberikan anda fail tunggal dan salinan yang terselamat sekiranya akaun anda dikunci.

Lakukan dump pangkalan data secara manual terlebih dahulu. Dump adalah satu-satunya sandaran pangkalan data yang boleh dipercayai tanpa perlu menghentikannya.

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 memberikan dump yang konsisten hanya untuk jadual InnoDB. Jadual MyISAM memerlukan pangkalan data dihentikan. Tarball /etc adalah yang akan anda gunakan sebenarnya, kerana ia menyimpan setiap fail konfigurasi yang akan ditanya semasa proses naik taraf nanti.

Sandaran yang tidak pernah anda pulihkan hanyalah satu andaian. Ambil satu fail daripadanya sekarang, sebelum anda memerlukannya dalam keadaan terdesak.

Langkah 2: tampal 24.04 sepenuhnya terlebih dahulu

do-release-upgrade enggan berjalan pada sistem dengan keadaan pakej yang rosak, dan 24.04 yang separuh ditampal menjadikan setiap kegagalan kemudian lebih sukar untuk dibaca.

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

dpkg --audit jika tidak mencetak apa-apa, bermakna tiada pakej yang separuh dikonfigurasikan. apt-mark showhold jika tidak mencetak apa-apa, bermakna tiada pakej yang dipinkan pada versi yang akan menyekat naik taraf. Lepaskan mana-mana pakej yang disenaraikan dengan sudo apt-mark unhold dan nama pakej tersebut, atau terima hakikat bahawa penahanan itu wujud atas sebab tertentu dan berhenti di sini.

But semula jika kernel berubah, supaya anda menaik taraf daripada mesin yang menjalankan kod yang ia fikir sedang dijalankan.

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

Kemudian periksa ruang cakera. Pemuat naik taraf memuat turun keseluruhan set pakej baharu sebelum ia memasang apa-apa, dan ia akan membatalkan proses dengan mesej yang menamakan sistem fail jika ruang tidak mencukupi.

df -h / /boot

Di bawah kira-kira 5 GB ruang kosong pada / adalah tahap di mana proses ini akan bermasalah. /boot di bawah 300 MB akan gagal kemudian, semasa pemasangan kernel, dengan No space left on device. Kernel lama biasanya menjadi punca, dan sudo apt --purge autoremove akan membersihkannya.

Satu lagi perkara untuk dihentikan sebelum anda bermula: jika kemas kini keselamatan automatik berjalan di tengah-tengah proses, ia akan memegang kunci dpkg, dan pemuat naik taraf keluaran akan berhenti dengan Could not get lock /var/lib/dpkg/lock-frontend. Jalankan sudo systemctl stop unattended-upgrades terlebih dahulu dan mulakannya semula apabila anda selesai.

Langkah 3: semak repositori pihak ketiga dan pakej yang dipinkan

do-release-upgrade melumpuhkan setiap sumber apt yang bukan daripada Ubuntu, kerana pakej yang dibina untuk noble boleh merosakkan sistem resolute. Ia mengaktifkan semula sumber yang dikenalinya selepas itu dan membiarkan yang lain dalam keadaan dikomen. Ketahui apa yang anda bawa sebelum alat tersebut membuat keputusan bagi pihak anda.

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 menggunakan dua format dalam direktori tersebut: format satu baris lama fail .list, dan fail .sources deb822 dengan medan Types: dan Suites:. Kedua-duanya dilumpuhkan oleh proses naik taraf. ubuntu-security-status --thirdparty menyenaraikan pakej terpasang yang tidak disediakan oleh mana-mana arkib Ubuntu, yang merupakan jumlah sebenar apa yang telah anda tambah. Apa-apa sahaja dalam /etc/apt/preferences.d/ ialah pin, dan pin yang ditulis untuk noble akan terus memilih pakej lama pada keluaran baharu.

Bagi setiap repositori pihak ketiga, sahkan vendor telah menerbitkan pakej untuk kod nama baharu sebelum anda bermula. Suite Docker disenaraikan di https://download.docker.com/linux/ubuntu/dists/, dan vendor lain juga mendedahkan direktori yang sama. Sumber yang menghala ke suite yang tidak wujud akan memberikan ralat ini pada apt update pertama selepas naik taraf:

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

Biarkan sumber tersebut dilumpuhkan sehingga vendor menerbitkannya. Menyunting kod nama kepada kod yang dibina oleh vendor adalah cara anda memasang pakej yang dipautkan dengan pustaka sistem yang salah.

Langkah 4: jalankan naik taraf dalam tmux, bukan dalam shell SSH biasa

Jika sambungan anda terputus semasa do-release-upgrade berjalan dalam shell log masuk biasa, proses tersebut akan menerima SIGHUP dan terhenti di pertengahan proses nyahpampat. Ini menyebabkan dpkg berada dalam keadaan separuh konfigurasi, dan pelayan mungkin tidak lagi mempunyai network stack yang berfungsi untuk anda menyambung semula. Jalankan proses tersebut di dalam terminal multiplexer supaya proses kekal hidup pada pelayan apabila klien anda terputus.

sudo apt install -y tmux
tmux new -s upgrade

Di dalam sesi tersebut:

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

Program naik taraf akan memulakan daemon SSH kedua pada port 1022 sebelum ia membuat sebarang perubahan, dan ia akan memaklumkan perkara tersebut:

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.

Ia tidak membuka firewall anda untuk port tersebut, kerana membuka lubang pada firewall tanpa kebenaran adalah tindakan yang tidak wajar. Buka port 1022 sendiri sebelum anda bermula, dan tutup port tersebut apabila anda selesai dengan sudo ufw delete allow 1022/tcp. Ingat bahawa pembekal anda mungkin menjalankan firewall kedua dalam panel kawalan mereka, di luar pelayan.

Jika sambungan terputus juga, log masuk semula dan jalankan tmux attach -t upgrade. Proses naik taraf tetap berjalan semasa anda tiada.

Langkah 5: jawab gesaan fail konfigurasi dengan teliti

dpkg hanya akan memaparkan gesaan untuk fail yang telah anda atau skrip ubah. Oleh itu, setiap gesaan mewakili fail yang anda edit dengan sengaja, dan menekan enter untuk melangkau gesaan tersebut adalah cara pelayan yang diperkukuh (hardened) berubah secara senyap kepada konfigurasi lalai.

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

Tekan D terlebih dahulu, setiap kali gesaan muncul. Baca perubahan yang berlaku, kemudian kekalkan versi anda dengan N. Pilihan lalai sudah pun ditetapkan kepada N, iaitu jawapan yang selamat, kerana fail anda berfungsi pada masa ini manakala fail daripada pakej belum pernah dijalankan pada mesin ini.

Mengekalkan fail anda mempunyai kos: anda tidak akan mendapat tetapan lalai yang baharu. Lakukan penyelarasan selepas itu, sebaik sahaja sistem kembali beroperasi dan anda tidak berada di bawah tekanan masa.

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

Setiap fail yang disenaraikan adalah versi penyelenggara, yang disimpan bersebelahan dengan fail anda. Bandingkan perbezaan (diff) satu demi satu dan salin tetapan yang penting. Dua fail memerlukan perhatian khusus: /etc/ssh/sshd_config, kerana jawapan yang salah akan menamatkan sesi anda, dan konfigurasi pelayan web anda, kerana jawapan yang salah akan menyebabkan laman web tidak dapat diakses.

Proses naik taraf juga akan bertanya servis mana yang perlu dimulakan semula, melalui needrestart. Terima senarai penuh tersebut. Daemon yang masih berjalan dengan fail pustaka kongsi (shared library) yang telah dipadam daripada cakera akan terhenti (crash) pada permintaan akan datang, pada masa anda tidak memantaunya.

Langkah 6: but semula, kemudian periksa mesin

sudo reboot

Apabila ia kembali aktif:

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 sepatutnya melaporkan Release: 26.04 dan Codename: resolute. uname -r sepatutnya menunjukkan kernel 7.0. systemctl --failed sepatutnya menyenaraikan sifar unit, dan apa sahaja yang disenaraikannya adalah tugas anda yang seterusnya. apt update terakhir menarik kemas kini yang diterbitkan sejak imej keluaran dibina.

PostgreSQL 16 ke 18: kluster yang kekal di belakang secara senyap

Ubuntu 24.04 membekalkan PostgreSQL 16 dan 26.04 membekalkan PostgreSQL 18. Naik taraf ini memasang versi 18 di samping versi 16 dan tidak memindahkan data anda. Lapisan postgresql-common Debian mencipta kluster kosong baharu untuk versi major baharu pada port bebas seterusnya, jadi versi 16 kekal pada port 5432 dengan semua data anda manakala versi 18 berada dalam keadaan kosong pada port 5433. Aplikasi anda terus berhubung dengan port 5432 dan tiada apa-apa yang kelihatan bermasalah, itulah sebabnya pengguna menyedari perkara ini selepas beberapa bulan.

pg_lsclusters

Dua kluster yang disenaraikan bermakna anda belum melakukan migrasi. Lakukan migrasi apabila anda boleh menghentikan aplikasi:

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

Gugurkan kluster 18 yang kosong terlebih dahulu, kerana pg_upgradecluster tidak akan menulis ke dalam kluster sasaran yang sudah wujud. Kaedah lalai melakukan dump pada versi 16 dan memuatkannya semula ke dalam versi 18, jadi anda memerlukan ruang cakera kosong yang lebih kurang sama saiz dengan pangkalan data tersebut. -m upgrade menggunakan pg_upgrade sebagai ganti dan jauh lebih pantas untuk pangkalan data yang besar. Apabila proses selesai, baca lajur Port: kluster baharu akan mengambil alih port 5432 dan kluster lama akan ditinggalkan dalam keadaan berhenti. Jalankan proses analyze sendiri, kerana kluster yang baru dimuatkan tidak mempunyai statistik dan pertanyaan awal akan menjadi perlahan.

Uji aplikasi terhadap kluster baharu selama beberapa hari. Hanya selepas itu, buang kluster lama:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Direktori data kluster lama adalah cara rollback paling pantas yang anda miliki. Jangan padamkannya pada hari naik taraf.

MySQL 8.0 ke 8.4: pilihan yang dibuang yang menghentikan pelayan

26.04 menukar MySQL daripada 8.0 kepada 8.4 LTS, dan dua perubahan akan menjejaskan pelayan.

Pertama, mysqld enggan bermula apabila konfigurasi mengandungi pilihan yang telah dibuang dalam versi baharu. default_authentication_plugin adalah pilihan yang biasa ditemui, kerana banyak panduan lama mengarahkan anda untuk menetapkannya. Servis gagal bermula, dan journalctl -u mysql -n 50 menamakan pemboleh ubah yang tidak dikenali itu secara terus. Padam baris tersebut daripada fail di bawah /etc/mysql/mysql.conf.d/, kemudian sudo systemctl start mysql.

Kedua, pemalam mysql_native_password tidak lagi diaktifkan secara lalai dalam 8.4, jadi akaun yang masih menggunakannya tidak boleh log masuk langsung. Semak semasa anda masih berada pada 8.0:

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

Tukar setiap akaun yang menunjukkan mysql_native_password sebelum naik taraf, kemudian kemas kini kata laluan dalam konfigurasi aplikasi anda:

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

Jika pustaka klien terlalu lama untuk menyokong caching_sha2_password, anda boleh mengaktifkan semula pemalam lama tersebut dalam 8.4 dengan menambah mysql_native_password=ON di bawah [mysqld]. Anggap ini sebagai langkah sementara dengan tarikh tamat, kerana pemalam tersebut akan dibuang sepenuhnya pada masa hadapan.

PHP 8.3 ke 8.5: vhost anda menghala ke soket yang telah tiada

24.04 membawakan PHP 8.3 dan 26.04 membawakan PHP 8.5. Pakej dipasang ke dalam laluan berversi dan tiada apa-apa yang menulis semula konfigurasi pelayan web anda. Sebuah vhost nginx yang memegang fastcgi_pass unix:/run/php/php8.3-fpm.sock; kini menghala ke soket yang tidak dicipta oleh sebarang proses, jadi setiap permintaan PHP mengembalikan 502 dan log ralat nginx menyatakan:

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

Halakan ia ke soket baharu, uji konfigurasi, dan muat semula:

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

Pada Apache dengan mod_php, simptomnya berbeza: Apache tidak akan bermula langsung, dan sudo apache2ctl -t melaporkan bahawa ia tidak dapat memuatkan libphp8.3.so kerana fail tersebut tidak wujud. Modul yang didayakan merupakan symlink kepada pakej yang telah tiada.

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

Jika anda membina pelayan tersebut daripada a LAMP stack on Ubuntu 24.04, kedua-dua laluan tersebut perlu diperiksa, memandangkan panduan itu meninggalkan anda dengan nama modul berversi dan soket berversi.

Penalaan php.ini anda juga tidak berpindah. memory_limit, upload_max_filesize dan apa-apa sahaja yang anda tetapkan berada dalam /etc/php/8.3/, dan pepohon baharu bermula daripada tetapan lalai. Lakukan diff pada kedua-dua fail dan salin nilai tersebut secara manual. Menyalin keseluruhan fail lama ke atas fail baharu akan membawa tetapan lalai 8.3 ke dalam pemasangan 8.5. Kemudian jalankan php -m dan bandingkan: sambungan yang dipasang sebagai php8.3-redis memerlukan pakej php8.5- miliknya, dan jika ia datang daripada PPA, penaik taraf telah melumpuhkan sumber tersebut dan sambungan itu hilang begitu sahaja.

Sijil perlu diperiksa secara khusus. Jalankan sudo certbot renew --dry-run selepas naik taraf. Ia menguji keseluruhan laluan pembaharuan, termasuk cangkuk (hook) muat semula pelayan web, tanpa menyentuh sijil aktif. Cangkuk yang memanggil nama servis atau binari yang telah berubah akan gagal di sini, di hadapan anda, bukannya gagal secara senyap dalam masa 60 hari. Certbot with Let's Encrypt on nginx merangkumi rupa bentuk cangkuk tersebut.

SSH: kegagalan yang menamatkan sesi semasa anda

Prompt sshd_config ialah tempat pengguna sering terkunci keluar. Menjawab Y akan memasang fail penyelenggara, yang membuang PermitRootLogin, PasswordAuthentication, AllowUsers, Port anda serta setiap baris lain yang telah anda tambah. Jika firewall anda hanya membenarkan port tersuai dan konfigurasi pakej mendengar pada 22, sambungan seterusnya akan ditolak, dan sesi yang sedang anda gunakan adalah yang terakhir.

Cegah perkara ini sebelum anda melakukan naik taraf. /etc/ssh/sshd_config pada 24.04 bermula dengan Include /etc/ssh/sshd_config.d/*.conf, dan OpenSSH mengekalkan nilai pertama yang dibacanya untuk setiap tetapan, jadi fail drop-in yang disertakan di bahagian atas akan mengatasi sebarang tetapan di bawahnya. Pindahkan tetapan anda ke dalam fail yang tidak dimiliki oleh 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

Apabila tiada apa-apa dalam /etc/ssh/sshd_config milik anda, prompt tersebut tidak lagi menjadi masalah: mana-mana jawapan akan mengekalkan tetapan anda, kerana ia berada dalam fail yang berbeza.

Port tersuai memerlukan satu lagi semakan, kerana ia mungkin tidak berada di tempat yang anda sangkakan:

systemctl is-enabled ssh.socket

Jika arahan itu mencetak enabled, systemd memiliki port pendengar tersebut dan baris Port dalam sshd_config akan diabaikan. Ubuntu telah menggunakan pengaktifan soket untuk sshd sejak 22.10, dan inilah sebabnya suntingan Port 2222 kelihatan tidak memberi kesan. Tetapkan ia pada unit soket sebaliknya, dengan sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

ListenStream= yang kosong diperlukan. Ia mengosongkan nilai yang diwarisi, dan tanpanya soket akan mendengar pada port 22 serta 2222. Gunakan tetapan tersebut dengan sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Selepas naik taraf, sebelum anda menutup sesi yang sedang digunakan:

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

Kemudian buka terminal kedua pada mesin anda sendiri dan log masuk semula. Shell yang berfungsi dalam terminal kedua itu adalah satu-satunya bukti yang sah. Pastikan sesi pertama tetap terbuka sehingga anda berjaya log masuk. Mengeraskan SSH pada VPS membincangkan tetapan yang wajar dikekalkan dalam fail drop-in tersebut.

Jika sudah terlambat, konsol web pembekal anda memberikan anda akses log masuk yang tidak menggunakan SSH sama sekali. Log masuk melalui konsol tersebut, betulkan konfigurasi, jalankan sudo sshd -t, dan mulakan semula servis. Konsol tersebut adalah sebab utama mengapa anda perlu menguji akses konsol sebelum naik taraf, bukannya semasa proses tersebut berlangsung.

FAQ

Mengapa do-release-upgrade menyatakan "No new release found" pada Ubuntu 24.04?

Kerana /etc/update-manager/release-upgrades mengandungi Prompt=lts pada Ubuntu Server, dan tetapan tersebut hanya menawarkan keluaran sokongan jangka panjang (LTS) seterusnya selepas keluaran titik (point release) pertamanya tersedia. Ubuntu 26.04 LTS dilancarkan pada 23 April 2026, dan 26.04.1 dijadualkan pada 27 Ogos 2026. Sehingga tarikh tersebut, pelayan 24.04 tidak akan mengesan sebarang kemas kini. Kekalkan tetapan tersebut daripada menukarnya kepada Prompt=normal, yang akan menghalakan anda melalui keluaran interim (interim releases) sebaliknya.

Adakah saya perlu but semula pelayan untuk melengkapkan naik taraf?

Ya. Naik taraf tersebut memasang kernel baharu, pustaka C baharu, dan sistem init baharu; sistem yang sedang berjalan akan terus menggunakan versi lama sehingga ia dimulakan semula. do-release-upgrade akan meminta anda untuk but semula pada akhir proses, dan mesin yang dibiarkan berjalan sehingga "nanti" merupakan mesin yang menjalankan campuran dua keluaran. Selepas ia kembali aktif, semak uname -r untuk kernel baharu dan systemctl --failed bagi servis yang tidak berjaya dihidupkan semula.

Patutkah saya melakukan naik taraf secara terus (in-place) atau membina pelayan 26.04 yang baharu?

Bina pelayan baharu jika boleh. VPS baharu membolehkan anda memasang stack, memulihkan data, dan menguji segala-galanya sementara pelayan lama masih melayani trafik. Dengan cara ini, proses rollback hanyalah perubahan DNS dan bukannya pemulihan daripada sandaran (backup). Lakukan naik taraf secara terus apabila pelayan menyimpan keadaan (state) yang sukar dipindahkan, apabila penyedia mengenakan caj setiap mesin, atau apabila anda mempunyai snapshot dan akses konsol yang terbukti. Laluan naik taraf secara terus adalah kaedah yang lazim, namun ia merupakan proses sehala sepanjang tempoh ia dijalankan.

Apakah yang berlaku jika sambungan SSH saya terputus semasa naik taraf?

Dalam shell log masuk biasa, proses tersebut akan menerima SIGHUP dan terhenti di tengah jalan, yang menyebabkan dpkg berada dalam keadaan separuh konfigurasi. Mulakan proses di dalam tmux atau screen supaya proses tersebut kekal berjalan; dengan itu anda boleh menyambung semula dan menjalankan tmux attach -t upgrade untuk menyambung tugas tersebut. Pemuat naik taraf (upgrader) juga memulakan daemon SSH tambahan pada port 1022 sebagai laluan masuk kedua, namun ia tidak membuka firewall untuk port tersebut. Oleh itu, benarkan port 1022 secara manual terlebih dahulu dan tutup semula selepas selesai.

Laman PHP saya memaparkan ralat 502 selepas naik taraf. Apa yang rosak?

Laluan soket PHP FPM telah berubah mengikut versi. Ubuntu 24.04 menjalankan PHP 8.3 manakala 26.04 menjalankan PHP 8.5, jadi /run/php/php8.3-fpm.sock tidak lagi wujud sementara vhost nginx anda masih merujuk kepadanya. Log ralat nginx akan memaparkan connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Kemas kini fastcgi_pass kepada soket 8.5, jalankan sudo nginx -t, kemudian muat semula (reload) nginx. Bagi Apache dengan mod_php, penyelesaian yang setara ialah sudo a2dismod php8.3 diikuti dengan sudo a2enmod php8.5 dan mulakan semula servis.