Tutorial Ubuntu 26.04 / Menyiapkan dan menjalankan peningkatan rilis Ubuntu LTS

Peningkatan rilis Ubuntu LTS (Long Term Support) mengubah rilis sistem operasi dan berbeda dari pembaruan paket rutin. Jika Anda sudah memasang Ubuntu 26.04, tidak perlu berpindah rilis lain hanya untuk menyelesaikan latihan ini. Gunakan prosedur ini untuk migrasi sistem yang sudah ada, misalnya 24.04 LTS, melalui jalur resmi yang ditawarkan dan dengan rencana pemulihan.

Periksa rilis saat ini dan jalur yang ditawarkan

Jalankan pemeriksaan berikut satu per satu pada sistem Ubuntu yang akan dimigrasikan. Catat rilis dari os-release, kernel yang sedang berjalan, ruang pada / dan /boot, paket yang ditahan, serta masalah basis data dpkg. Tidak adanya keluaran audit atau daftar hold bukan bukti bahwa seluruh layanan siap dimigrasikan.

cat /etc/os-release
uname -r
df -h / /boot
apt-mark showhold
dpkg --audit

Di antara rilis LTS, pindah ke LTS berikutnya secara berurutan. Contohnya, sistem 22.04 perlu melalui 24.04 sebelum 26.04. Jangan mengganti nama suite repositori secara manual untuk melewati rilis atau memakai -d hanya karena peningkatan belum ditawarkan.

Panduan peningkatan rilis Ubuntu Server menjelaskan jalur dan prasyaratnya. Baca juga catatan rilis 26.04, termasuk perubahan untuk versi asal dan lingkungan Anda.

Tim rilis mengumumkan aktivasi jalur 24.04 ke 26.04.1 pada 29 September 2026. Pengumuman umum tidak membuktikan sistem tertentu siap atau sedang mendapat penawaran. Tetap periksa keluaran upgrader karena distribusi dapat menunda atau menghentikan penawaran saat ada masalah yang diketahui.

Siapkan kondisi awal yang dapat dipulihkan

1. Buat cadangan independen dan uji pemulihan pada VM atau direktori lain. Pastikan konsistensi basis data dan volume aplikasi yang harus dipulihkan bersama.
2. Uji migrasi pada klon terisolasi. Jangan mengaktifkan alamat statis dan identitas host duplikat bersamaan dengan server produksi.
3. Pastikan akses konsol, daya yang stabil, kapasitas, jendela pemeliharaan, versi aplikasi yang kompatibel, dan penanggung jawab. Siapkan akses pemulihan di luar sesi SSH yang sedang dipakai.
4. Inventarisasikan repositori pihak ketiga dan perubahan lokal. Aktifkan kembali sumber yang dinonaktifkan hanya setelah dukungan rilis tujuan dipastikan.

Tentukan kondisi yang mengharuskan pemulihan dan data baru yang mungkin harus diselamatkan. Mengembalikan snapshot VM saja dapat membuat keadaan berbeda dari basis data eksternal atau server lain. Catat batas pemulihan dan perubahan eksternal; penurunan versi paket biasa bukan cara membalik seluruh peningkatan rilis.

Perbarui rilis asal hingga kondisinya sehat

Jalankan pembaruan indeks, lalu simulasi berikut. Simulasi menampilkan rencana tindakan tanpa menerapkan peningkatan paket; periksa penghapusan, paket yang ditahan, dan perubahan dependensi.

sudo apt update
apt-get -s dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

Manual apt-get menjelaskan bahwa simulasi tidak mengunci keadaan paket. Akun biasa mungkin tidak dapat membaca seluruh konfigurasi APT; periksa peringatan akses dan tinjau ulang rencana aktual sebelum menyetujui perubahan.

Opsi Always-Include-Phased-Updates di sini membantu memeriksa pembaruan yang diperlukan sebelum peningkatan rilis. Opsi tersebut bukan anjuran umum untuk selalu mendahulukan pembaruan bertahap pada operasi sehari-hari. Selidiki rencana penghapusan yang tidak diharapkan dan lanjutkan hanya setelah hasil diperiksa, cadangan dapat dipulihkan, serta waktu pemeliharaan tersedia.

Jalankan perintah pertama berikut dan pastikan berhasil sebelum memeriksa penanda reboot dengan perintah kedua. dist-upgrade tetap memperbarui paket pada rilis asal; perintah ini sendiri bukan perpindahan ke LTS berikutnya.

sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
test ! -e /run/reboot-required || cat /run/reboot-required

Jika /run/reboot-required ada, baca alasannya dan lakukan reboot terencana sebelum melanjutkan. Pemeriksaan penanda tidak melakukan reboot otomatis; status keluar nol dari perintah kedua juga tidak membuktikan apt sebelumnya berhasil. Setelah reboot yang diperlukan, pastikan rilis asal masih dapat boot, koneksi SSH baru berfungsi, serta jaringan dan aplikasi tetap bekerja.

Selidiki paket tertahan atau keadaan dpkg yang rusak. Jangan menghapus berkas lock atau melepaskan seluruh hold tanpa mengetahui proses dan alasan kebijakannya. Tuntaskan kegagalan pembaruan pada rilis asal sebelum memulai perpindahan rilis.

Periksa ketersediaan lalu jalankan secara interaktif

Siapkan alat pemeriksa dan baca kebijakan penawaran. Periksa keberhasilan tiap perintah secara terpisah.

sudo apt install update-manager-core
grep -E "^Prompt=" /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Untuk kebijakan LTS saja, pastikan nilai efektif Prompt=lts. Jika baris tidak ditemukan atau ada pengaturan yang meragukan, periksa berkas lengkap. Cadangkan /etc/update-manager/release-upgrades sebelum memakai sudoedit untuk menyesuaikan kebijakan; jangan mengganti semua konfigurasi secara otomatis.

Menurut manual do-release-upgrade pada 24.04, -c hanya memeriksa ketersediaan, sedangkan -d berkaitan dengan rilis pengembangan. Jika tidak ada rilis yang ditawarkan, periksa prasyarat dan pesan kesalahan jaringan atau kebijakan. Tunggu jalur yang ditawarkan atau rencanakan server pengganti beserta migrasi data; jangan memaksa penawaran yang belum tersedia.

Perintah berikut memulai proses interaktif pada klon yang disiapkan atau server dalam pemeliharaan yang sudah disetujui. Jangan menjalankannya sekadar untuk melihat contoh keluaran.

sudo do-release-upgrade

Baca ringkasan paket baru, perubahan, dan penghapusan sebelum menerima kelanjutan. Saat diminta memilih konfigurasi, lihat perbedaannya dan tentukan apakah perubahan lokal harus dipertahankan atau digabung dengan versi baru. Memilih jawaban yang sama untuk semua berkas dapat menghilangkan konfigurasi penting atau mempertahankan pengaturan yang sudah tidak sesuai.

Tetap pantau proses dan siapkan respons terhadap pertanyaan. Jika upgrader menyarankan port tambahan untuk pemulihan jarak jauh, batasi akses sesuai klien pengelolaan dan periksa kebutuhan penutupannya setelah selesai. Hindari penghentian paksa dan kehilangan daya. Jika gagal, simpan pesan kesalahan serta catatan /var/log/dist-upgrade, lalu periksa sebelum mengulang tindakan atau melakukan pemulihan.

Periksa layanan setelah reboot

Peningkatan belum selesai hanya karena pemasangan paket berhenti tanpa kesalahan. Lakukan reboot yang diminta, lalu gunakan konsol untuk memeriksa rilis baru dan kernel berjalan dengan pemeriksaan awal tadi.

1. Periksa layanan yang gagal melalui systemctl --failed dan baca status serta log layanan terkait. Jangan menganggap nama rilis baru berarti semua layanan sehat.
2. Periksa alamat, rute, dan DNS sesuai konfigurasi server, lalu uji koneksi SSH baru dari klien yang diizinkan sambil mempertahankan akses konsol.
3. Uji baca/tulis aplikasi, HTTPS dan sertifikat yang disajikan, folder bersama, serta kontainer sesuai beban kerja. Bandingkan dengan hasil pengujian sebelum migrasi.
4. Tinjau paket usang setelah memastikan layanan bekerja dan jalur boot pemulihan tersedia. Aktifkan kembali pembaruan serta cadangan, uji pemulihannya, dan perbarui catatan perubahan.

Jika pemeriksaan gagal, jaga sumber bukti dan perubahan data sejak cadangan terakhir sebelum memulihkan. Gunakan batas pemulihan yang sudah direncanakan agar server ini, penyimpanan eksternal, dan layanan lain kembali konsisten.