Mengatasi do-release-upgrade: tidak ada rilis baru

Mengapa do-release-upgrade menyatakan tidak ada rilis baru

do-release-upgrade yang berakhir di No new release found. hampir tidak pernah menunjukkan bahwa alatnya rusak. Jalur upgrade yang diminta memang tertutup saat itu, dan alat tersebut melaporkannya dengan cara sesingkat mungkin. Ada lima hal yang dapat menutup jalur tersebut: pengaturan Prompt di /etc/update-manager/release-upgrades, gate point release pada upgrade LTS (long term support), repositori pihak ketiga, paket yang ditahan atau belum dikonfigurasi sepenuhnya, serta rilis yang sudah melewati masa dukungannya.

Periksa semuanya dalam urutan tersebut. Masing-masing memiliki perintah untuk membuktikan apakah kondisi itu berlaku pada server Anda. Dengan demikian, Anda tidak perlu menebak kondisi mana dari kelima hal tersebut yang sedang terjadi.

Apa yang sebenarnya dilaporkan flag check-only

sudo do-release-upgrade -c
echo $?

-c hanya melakukan pemeriksaan. Perintah ini membaca metadata rilis Canonical melalui HTTPS (hypertext transfer protocol secure) dan menampilkan hasilnya. Perintah ini tidak mengunduh alat upgrade dan tidak menulis ulang file source. Ada dua keluaran penting:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Kode keluar menyampaikan hasil yang sama untuk script. Nilainya 0 jika rilis tersedia dan 1 jika tidak ada rilis, yaitu kebalikan dari konvensi shell pada umumnya. Karena itu, periksa nilainya dengan saksama sebelum menggunakannya sebagai dasar pemeriksaan.

Jika banner login masih menampilkan hasil lama, berarti hasil tersebut tersimpan dalam cache. Baris itu berasal dari /etc/update-motd.d/91-release-upgrade, yang menampilkan hasil tersimpan dan tidak mengakses jaringan. Perbarui hasilnya dengan sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, atau cukup percayai -c. Banner hanya mengulangi hasil pemeriksaan terakhir yang dijalankan.

Pemeriksaan ini juga harus dapat terhubung ke changelogs.ubuntu.com. Pada server di balik firewall outbound yang ketat atau proxy yang tidak dapat digunakan oleh perintah tersebut, metadata tidak dapat diminta. Akibatnya, tidak ada rilis yang dapat ditemukan.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Baris HTTP/2 200 berarti server dapat melihat metadata. Baris curl: (28) Connection timed out berarti aturan egress adalah penyebab sebenarnya. Mengedit file APT (advanced package tool) sebanyak apa pun tidak akan mengubah hasilnya.

Jika perintah tersebut tidak tersedia sama sekali, perintah itu berada dalam ubuntu-release-upgrader-core. Image cloud minimal terkadang tidak menyertakan package tersebut.

sudo apt install ubuntu-release-upgrader-core

Baca /etc/update-manager/release-upgrades sebelum mengubah apa pun

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

File tersebut memuat dokumentasinya sendiri dalam komentar. Tiga nilai berikut valid:

• never: jangan pernah memeriksa atau mengizinkan upgrade ke rilis baru.
• normal: tawarkan rilis yang didukung dan langsung mengikuti rilis yang sedang berjalan.
• lts: tawarkan rilis LTS pertama yang mengikuti rilis yang sedang berjalan.

Prompt=never paling mudah didiagnosis karena tool tersebut menyebutkan nama file dan pengaturan itu dalam output-nya:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Penyedia hosting dan tool manajemen konfigurasi sengaja menetapkan never untuk mencegah sekumpulan server berpindah antar-rilis tanpa kendali. Jika Anda menemukannya di sana, berarti seseorang sengaja memilihnya. Ubah nilainya menjadi lts untuk server yang ingin Anda pertahankan pada jalur long-term support, lalu kembalikan setelahnya jika automation Anda mengharapkan nilai lama.

Ada satu detail dalam komentar tersebut yang sering terlewat. Jika Prompt=lts ditetapkan dan rilis yang sedang berjalan bukan rilis LTS, upgrader memperlakukan pengaturan tersebut sebagai normal. Pada mesin 25.10, kedua nilai tersebut berperilaku sama. Pada mesin 24.04, keduanya tidak sama. Perbedaan itu menjadi inti bagian berikutnya.

Mengapa upgrade LTS ke LTS menunggu point release pertama

Prompt menentukan file metadata yang dibaca upgrader. Alamatnya terdapat di /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts membaca meta-release-lts. Prompt=normal membaca meta-release. Kedua file tersebut menjelaskan setiap release dalam blok kecil berisi beberapa key, dan upgrader hanya menawarkan release jika flag Supported:-nya bernilai 1. Baca sendiri file tersebut dari server yang sama:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Pemeriksaan pada 13 August 2026 menunjukkan bahwa kedua file tersebut memberikan informasi yang berbeda tentang Ubuntu 26.04. File LTS berisi:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

File biasa berisi:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Nilai Supported: 0 dalam file LTS adalah gate-nya. Server 24.04 yang menggunakan Prompt=lts default membaca file tersebut, tidak menemukan release LTS yang lebih baru dan ditandai tersedia, lalu menampilkan No new release found. Tidak ada yang salah pada mesin Anda. Canonical belum membuka jalur tersebut.

Flag berubah menjadi 1 saat point release pertama dirilis. Ubuntu 26.04.1 dijadwalkan pada 27 August 2026, tetapi jadwal release dapat berubah. Karena itu, periksa metadata, bukan kalender. Penundaan ini disengaja: pengguna yang melakukan upgrade lebih awal menemukan masalah penghambat, lalu masalah tersebut diperbaiki sebelum populasi server LTS yang jauh lebih besar melakukan upgrade.

Ada dua opsi yang dapat dipilih. Tunggu point release, yang merupakan pilihan tepat untuk server yang tidak ingin sering Anda pantau. Atau, tetapkan Prompt=normal, yang mengarahkan tool yang sama ke meta-release, tempat 26.04 sudah ditandai sebagai didukung. Jalur kedua akan meng-upgrade Anda ke 26.04 yang sudah dirilis, bukan ke build development. Karena itu, opsi ini masih dapat dipertanggungjawabkan pada mesin yang dapat dipulihkan dari snapshot. Kembalikan nilai tersebut ke lts setelah selesai. Prosedurnya, langkah demi langkah, tersedia di panduan lengkap upgrade server 24.04 ke 26.04.

Repositori pihak ketiga dan PPA yang menghambat upgrade

Alat upgrade menulis ulang sumber APT agar menunjuk ke rilis baru. Alat ini hanya dapat melakukannya untuk repositori yang menyediakan paket bagi rilis baru. Sumber lainnya akan dinonaktifkan dengan menambahkan komentar. Alasannya dicetak satu baris untuk setiap entri, dan pesannya spesifik: was disabled (unknown mirror), was disabled (unknown dist), dan was disabled (no Release file).

PPA (personal package archive) yang dibuat untuk noble tidak memiliki direktori untuk resolute di server. Akibatnya, alat upgrade tidak dapat mengambil file Release untuk seri baru dan menonaktifkan entri tersebut. Biasanya ini hanya peringatan yang dapat Anda terima. Masalah ini menjadi penghenti proses ketika repositori pihak ketiga menyediakan paket yang juga disertakan dalam rilis baru. Dalam kondisi tersebut, perhitungan upgrade memiliki dua kandidat dan tidak dapat memenuhi keduanya.

Tentukan sendiri hal ini sebelum memulai, bukan membiarkan alat mengambil keputusan selama proses unattended yang berlangsung lama.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy pada nama paket menampilkan asal repositori untuk setiap versi yang terpasang. Dengan demikian, Anda dapat melihat secara tepat paket mana yang bergantung pada sumber yang akan dinonaktifkan. Menghapus sumber tidak menurunkan versi paket. Jadi, paket yang dipasang dari PPA tetap menggunakan versi PPA dan dapat lebih baru daripada versi yang tersedia dalam rilis baru. Jika hal itu berpengaruh, hapus paket tersebut juga, lalu pasang ulang dari archive setelah upgrade. Jika Anda berencana mengaktifkan kembali suatu repositori, seperti repositori Tailscale, codename-nya harus diperbarui ke rilis baru sebelum paket dapat dipasang kembali. Inilah penyebab sebagian besar error instalasi Tailscale di Ubuntu.

Tersedia flag untuk pilihan sebaliknya. Halaman manual menjelaskan --allow-third-party sebagai "Mencoba upgrade dengan mirror dan repositori pihak ketiga tetap diaktifkan, bukan menonaktifkannya." Gunakan flag ini hanya setelah memastikan bahwa repositori tersebut sudah menyediakan paket untuk rilis target. Jika belum, Anda meminta APT menyelesaikan grafik dependensi terhadap seri yang belum pernah dibuat oleh repositori tersebut.

Pada Ubuntu 24.04 dan versi lebih baru, sebagian besar sumber berada di /etc/apt/sources.list.d/ubuntu.sources dalam format deb822. Repositori yang sama dan ditulis dalam format lama serta format baru akan menghasilkan error terpisah dengan pesan tersendiri. Kasus ini dibahas dalam error entri sumber duplikat dalam format deb822.

Paket yang tertahan dan belum dikonfigurasi menghentikan perhitungan

Upgrade rilis harus memindahkan hampir semua paket pada sistem. Jika satu paket tidak dapat dipindahkan, perhitungannya gagal. Upgrader akan lebih baik berhenti lebih awal daripada membiarkan proses berjalan setengah selesai. Dua perintah dapat menemukan penyebabnya.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold mencetak paket yang ditahan, satu paket per baris, dan tidak mencetak apa pun pada sistem yang bersih. Penahanan adalah instruksi manual untuk tidak pernah mengubah paket tersebut. Seseorang mungkin menahan kernel atau versi database, lalu melupakannya. Lepaskan penahanan paket yang tidak lagi diperlukan dengan sudo apt-mark unhold diikuti nama paket.

dpkg --audit mencantumkan paket yang sudah dibongkar tetapi belum dikonfigurasi. Status ini berasal dari proses instalasi yang terhenti, paling sering karena sesi terputus. Upgrader mencoba memperbaikinya dan mencetak dpkg interrupted, calling dpkg --configure -a, tetapi menjalankan perbaikan sendiri terlebih dahulu memungkinkan Anda membaca error, bukan membiarkannya berlalu di layar. Jika tool tidak dapat memperbaiki suatu paket, tool tersebut menghasilkan pesan Package in inconsistent state. Paket itu perlu ditangani sebelum Anda mencoba lagi.

Perbarui rilis yang sedang berjalan hingga sepenuhnya mutakhir sebelum melakukan upgrade.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

Opsi phased updates lebih penting daripada yang terlihat. Ubuntu meluncurkan sebagian pembaruan ke persentase mesin tertentu secara bertahap. Karena itu, apt upgrade biasa dapat dengan benar membiarkan beberapa paket tetap tertinggal, sehingga server menjadi kurang mutakhir daripada yang Anda kira. Opsi tersebut mengambil semua pembaruan. Reboot setelahnya jika pembaruan itu menyertakan kernel, sehingga Anda melakukan upgrade dari kernel yang benar-benar sedang berjalan. Server yang sudah memperbarui dirinya sendiri melalui upgrade keamanan tanpa pengawasan memiliki lebih sedikit pekerjaan pada tahap ini, meskipun mekanisme tersebut memang tidak pernah melewati batas antar-rilis.

Jika rilis sudah melewati akhir dukungan standar

Rilis interim Ubuntu didukung selama sembilan bulan. Setelah dukungan tersebut berakhir, flag Supported: berubah menjadi 0, dan jalur normal tidak menyediakan opsi upgrade dari rilis itu. Berdasarkan pemeriksaan pada 13 August 2026, meta-release menyatakan hal berikut tentang 25.10:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

Archive juga berpindah pada waktu yang sama. Paket untuk rilis yang sudah mencapai akhir masa dukungan dihapus dari archive.ubuntu.com dan disimpan di old-releases.ubuntu.com. Akibatnya, apt update mulai mengembalikan 404 Not Found, sistem tidak dapat lagi diperbarui, dan karena upgrader mengharuskan sistem sudah diperbarui, proses tidak dapat dilanjutkan. Perbaiki source terlebih dahulu.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Arahkan archive.ubuntu.com dan security.ubuntu.com ke old-releases.ubuntu.com, lalu biarkan codename tetap seperti semula. Hanya nama host yang berubah.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Jalankan perintah yang sama terhadap /etc/apt/sources.list jika server Anda masih menyimpan source dalam satu file tersebut. Opsi -i.bak membuat cadangan di sebelah file asli, sehingga Anda dapat mengembalikannya jika perubahan ternyata ditujukan ke file yang salah. apt update yang berhasil setelah itu berarti archive dapat diakses kembali, dan do-release-upgrade kini akan dapat berkomunikasi dengan Anda.

Tetapkan ekspektasi yang realistis tentang hasil proses ini. Ubuntu mendukung satu langkah rilis pada satu waktu, sehingga server yang tertinggal dua atau tiga rilis yang sudah tidak didukung harus melewati setiap langkah secara berurutan. Setiap langkah juga dapat gagal karena repository pihak ketiga atau paket yang ditahan masing-masing. Pada VPS, sering kali lebih cepat membuat server baru dengan LTS terbaru, memindahkan service ke server tersebut, lalu mempertahankan server lama sampai Anda yakin semuanya berjalan baik. Cara ini juga menyediakan rollback, sesuatu yang tidak pernah tersedia pada upgrade di tempat. Jika setelah itu Anda sedang memilih jalur rilis yang akan digunakan, bacalah perbedaan antara rilis LTS dan interim pada server sebelum mengambil keputusan.

Apa yang sebenarnya dilakukan flag development release

-d atau --devel-release membuat upgrader membaca meta-release-development, bukan file yang dipilih oleh Prompt. Halaman manual menjelaskannya sebagai "Jika menggunakan rilis terbaru yang didukung, lakukan upgrade ke development release."

Diperiksa pada 13 August 2026, entri terbaru dalam file tersebut bukan 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Jadi, -d tidak memberikan 26.04 yang sudah dirilis kepada server 24.04. Flag tersebut mengarah ke 26.10, yaitu rilis yang masih dalam proses pengembangan. Saran lama untuk "cukup tambahkan -d" ditulis untuk periode sebelum LTS dirilis. Jika diulangi sekarang, server Anda akan diarahkan ke tujuan yang tidak Anda inginkan. Jika Prompt=lts masih digunakan, flag tersebut berhenti dan menampilkan pesannya sendiri:

There is no development version of an LTS available.

Dokumentasi server Ubuntu menjelaskan flag tersebut secara tegas: "menggunakan development release (atau flag -d) tidak direkomendasikan untuk lingkungan produksi". Development release berubah setiap hari dan tidak memiliki jaminan dukungan keamanan. Akibatnya, paket yang berfungsi pada pagi hari dapat menyebabkan service gagal pada sore hari. Gunakan rilis tersebut pada virtual machine sementara yang dibuat untuk menguji konfigurasi Anda sendiri. Jangan gunakan pada server yang diandalkan oleh pengguna atau service lain. Jika Anda menginginkan 26.04 yang sudah dirilis sebelum LTS gate dibuka, Prompt=normal adalah cara yang benar.

Jalankan upgrade di tempat sesi SSH yang terputus tidak dapat menghentikannya

Upgrade rilis mengganti sebagian besar sistem, termasuk openssh-server dan systemd. Jika sesi SSH (secure shell) Anda terputus saat dpkg sedang bekerja, proses tersebut dihentikan setelah paket dibongkar dan belum dikonfigurasi. Kondisi inilah yang biasanya membuat percobaan berikutnya gagal. Selalu mulai upgrade di dalam terminal multiplexer.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Jika koneksi terputus, login kembali lalu jalankan tmux attach -t upgrade. Upgrade tetap berjalan karena proses tersebut merupakan child dari server tmux, bukan dari sesi SSH Anda. screen -S upgrade dan screen -r upgrade menjalankan fungsi yang sama jika Anda lebih memilih screen.

Program upgrade memiliki mekanisme pengamanan sendiri bagi pengguna yang tidak memakai multiplexer. Saat mendeteksi bahwa program berjalan melalui SSH, program tersebut menawarkan untuk memulai sshd kedua pada port 1022. Dengan demikian, sesi utama yang terputus masih menyediakan jalur untuk masuk kembali. Program tersebut menentukan kondisi ini dengan menelusuri proses induknya sendiri dan mencari proses bernama sshd. Di dalam tmux atau screen, penelusuran itu justru menemukan server multiplexer. Karena itu, tawaran tersebut tidak muncul, dan file pid /var/run/release-upgrader-sshd.pid hanya ditulis saat daemon tambahan benar-benar dimulai. Tidak ada masalah jika Anda tidak melihat prompt tersebut. Anda sudah memiliki perlindungan yang lebih baik.

Jika Anda menerima tawaran tersebut, port itu tidak dibuka secara otomatis. Tool tersebut menjelaskannya dengan tegas karena membuka port adalah keputusan keamanan yang tidak berhak diambilnya untuk Anda. Buka port tersebut selama upgrade berlangsung, lalu tutup kembali setelahnya.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

Sebagian besar penyedia VPS menjalankan firewall kedua di panel kontrol mereka, di luar sistem operasi. Port 1022 juga harus dibuka di sana. Jika tidak, listener fallback berjalan tetapi tidak dapat dijangkau. Ini adalah kondisi terburuk.

Pastikan empat hal berikut sebelum mengetik perintah:

• Buat snapshot atau backup penuh. Upgrade rilis langsung tidak memiliki fungsi undo, dan inilah satu-satunya kesempatan Anda untuk memulihkannya.
• Pastikan Anda dapat membuka console penyedia sebelum membutuhkannya. Jika server tidak kembali setelah reboot, SSH adalah akses yang tidak akan Anda miliki. Kernel yang gagal boot merupakan masalah terpisah dengan langkah pemulihannya sendiri, yang dibahas dalam VPS yang tidak dapat boot setelah pembaruan kernel.
• Periksa ruang kosong dengan df -h / /boot. Upgrade mengunduh seluruh kumpulan paket, dan partisi /boot yang menyimpan beberapa kernel lama sering menjadi tempat proses terhenti.
• Baca catatan rilis untuk service yang Anda jalankan. Lompatan versi utama pada PostgreSQL atau PHP ikut hadir bersama rilis tersebut, terlepas dari apakah Anda sudah merencanakannya.

FAQ

Mengapa do-release-upgrade menyatakan tidak ada rilis baru yang ditemukan pada Ubuntu 24.04?

Nilai default Prompt=lts di /etc/update-manager/release-upgrades membuat alat tersebut membaca https://changelogs.ubuntu.com/meta-release-lts, dan Ubuntu 26.04 menetapkan Supported: 0 dalam file itu hingga point release pertamanya. Upgrader tidak menemukan rilis LTS yang lebih baru dan ditandai tersedia, sehingga proses berhenti. Periksa file tersebut sendiri dengan curl -s https://changelogs.ubuntu.com/meta-release-lts, lalu baca blok terakhir. Saat diperiksa pada 13 August 2026, nilainya masih 0, sedangkan Ubuntu 26.04.1 dijadwalkan pada 27 August 2026.

Apakah aman menetapkan Prompt=normal daripada menunggu point release?

Proses ini meng-upgrade sistem ke 26.04 yang sudah dirilis, bukan ke build development, karena Prompt=normal membaca meta-release, dan 26.04 sudah memiliki Supported: 1 di sana. Risikonya terletak pada waktu pelaksanaan. Anda melakukan upgrade sebelum masalah yang ditemukan oleh pengguna awal diperbaiki. Lakukan pada server yang dapat dipulihkan dari snapshot dan yang dapat Anda akses melalui konsol provider jika reboot gagal. Setelah selesai, kembalikan nilainya ke lts.

Apakah flag -d meng-upgrade sistem saya ke 26.04?

Tidak. -d membaca meta-release-development, yang entri terbarunya pada 13 August 2026 adalah Ubuntu 26.10, yaitu rilis yang masih dalam pengembangan. Pada mesin LTS dengan Prompt=lts, flag tersebut mencetak There is no development version of an LTS available. lalu berhenti. Dokumentasi server Ubuntu sendiri menyatakan bahwa rilis development tidak direkomendasikan untuk production, jadi gunakan Prompt=normal jika ingin memperoleh 26.04 yang sudah dirilis lebih awal.

apt update mengembalikan error 404 pada rilis lama. Bagaimana cara meng-upgrade-nya?

Rilis tersebut telah mencapai end of life, sehingga paketnya dipindahkan dari archive.ubuntu.com ke old-releases.ubuntu.com. Ubah hanya nama host dalam /etc/apt/sources.list.d/ubuntu.sources, atau dalam /etc/apt/sources.list pada layout yang lebih lama, dan pertahankan codename yang ada. Kemudian jalankan sudo apt update dan sudo apt full-upgrade. Setelah sistem kembali mutakhir, do-release-upgrade dapat meng-upgrade sistem satu rilis setiap kali.

Apakah saya perlu menghapus PPA sebelum menjalankan do-release-upgrade?

Tidak perlu, karena upgrader akan mengomentari setiap source yang tidak menyediakan paket untuk rilis baru dan mencetak baris seperti was disabled (no Release file) untuk masing-masing source tersebut. Namun, lebih baik jika Anda melakukannya sendiri terlebih dahulu agar dapat menentukan urutannya dan melihat hasilnya. Jalankan apt policy pada paket yang ingin Anda periksa untuk mengetahui paket yang berasal dari setiap PPA, lalu instal ulang paket tersebut dari archive jika versi PPA lebih baru daripada versi yang tersedia pada rilis baru.