Cara Upgrade Ubuntu 24.04 ke 26.04 di VPS

Kapan Ubuntu 24.04 dapat di-upgrade ke 26.04?

Anda dapat meng-upgrade Ubuntu 24.04 ke 26.04 pada VPS setelah rilis poin 26.04.1 tersedia, yang dijadwalkan pada 27 August 2026. Sebelum itu, server 24.04 memang tidak akan melihat rilis baru tersebut. Ubuntu 26.04 LTS (Resolute Raccoon) dirilis pada 23 April 2026, tetapi Canonical baru membuka jalur upgrade dari LTS ke LTS pada rilis poin pertama. Rilis tersebut menggabungkan perbaikan bug instalasi dan upgrade yang ditemukan selama beberapa bulan pertama.

Jalankan pemeriksaan pada server 24.04 pada awal August 2026. Hasilnya akan seperti berikut:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Itu bukan kesalahan pada server Anda. /etc/update-manager/release-upgrades berisi Prompt=lts pada Ubuntu Server. Artinya, alat tersebut hanya menawarkan rilis long term support berikutnya, dan hanya setelah rilis poin .1 tersedia. Jika Anda menetapkan Prompt=normal, proses tersebut akan memandu Anda melewati 24.10, 25.04, dan 25.10 secara berurutan. Semua rilis interim tersebut telah mencapai end of life. Biarkan tetap pada lts dan tunggu. Jadwal Canonical dapat berubah, jadi periksa kembali jika tanggal tersebut berlalu tanpa perubahan.

Setiap perintah di bawah ini harus Anda jalankan sendiri pada server Anda, sesuai urutan yang diberikan. Release upgrade tidak dapat diuji coba pada mesin yang sedang Anda upgrade. Proses tersebut mengganti kernel dan C library, serta memerlukan reboot untuk selesai.

Perlukah melakukan upgrade?

Ubuntu 24.04 menerima pembaruan keamanan standar hingga 2029, jadi server produksi yang berfungsi baik tidak berada di bawah tenggat waktu. Lakukan upgrade karena Anda memerlukan sesuatu yang tersedia di 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2, atau kernel 7.0. "Nomornya bertambah" bukan alasan untuk menyentuh mesin yang melayani pelanggan.

Jangan melakukan upgrade di tempat jika salah satu kondisi berikut terpenuhi:

• Anda belum pernah membuka console provider Anda (VNC atau serial) dan login melalui console tersebut. Console itu adalah satu-satunya cara untuk kembali mengakses server jika SSH bermasalah. Mengetahui bahwa console tersebut tidak berfungsi saat Anda sudah terkunci di luar server adalah terlambat.
• Anda tidak dapat menanggung downtime selama satu jam dan tidak memiliki rollback.
• Stack Anda bergantung pada repositori pihak ketiga yang belum menerbitkan paket untuk resolute.
• Server dibuat secara manual lebih dari dua tahun lalu dan tidak ada yang mengetahui apa saja yang terpasang di dalamnya.

Alternatifnya sering kali lebih baik: buat VPS 26.04 baru, install stack Anda dan pulihkan data, lalu alihkan DNS setelah server tersebut merespons dengan benar. Anda dapat mempertahankan server lama tetap berjalan sampai server baru terbukti berfungsi baik. Rollback cukup dilakukan dengan mengubah DNS, bukan memulihkan cadangan. Jika memilih cara ini, mulai dari sepuluh menit pertama pada VPS baru dan siapkan server baru dengan benar.

Langkah 1: buat cadangan yang dapat dipulihkan

Gunakan dua lapisan karena keduanya dapat gagal dengan cara yang berbeda. Snapshot provider mencakup seluruh disk dan dapat dipulihkan dalam hitungan menit, tetapi snapshot dibuat saat database sedang menulis. Karena itu, snapshot hanya konsisten terhadap kerusakan (crash-consistent), bukan konsisten terhadap aplikasi. Cadangan tingkat file dengan restic, yang disimpan di luar server memberi Anda file individual dan salinan yang tetap tersedia jika akun Anda dikunci.

Buat dump database secara manual terlebih dahulu. Dump adalah satu-satunya cadangan database yang dapat Anda percaya tanpa menghentikan database tersebut.

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 hanya membuat dump yang konsisten untuk tabel InnoDB. Tabel MyISAM mengharuskan database dihentikan. Tarball /etc adalah yang akan benar-benar Anda gunakan, karena tarball tersebut berisi setiap file konfigurasi yang akan ditanyakan oleh proses upgrade.

Cadangan yang belum pernah Anda pulihkan hanyalah perkiraan. Pulihkan satu file dari cadangan tersebut sekarang, sebelum Anda membutuhkannya dalam situasi yang mendesak.

Langkah 2: selesaikan patch 24.04 terlebih dahulu

do-release-upgrade menolak berjalan pada sistem dengan status paket yang rusak. 24.04 yang hanya dipatch sebagian juga membuat setiap kegagalan berikutnya lebih sulit dibaca.

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

dpkg --audit yang tidak menampilkan apa pun berarti tidak ada paket yang dikonfigurasi sebagian. apt-mark showhold yang tidak menampilkan apa pun berarti tidak ada paket yang dikunci pada versi yang dapat menghambat upgrade. Lepaskan setiap paket yang tercantum dengan sudo apt-mark unhold dan nama paketnya. Anda juga dapat menganggap bahwa hold tersebut ada karena alasan tertentu dan menghentikan proses di sini.

Reboot jika kernel berubah. Dengan demikian, upgrade berjalan dari mesin yang menggunakan kode yang diyakininya sedang berjalan.

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

Selanjutnya, periksa ruang disk. Upgrader mengunduh seluruh set paket baru sebelum memasang apa pun. Jika ruang tidak cukup, proses dibatalkan dan pesan error menyebutkan filesystem yang bermasalah.

df -h / /boot

Masalah ini biasanya terjadi jika ruang kosong pada / kurang dari sekitar 5 GB. /boot dengan ruang kosong kurang dari 300 MB akan gagal kemudian, saat instalasi kernel, dengan No space left on device. Kernel lama biasanya menjadi penyebabnya, dan sudo apt --purge autoremove akan menghapusnya.

Ada satu hal lagi yang harus dihentikan sebelum memulai. Jika pembaruan keamanan otomatis berjalan di tengah proses, pembaruan tersebut menahan dpkg lock. Akibatnya, release upgrader berhenti dengan Could not get lock /var/lib/dpkg/lock-frontend. Jalankan sudo systemctl stop unattended-upgrades terlebih dahulu, lalu mulai kembali setelah proses tersebut selesai.

Langkah 3: periksa repositori pihak ketiga dan paket yang dipin

do-release-upgrade menonaktifkan setiap sumber apt yang bukan berasal dari Ubuntu, karena paket yang dibuat untuk noble dapat merusak sistem resolute. Setelah itu, do-release-upgrade mengaktifkan kembali sumber yang dikenali dan membiarkan sumber lainnya tetap dinonaktifkan. Pahami konfigurasi yang Anda gunakan sebelum alat tersebut menentukan tindakan untuk 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 di direktori tersebut: file .list satu baris versi lama dan file .sources berformat deb822 dengan field Types: dan Suites:. Keduanya dinonaktifkan oleh proses upgrade. ubuntu-security-status --thirdparty mencantumkan paket terinstal yang tidak disediakan oleh arsip Ubuntu mana pun. Daftar ini menunjukkan jumlah sebenarnya dari paket tambahan yang Anda pasang. Apa pun yang tercantum dalam /etc/apt/preferences.d/ adalah pin, dan pin yang ditulis untuk noble akan terus memilih paket lama pada rilis baru.

Untuk setiap repositori pihak ketiga, pastikan vendor telah menerbitkan repositori untuk codename baru sebelum memulai. Suite Docker tercantum di https://download.docker.com/linux/ubuntu/dists/, dan vendor lain menyediakan direktori dengan struktur yang sama. Sumber yang menunjuk ke suite yang tidak ada akan menghasilkan pesan berikut saat menjalankan apt update pertama setelah upgrade:

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

Biarkan sumber tersebut tetap dinonaktifkan sampai vendor menerbitkannya. Mengubah codename ke codename yang memang digunakan vendor untuk membangun paket dapat menyebabkan Anda menginstal paket yang tertaut ke library sistem yang salah.

Langkah 4: jalankan upgrade di tmux, bukan di shell SSH biasa

Jika koneksi Anda terputus saat do-release-upgrade berjalan di shell login biasa, proses menerima SIGHUP dan berhenti di tengah proses unpacking. Akibatnya, dpkg berada dalam kondisi terkonfigurasi sebagian, dan server mungkin tidak lagi memiliki network stack yang berfungsi untuk menerima koneksi ulang. Jalankan proses tersebut di dalam terminal multiplexer agar tetap aktif di server saat koneksi client Anda terputus.

sudo apt install -y tmux
tmux new -s upgrade

Di dalam sesi tersebut:

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

Proses upgrader memulai daemon SSH kedua pada port 1022 sebelum mengubah apa pun, dan menampilkan pesan berikut:

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.

Proses tersebut tidak membuka firewall untuk port itu karena membuka akses firewall tanpa meminta persetujuan akan menimbulkan risiko yang tidak diharapkan. Buka port 1022 secara manual sebelum memulai, lalu tutup kembali setelah selesai menggunakan sudo ufw delete allow 1022/tcp. Ingat bahwa provider Anda mungkin menjalankan firewall kedua melalui control panel, di luar server.

Jika koneksi tetap terputus, login kembali lalu jalankan tmux attach -t upgrade. Proses upgrade tetap berjalan selama Anda tidak terhubung.

Langkah 5: jawab prompt file konfigurasi dengan cermat

dpkg hanya menampilkan prompt untuk file yang Anda atau sebuah skrip ubah. Karena itu, setiap prompt merujuk pada file yang memang Anda edit dengan sengaja. Menekan enter agar prompt tersebut hilang dapat membuat server yang telah diperkuat diam-diam kembali menggunakan konfigurasi default.

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. Baca perubahan yang ada, lalu pertahankan versi Anda dengan N. Pilihan default adalah N, dan ini merupakan jawaban yang aman karena file Anda sudah berfungsi saat ini, sedangkan file dari paket belum pernah dijalankan pada mesin ini.

Mempertahankan file Anda memiliki konsekuensi: Anda tidak mendapatkan default baru. Lakukan penyesuaian setelahnya, setelah server aktif dan Anda tidak berada dalam tekanan waktu.

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

Setiap file yang tercantum adalah versi maintainer yang disimpan di sebelah file Anda. Bandingkan keduanya satu per satu, lalu salin pengaturan penting ke file Anda. Berikan perhatian khusus pada dua file: /etc/ssh/sshd_config, karena jawaban yang salah akan mengakhiri sesi Anda, dan konfigurasi web server Anda, karena jawaban yang salah akan membuat situs tidak dapat diakses.

Upgrade juga menanyakan layanan mana yang harus di-restart melalui needrestart. Terima seluruh daftar. Daemon yang masih berjalan menggunakan file shared library yang telah dihapus dari disk dapat mengalami crash pada request berikutnya, saat Anda tidak sedang memantaunya.

Langkah 6: reboot, lalu periksa mesin

sudo reboot

Setelah 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 seharusnya melaporkan Release: 26.04 dan Codename: resolute. uname -r seharusnya menampilkan kernel 7.0. systemctl --failed seharusnya mencantumkan nol unit. Jika ada unit yang tercantum, itulah tugas Anda berikutnya. apt update terakhir mengambil pembaruan yang diterbitkan sejak image rilis dibuat.

PostgreSQL 16 ke 18: cluster yang diam-diam tertinggal

Ubuntu 24.04 menyertakan PostgreSQL 16, sedangkan 26.04 menyertakan PostgreSQL 18. Proses upgrade memasang 18 berdampingan dengan 16 dan tidak memindahkan data Anda. Lapisan postgresql-common milik Debian membuat cluster baru yang kosong untuk versi mayor baru pada port bebas berikutnya. Dengan demikian, 16 tetap menggunakan port 5432 beserta seluruh data Anda, sedangkan 18 berada dalam keadaan kosong pada port 5433. Aplikasi Anda tetap terhubung ke 5432 dan tidak menunjukkan masalah apa pun. Karena itu, masalah ini sering baru ditemukan beberapa bulan kemudian.

pg_lsclusters

Jika terdapat dua cluster dalam daftar, berarti Anda belum melakukan migrasi. Lakukan migrasi saat aplikasi dapat dihentikan:

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

Hapus cluster 18 yang kosong terlebih dahulu karena pg_upgradecluster tidak akan menulis ke cluster target yang sudah ada. Metode default mencadangkan data dari 16 lalu memuatnya kembali ke 18. Karena itu, Anda memerlukan ruang disk kosong yang kira-kira sebesar ukuran database. -m upgrade menggunakan pg_upgrade sebagai gantinya dan jauh lebih cepat pada database berukuran besar. Setelah proses selesai, baca kolom Port. Cluster baru akan mengambil alih port 5432, sedangkan cluster lama dibiarkan berhenti. Jalankan proses analyze secara manual karena cluster yang baru dimuat belum memiliki statistik dan query pertama akan berjalan lambat.

Uji aplikasi terhadap cluster baru selama beberapa hari. Setelah itu, hapus cluster lama:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Direktori data cluster lama adalah cara rollback tercepat yang Anda miliki. Jangan menghapusnya pada hari upgrade.

MySQL 8.0 ke 8.4: opsi yang dihapus dan menghentikan server

26.04 memutakhirkan MySQL dari 8.0 ke 8.4 LTS, dan dua perubahan dapat menyebabkan masalah pada server.

Pertama, mysqld menolak untuk start jika konfigurasinya berisi opsi yang telah dihapus pada versi baru. default_authentication_plugin adalah opsi yang umum digunakan karena banyak panduan lama menyarankan pengaturannya. Service gagal start, dan journalctl -u mysql -n 50 menyebutkan variabel yang tidak dikenal secara langsung. Hapus baris tersebut dari file di bawah /etc/mysql/mysql.conf.d/, lalu sudo systemctl start mysql.

Kedua, plugin mysql_native_password tidak lagi diaktifkan secara default pada 8.4, sehingga account yang masih menggunakannya sama sekali tidak dapat login. Periksa saat Anda masih menggunakan 8.0:

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

Migrasikan setiap account yang menampilkan mysql_native_password sebelum upgrade, lalu perbarui password dalam konfigurasi aplikasi:

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

Jika library client terlalu lama untuk menggunakan caching_sha2_password, Anda dapat mengaktifkan kembali plugin lama pada 8.4 dengan menambahkan mysql_native_password=ON di bawah [mysqld]. Gunakan ini hanya sebagai solusi sementara dengan batas waktu, karena plugin tersebut akan dihapus sepenuhnya.

PHP 8.3 hingga 8.5: vhost Anda menunjuk ke socket yang sudah tidak ada

Ubuntu 24.04 menyertakan PHP 8.3, sedangkan Ubuntu 26.04 menyertakan PHP 8.5. Paket diinstal ke path berversi, dan tidak ada proses yang menulis ulang konfigurasi web server Anda. vhost nginx yang berisi fastcgi_pass unix:/run/php/php8.3-fpm.sock; sekarang menunjuk ke socket yang tidak dibuat oleh proses mana pun. Akibatnya, setiap permintaan PHP mengembalikan 502, dan error log nginx berisi:

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

Arahkan ke socket baru, uji konfigurasi, lalu 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

Pada Apache dengan mod_php, gejalanya berbeda. Apache sama sekali tidak dapat start, dan sudo apache2ctl -t melaporkan bahwa libphp8.3.so tidak dapat dimuat karena file tersebut tidak ada. Modul yang diaktifkan adalah symlink ke paket yang sudah tidak ada.

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

Jika Anda membangun server menggunakan stack LAMP di Ubuntu 24.04, kedua path tersebut perlu diperiksa. Panduan tersebut menghasilkan nama modul dan socket berversi.

Konfigurasi tuning php.ini Anda juga tidak ikut berpindah. memory_limit, upload_max_filesize, dan pengaturan lain yang Anda tetapkan berada di /etc/php/8.3/, sedangkan tree baru menggunakan nilai default. Bandingkan kedua file tersebut, lalu salin nilainya secara manual. Menyalin seluruh file lama ke file baru akan membawa nilai default 8.3 ke instalasi 8.5. Setelah itu, jalankan php -m dan bandingkan hasilnya. Ekstensi yang diinstal sebagai php8.3-redis memerlukan paket php8.5-. Jika ekstensi tersebut berasal dari PPA, upgrader menonaktifkan sumber tersebut sehingga ekstensi itu tidak lagi tersedia.

Sertifikat juga perlu diperiksa secara khusus. Jalankan sudo certbot renew --dry-run setelah upgrade. Perintah ini menguji seluruh jalur renewal, termasuk hook reload web server, tanpa mengubah sertifikat aktif. Jika hook memanggil nama service atau binary yang sudah berubah, kegagalan terlihat langsung di sini, bukan terjadi tanpa diketahui 60 hari kemudian. Certbot dengan Let's Encrypt pada nginx menjelaskan bentuk hook yang benar.

SSH: kegagalan yang mengakhiri sesi yang sedang Anda gunakan

Prompt sshd_config adalah tempat pengguna dapat terkunci dari server. Menjawab Y akan memasang file pemelihara paket, yang membuang PermitRootLogin, PasswordAuthentication, AllowUsers, Port, serta setiap baris lain yang Anda tambahkan. Jika firewall Anda hanya mengizinkan port khusus dan konfigurasi paket menggunakan port 22, koneksi berikutnya akan ditolak. Sesi yang sedang Anda gunakan menjadi sesi terakhir yang tersedia.

Cegah masalah ini sebelum melakukan upgrade. /etc/ssh/sshd_config pada 24.04 dimulai dengan Include /etc/ssh/sshd_config.d/*.conf. OpenSSH mempertahankan nilai pertama yang dibacanya untuk setiap pengaturan. Karena itu, drop-in yang disertakan di bagian atas akan mengalahkan pengaturan di bawahnya. Pindahkan pengaturan Anda ke file yang tidak dimiliki 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

Setelah tidak ada lagi konfigurasi Anda di /etc/ssh/sshd_config, prompt tersebut tidak lagi penting. Apa pun jawaban Anda, pengaturan tetap dipertahankan karena berada di file lain.

Port khusus memerlukan satu pemeriksaan tambahan karena port tersebut mungkin tidak berada di lokasi yang Anda kira:

systemctl is-enabled ssh.socket

Jika perintah tersebut menampilkan enabled, systemd mengelola port yang sedang listen. Baris Port di sshd_config diabaikan. Ubuntu telah menggunakan socket activation untuk sshd sejak 22.10. Inilah sebabnya perubahan Port 2222 tampak tidak berpengaruh. Tetapkan port pada unit socket dengan sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

ListenStream= yang kosong diperlukan. Nilai yang diwariskan akan dihapus. Tanpa nilai tersebut, socket juga akan listen pada port 22 selain 2222. Terapkan perubahan dengan sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Setelah upgrade, sebelum menutup sesi yang sedang Anda gunakan:

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

Kemudian buka terminal kedua pada mesin Anda dan login kembali. Shell yang berfungsi di terminal kedua adalah satu-satunya bukti yang dapat diandalkan. Biarkan sesi pertama tetap terbuka sampai Anda berhasil login. Hardening SSH pada VPS membahas pengaturan yang sebaiknya dipertahankan dalam drop-in tersebut.

Jika sudah terlambat, web console dari provider Anda menyediakan login yang tidak menggunakan SSH. Login melalui console tersebut, perbaiki konfigurasi, jalankan sudo sshd -t, lalu restart service. Console tersebut adalah alasan Anda harus menguji akses console sebelum upgrade, bukan saat upgrade berlangsung.

FAQ

Mengapa do-release-upgrade menampilkan "No new release found" di Ubuntu 24.04?

Karena /etc/update-manager/release-upgrades berisi Prompt=lts pada Ubuntu Server. Pengaturan tersebut hanya menawarkan rilis long term support berikutnya setelah point release pertamanya tersedia. Ubuntu 26.04 LTS dirilis pada 23 April 2026, sedangkan 26.04.1 dijadwalkan pada 27 August 2026. Sebelum tanggal tersebut, server 24.04 tidak akan melihat rilis baru. Biarkan pengaturan itu apa adanya. Jangan beralih ke Prompt=normal karena sistem akan melewati rilis interim.

Apakah saya harus me-reboot server untuk menyelesaikan upgrade?

Ya. Upgrade memasang kernel baru, C library baru, dan init system baru. Sistem yang sedang berjalan tetap menggunakan komponen lama sampai direstart. do-release-upgrade meminta reboot pada akhir proses. Mesin yang dibiarkan berjalan hingga "nanti" akan menggunakan campuran komponen dari dua rilis. Setelah kembali online, periksa uname -r untuk melihat kernel baru dan systemctl --failed untuk menemukan service yang tidak berhasil berjalan kembali.

Sebaiknya saya melakukan upgrade in-place atau membuat server 26.04 baru?

Buat server baru jika memungkinkan. VPS baru memungkinkan Anda memasang stack, memulihkan data, dan menguji semuanya saat server lama masih melayani traffic. Dengan demikian, rollback cukup dilakukan dengan mengubah DNS, bukan dengan memulihkan backup. Lakukan upgrade in-place jika server menyimpan state yang sulit dipindahkan, provider menagih biaya per mesin, atau Anda memiliki snapshot dan akses console yang sudah teruji. Jalur in-place sudah umum digunakan, tetapi selama proses berlangsung, perubahan tersebut tidak dapat dibatalkan dengan mudah.

Apa yang terjadi jika koneksi SSH saya terputus selama upgrade?

Dalam login shell biasa, proses menerima SIGHUP dan berhenti di tengah proses. Akibatnya, dpkg berada dalam kondisi terkonfigurasi sebagian. Jalankan proses di dalam tmux atau screen agar proses tetap berjalan. Setelah tersambung kembali, jalankan tmux attach -t upgrade untuk melanjutkannya. Upgrader juga menjalankan SSH daemon cadangan pada port 1022 sebagai jalur akses kedua. Namun, upgrader tidak membuka firewall untuk port tersebut. Izinkan port 1022 terlebih dahulu, lalu tutup kembali setelah selesai.

Situs PHP saya mengembalikan 502 setelah upgrade. Apa yang rusak?

Path socket PHP FPM berubah sesuai versinya. Ubuntu 24.04 menjalankan PHP 8.3, sedangkan 26.04 menjalankan PHP 8.5. Akibatnya, /run/php/php8.3-fpm.sock tidak lagi ada, sementara vhost nginx masih menggunakannya. Error log nginx menampilkan connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Perbarui fastcgi_pass agar menggunakan socket 8.5, jalankan sudo nginx -t, lalu reload nginx. Pada Apache dengan mod_php, perbaikan yang setara adalah sudo a2dismod php8.3, kemudian sudo a2enmod php8.5 dan restart.