Cara Memulihkan Upgrade Ubuntu yang Gagal di Tengah

Upgrade Ubuntu gagal di tengah proses: baca gejalanya terlebih dahulu

Upgrade rilis Ubuntu dari 24.04 ke 26.04 yang gagal akan meninggalkan server dalam salah satu dari empat kondisi, dan setiap kondisi memerlukan perbaikan yang berbeda. Proses upgrade mungkin masih berjalan di dalam sesi screen yang koneksinya terputus. dpkg mungkin telah dihentikan saat sebuah paket masih setengah dikonfigurasi, sehingga apt kini menolak semua tindakan yang menginstal, menghapus, atau meng-upgrade paket, meskipun apt update dan perintah hanya-baca seperti apt show masih dapat dijalankan. Sumber apt mungkin menyebut 26.04, sementara paket yang terinstal masih berasal dari 24.04. Atau server mungkin sama sekali tidak dapat melakukan boot. Tentukan kondisi yang terjadi sebelum mengetik apa pun, karena perbaikan untuk satu kondisi dapat memperburuk kondisi lainnya.

Satu aturan berlaku untuk keempat kondisi tersebut. Jangan reboot sampai Anda mengetahui status dpkg. Reboot saat proses penggantian paket masih berlangsung dapat mengubah interupsi dpkg yang masih dapat diperbaiki menjadi kondisi server yang tidak dapat melakukan boot, seperti yang dibahas menjelang akhir panduan ini. Jangan memulai proses apt atau dpkg kedua saat proses pertama mungkin masih berjalan, karena dua proses yang menulis database paket dapat menyebabkan database rusak.

Panduan ini mengasumsikan Anda mengikuti panduan upgrade 24.04 ke 26.04 dan membuat snapshot sebelum memulai. Jika tidak, baca bagian boot dengan mempertimbangkan hal tersebut, karena snapshot adalah solusi untuk kondisi terburuk.

Apakah upgrade masih berjalan?

Banyak upgrade yang dilaporkan gagal sebenarnya masih berjalan. Sesi SSH terputus, terminal menjadi kosong, dan upgrader tetap berjalan tanpa Anda.

do-release-upgrade dirancang untuk menangani kondisi ini. Saat berjalan dengan antarmuka teks, seperti yang digunakan pada server, do-release-upgrade membungkus dirinya dalam sesi GNU screen. Dengan demikian, upgrade tetap berjalan meskipun terminal yang memulainya terputus. Selain itu, saat mendeteksi bahwa dirinya dijalankan dari sesi SSH, do-release-upgrade menawarkan untuk memulai sshd kedua pada port lain, yaitu 1022 secara default. Anda tetap dapat login jika daemon SSH utama rusak selama proses penggantian paket. Kedua hal ini penting dalam kondisi tersebut.

Sambungkan kembali melalui SSH dan cari sesi screen. Upgrader berjalan di bawah sudo, sehingga sesi screen tersebut dimiliki oleh root. Perintah screen -ls biasa sebagai pengguna Anda sendiri tidak akan menampilkannya.

sudo screen -ls

screen -ls menandai setiap sesi sebagai attached atau detached. Jika ada satu sesi yang tercantum, sambungkan kembali ke sesi tersebut. Jika statusnya masih attached karena koneksi SSH yang terputus belum melepaskannya, -d akan melepaskan attachment yang sudah tidak aktif itu terlebih dahulu.

sudo screen -d -r

Jika ada lebih dari satu sesi, tambahkan nama sesi dari screen -ls setelah -r. Jangan mengandalkan sudo do-release-upgrade untuk menyambungkan Anda kembali secara otomatis. Kode yang menemukan sesi screen yang sudah ada berada di dalam upgrader yang diunduhnya. Sebelum mengunduh apa pun, do-release-upgrade keluar dengan pesan "Please install all available updates for your release before upgrading" jika menemukan paket yang masih menunggu upgrade, kecuali phased updates. Kondisi ini persis seperti sistem yang sedang berada di tengah proses penggantian paket. Setelah tersambung kembali, Anda akan kembali ke proses upgrade yang masih berjalan. Biasanya proses tersebut sedang menunggu jawaban atas prompt tentang file konfigurasi yang berubah atau restart service. Jawab prompt tersebut dan biarkan proses selesai.

Jika Anda memulai upgrade di dalam tmux, seperti yang direkomendasikan panduan upgrade, sambungkan kembali ke tmux terlebih dahulu dengan tmux attach. Sesi screen berjalan di dalam pane tmux tersebut, sehingga upgrade akan langsung terlihat. Jika pane hanya menampilkan shell prompt, upgrader tidak lagi berjalan di sana, dan sudo screen -ls adalah pemeriksaan berikutnya.

Jika port SSH utama menolak koneksi, coba port cadangan: ssh -p 1022 user@host. Daemon tersebut hanya ada selama upgrade berlangsung. Jika Anda tidak dapat masuk melalui kedua port, gunakan console dari provider Anda. Dari console, sudo ss -ltnp menampilkan port yang sedang digunakan untuk listening oleh proses sshd, sedangkan sudo ufw status menunjukkan apakah firewall mengizinkan akses ke port cadangan.

Jika tidak ada sesi screen dan tidak ada proses yang menunggu di console, upgrade memang sudah berhenti. Pastikan tidak ada proses yang masih menggunakan database paket sebelum Anda memperbaikinya:

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

Hasil kosong berarti dpkg sedang idle dan Anda dapat melanjutkan proses perbaikan. Proses dpkg atau apt dengan waktu berjalan yang lama, tanpa sesi screen yang dapat disambungkan kembali, berarti proses tersebut hang. Tunggu beberapa menit, periksa console untuk melihat apakah ada pertanyaan debconf yang belum dijawab, lalu hentikan proses tersebut hanya jika memang diperlukan. Jangan pernah menghapus file lock di bawah /var/lib/dpkg/ atau /var/lib/apt/lists/ saat masih ada proses yang menggunakannya. Lock tersebut adalah satu-satunya hal yang mencegah dua proses penulisan merusak database paket.

dpkg terinterupsi dan apt menolak berjalan

Jika dpkg dihentikan antara proses membongkar paket dan menjalankan skrip konfigurasinya, paket tersebut akan ditandai sebagai belum selesai dan meninggalkan entri yang belum selesai dalam jurnalnya di /var/lib/dpkg/updates/. Setiap perintah apt yang mengambil lock dpkg, yaitu perintah yang memasang, menghapus, atau meningkatkan versi paket, akan memeriksa jurnal tersebut terlebih dahulu dan berhenti dengan dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.. Perintah yang tidak pernah mengambil lock tersebut, seperti apt update, apt list, apt show, dan apt-cache, tetap dapat berjalan sehingga Anda masih dapat memeriksa sistem. Apa pun keluaran lain yang ditampilkan apt, langkah pertama tetap sama.

sudo dpkg --configure -a

Perintah ini menyelesaikan tahap konfigurasi untuk setiap paket yang sudah dibongkar tetapi belum dikonfigurasi. Perintah ini menjalankan skrip maintainer sesuai urutan dependensi. Pada sistem yang proses upgrade-nya terhenti di tengah jalan, proses ini dapat berlangsung lama, jadi tunggu hingga selesai. Jika berhenti pada suatu paket, perintah ini menampilkan nama paket dan skrip yang gagal. Catat nama tersebut. Paket itulah yang menghentikan proses upgrade Anda. Bagian berikut menjelaskan cara membaca error-nya.

Selanjutnya, biarkan apt memperbaiki dependensi yang belum terpenuhi akibat interupsi tersebut. Beberapa paket mungkin sudah di-upgrade, sedangkan paket yang menjadi dependensinya belum.

sudo apt --fix-broken install

Selanjutnya, selesaikan proses upgrade yang sebelumnya sedang dijalankan oleh program upgrade:

sudo apt update
sudo apt full-upgrade

Gunakan full-upgrade, bukan upgrade, karena upgrade rilis dapat menghapus paket, sedangkan upgrade biasa menolak menghapus apa pun. Baca ringkasan yang ditampilkan apt sebelum memberikan konfirmasi. Daftar penghapusan yang singkat adalah hal yang normal. Namun, daftar yang menghapus ubuntu-server, systemd, openssh-server, atau paket kernel bukan hal yang normal. Jawab no dan cari tahu alasan apt ingin menghapusnya sebelum melanjutkan.

Periksa hasilnya sebelum melakukan hal lain:

sudo dpkg --audit
sudo apt-get check

dpkg --audit menampilkan setiap paket yang masih berada dalam kondisi rusak, sedangkan apt-get check melaporkan dependensi yang belum terpenuhi. Keduanya seharusnya tidak menampilkan apa pun. Jika sudah demikian, jalankan sudo apt autoremove untuk menghapus dependensi yang dipasang otomatis dan sudah tidak diperlukan. Paket yang ditandai sebagai dipasang secara manual tetap dipertahankan meskipun tidak ada yang menggunakannya. Setelah itu, konfirmasikan rilis dengan cat /etc/os-release, lalu jalankan sudo update-initramfs -u -k all dan sudo update-grub. Setelah semua langkah tersebut selesai, lakukan reboot.

Cara membaca /var/log/dist-upgrade untuk menemukan paket yang menghentikan proses

Program upgrade menulis semua informasi ke /var/log/dist-upgrade/. Jika Anda telah menjalankannya lebih dari sekali, log dari percobaan sebelumnya dipindahkan ke subdirektori yang namanya berisi timestamp. Karena itu, periksa ls -la /var/log/dist-upgrade/ terlebih dahulu dan baca direktori yang sesuai dengan proses yang gagal.

main.log adalah catatan aktivitas program upgrade itu sendiri. File ini mencatat fase yang sedang dijalankan dan keputusan program terkait source Anda. Jika program upgrade mengalami crash, traceback Python juga terdapat di sini. Baca file ini dari bagian akhir. Baris terakhir menunjukkan fase saat proses berhenti. Jika terdapat traceback, berarti tool yang gagal, bukan paket.

apt.log berisi alasan resolver dependensi mengambil keputusan tertentu. Isinya panjang dan penting ketika apt menolak menghitung upgrade sama sekali. Ini berarti kegagalan terjadi sebelum paket apa pun diproses. Jika proses upgrade sudah sampai pada tahap memasang paket, biasanya Anda dapat melewati file ini.

apt-term.log adalah file yang perlu diperiksa ketika terjadi kegagalan pada paket. File ini merekam output terminal dpkg selama proses upgrade, yaitu teks yang biasanya akan bergulir di layar. Paket terakhir yang disebut sebelum bagian akhir adalah paket yang sedang diproses ketika upgrade berhenti. Jika skrip maintainer gagal, pesan dpkg tentang kegagalan tersebut terdapat di sana, bersama error dari skrip itu tepat di atasnya.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

Bandingkan hasilnya dengan /var/log/dpkg.log, yang mencatat perubahan status dan tindakan yang dilakukan dpkg, masing-masing dengan timestamp. tail -n 30 /var/log/dpkg.log menampilkan paket terakhir yang disentuh dpkg dan tindakan yang sedang dilakukan terhadap paket tersebut. Ini menjadi jawaban yang sama dari sumber kedua hanya jika belum ada proses lain yang menjalankan dpkg sejak kegagalan. Setelah Anda menjalankan dpkg --configure -a atau apt --fix-broken install, entri dari perintah tersebut akan berada di bagian akhir. Karena itu, gulir kembali ke baris dengan timestamp saat proses upgrade berhenti.

Sebagian besar kegagalan pada tahap ini di server disebabkan oleh beberapa hal. Service yang di-restart oleh paket dalam postinst gagal start karena file konfigurasinya telah Anda ubah. systemctl status bersama journalctl -xeu pada service tersebut menunjukkan baris yang tidak dapat diterimanya. Disk dapat penuh, biasanya /boot karena kernel lama atau /var karena cache paket apt, dan df -h / /boot /var menunjukkan kondisi tersebut. sudo apt clean mengosongkan cache meskipun apt sedang mengalami kebuntuan. Sementara itu, disk yang melaporkan penuh saat du menyatakan sebaliknya memiliki penjelasan tersendiri. Paket dari repository pihak ketiga yang dinonaktifkan oleh program upgrade mungkin bergantung pada library yang tidak lagi disertakan oleh 26.04. Paket yang ditahan (apt-mark showhold) dapat menghalangi perubahan versi suatu dependensi. Perbaiki penyebabnya, lalu jalankan kembali sudo dpkg --configure -a. Perintah tersebut melanjutkan proses dari titik terakhir.

Jika satu paket tetap menolak dikonfigurasi, apa pun yang Anda lakukan, dan tidak ada hal penting yang bergantung padanya, hapus paket tersebut lalu pasang kembali setelah upgrade selesai:

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

Gunakan cara ini hanya pada paket yang dapat Anda sebutkan dan jelaskan fungsinya. Jangan gunakan cara ini pada library atau apa pun yang berada dalam rantai dependensi ubuntu-server, karena penghapusan paksa melewati pemeriksaan yang seharusnya memberi tahu Anda komponen lain yang akan rusak.

Sumber berubah, tetapi paket belum berubah

Pemutakhir menulis ulang sumber apt di tahap awal, sebelum mengunduh paket apa pun. Jika proses terhenti setelah tahap tersebut, sumber akan menyebut 26.04, sedangkan paket yang terpasang merupakan campuran beberapa versi. Campuran ini membingungkan alat pengelola paket. Karena itu, do-release-upgrade mungkin sekarang menyatakan bahwa tidak ada rilis baru.

Bandingkan dua lokasi yang menjelaskan rilis yang sedang digunakan. /etc/apt/sources.list.d/ubuntu.sources adalah file sumber deb822 yang diperkenalkan pada 24.04. Baris Suites: di dalamnya memuat codename rilis. /etc/os-release ditulis oleh paket base-files dan menyatakan rilis yang sebenarnya terpasang.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

Ada tiga kombinasi yang perlu diperhatikan. Jika sumber masih menyebut 24.04 (codename noble) dan os-release juga masih menyatakan 24.04, pemutakhiran belum melewati tahap pemeriksaan. Anda dapat menjalankan sudo do-release-upgrade lagi setelah membaca main.log untuk mengetahui penyebab proses berhenti. Perintah tersebut tidak akan memulai proses jika masih ada pembaruan 24.04 yang tertunda atau jika /var/run/reboot-required.pkgs menyebut libc6, linux-base, atau paket linux-image. Karena itu, jalankan sudo apt full-upgrade dan reboot terlebih dahulu jika file tersebut memintanya. Jika sumber menyebut codename 26.04, sedangkan os-release masih menyatakan 24.04, pertukaran paket sudah dimulai tetapi terhenti. Perbaikan dpkg pada bagian sebelumnya, yang diakhiri dengan apt full-upgrade, adalah cara untuk menyelesaikannya. Jangan jalankan ulang pemutakhir dalam kondisi ini. Dengan paket 26.04 yang masih menunggu, pemutakhir akan berhenti dan meminta Anda memasang semua pembaruan yang tersedia terlebih dahulu. Jika sumber menyebut 26.04 dan os-release juga menyatakan 26.04, base-files merupakan salah satu paket yang berhasil terpasang. Sistem sekarang mengidentifikasi dirinya sebagai 26.04, meskipun sebagian besar komponennya mungkin belum diperbarui.

Kombinasi terakhir adalah jebakannya. do-release-upgrade menentukan rilis yang digunakan berdasarkan informasi yang sama dengan yang dibawa oleh os-release. Jika os-release sudah menyatakan 26.04, alat tersebut akan mencari rilis yang lebih baru daripada 26.04. Karena tidak menemukannya, alat tersebut melaporkan bahwa tidak ada rilis baru. Alat tersebut menjawab pertanyaan berdasarkan os-release, sedangkan os-release berisi informasi yang keliru. Jangan lagi meminta pemutakhir untuk melanjutkan proses. Selesaikan dengan apt: jalankan sudo apt update, lalu sudo apt full-upgrade. Perintah kedua memutakhirkan paket yang masih menggunakan versi 24.04, kecuali paket yang ditahan (apt-mark showhold menampilkan paket tersebut), dan mungkin menghapus beberapa paket. Karena itu, baca ringkasannya, lalu jalankan sudo apt autoremove. Alasan lain do-release-upgrade melaporkan tidak ada rilis baru, seperti perintah LTS yang menunggu rilis poin pertama, juga perlu disingkirkan jika os-release masih menyatakan 24.04.

Pemutakhir juga menonaktifkan sumber pihak ketiga di bawah /etc/apt/sources.list.d/ dan menyimpan salinan cadangan setiap file yang diubah, dengan menambahkan sufiks pada nama aslinya. Jalankan ls -la /etc/apt/sources.list.d/ dan diff pada setiap file asli beserta cadangannya untuk melihat perubahan yang dibuat secara tepat. Biarkan entri pihak ketiga tetap dinonaktifkan sampai paket Ubuntu konsisten. Setelah itu, aktifkan kembali setiap entri hanya setelah memastikan bahwa vendornya menyediakan paket untuk 26.04. Jika apt update melaporkan bahwa suatu sumber dikonfigurasi lebih dari satu kali, entri sources.list lama dan entri ubuntu.sources baru menjelaskan suite yang sama. Error sumber duplikat deb822 menjelaskan entri mana yang harus dihapus.

Server tidak dapat melakukan boot setelah upgrade

Reboot akan memperlihatkan dampak upgrade yang belum selesai. Pada VPS, penyebab yang paling mungkin adalah kernel yang terinstal tanpa initramfs, konfigurasi GRUB yang tidak pernah dibuat ulang, package yang dibiarkan dalam status belum dikonfigurasi padahal diperlukan oleh unit saat boot, atau disk yang penuh ketika dpkg sedang menulis data.

Buka console provider sebelum melakukan tindakan lain. Console menunjukkan proses boot berhenti di mana: menu GRUB, kernel panic, pemeriksaan filesystem yang menunggu jawaban, atau systemd emergency shell yang meminta password root. Satu pengamatan ini menentukan langkah berikutnya.

Jika GRUB muncul, boot kernel 24.04 sebelumnya dari submenu advanced options. Kernel lama biasanya tetap terinstal sampai autoremove dijalankan. Setelah sistem berjalan menggunakan kernel lama, jalankan sudo dpkg --configure -a dan perbaikan lain dari bagian sebelumnya, lalu sudo update-initramfs -u -k all dan sudo update-grub sebelum mencoba kernel baru lagi. Memulihkan VPS yang gagal boot setelah pembaruan kernel menjelaskan bagian GRUB dan initramfs secara terperinci.

Jika Anda masuk ke emergency shell, root filesystem biasanya di-mount dalam mode read-only. Mount ulang filesystem tersebut, lalu jalankan perbaikan yang sama:

mount -o remount,rw /
dpkg --configure -a

Jika sistem sama sekali tidak mencapai shell, boot rescue image dari provider, mount disk VPS, lalu lakukan perbaikan dari chroot. Temukan partisi root dengan lsblk, bukan dengan menebak namanya.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

Sebelum menghabiskan waktu satu jam di dalam chroot, bandingkan pilihan tersebut dengan snapshot. Anda membuat snapshot sebelum memulai, dan pada sebagian besar provider snapshot dapat dipulihkan dalam hitungan menit. Setelah itu, jalankan kembali upgrade. Proses ini biasanya memerlukan waktu jauh di bawah satu jam pada VPS, dan kali ini Anda sudah mengetahui package mana yang harus diperbaiki. Memulihkan snapshot merupakan pilihan yang lebih cepat jika salah satu kondisi berikut terpenuhi: Anda tidak dapat mengakses console atau rescue image, Anda tidak dapat menentukan nama package yang menghentikan upgrade, lebih dari satu package macet, atau server menjalankan layanan yang sedang ditunggu pengguna. Perbaikan manual hanya lebih cepat jika Anda mengetahui satu hal yang rusak dan perbaikannya cukup dengan satu perintah.

Salin /var/log/dist-upgrade/ dari server sebelum memulihkan snapshot. Jika itu satu-satunya cara untuk masuk, salin dari rescue image. Proses pemulihan akan menghapus log tersebut. Percobaan kedua akan gagal dengan cara yang sama jika Anda tidak pernah mengetahui penyebab kegagalan pertama. Hal yang dapat dan tidak dapat dipulihkan oleh snapshot layak dibaca sebelum Anda mengandalkannya. Snapshot mengembalikan seluruh disk ke kondisi sebelumnya, termasuk menghapus data apa pun yang ditulis setelah snapshot dibuat. Ini sesuai dilakukan di tengah upgrade, tetapi tidak sesuai dilakukan seminggu kemudian.

Tiga tanda bahwa sistem sebaiknya dibangun ulang

Sebagian upgrade tidak layak diselamatkan. Memulihkan snapshot lalu menjalankan kembali proses upgrade memang murah, tetapi jika kegagalan disebabkan oleh kondisi sistem itu sendiri, proses kedua juga akan gagal. Solusi yang tepat adalah menggunakan image 26.04 yang baru dan memulihkan data dari backup. Tiga tanda berikut menunjukkan bahwa Anda berada dalam kondisi tersebut.

Pertama, database milik dpkg rusak. Jika dpkg --audit atau apt-get check sama sekali tidak dapat membaca /var/lib/dpkg/status, alih-alih melaporkan paket yang rusak di dalamnya, catatan paket yang terpasang berarti sudah hilang. Ubuntu menyimpan salinan harian di bawah /var/backups/ (ls -la /var/backups/dpkg.status*), dan mengganti file tersebut dengan salinan terbaru yang masih baik terkadang dapat menyelesaikan masalah. Namun, jika salinan itu tidak sesuai dengan kondisi sebenarnya di disk, Anda hanya menebak. Setiap proses apt berikutnya akan dibangun berdasarkan tebakan tersebut.

Kedua, alat yang diperlukan untuk memperbaiki sistem juga rusak. Jika apt atau dpkg tidak dapat dijalankan karena shared library telah dihapus atau hanya terganti sebagian, atau systemd tidak dapat memulai unit karena paketnya sendiri baru dikonfigurasi sebagian, tidak ada package manager yang berfungsi untuk memperbaiki package manager tersebut. ldd /usr/bin/apt menunjukkan apakah semua library milik apt tersedia. Terkadang Anda dapat memulihkan sistem dari kondisi ini menggunakan chroot pada rescue image, tetapi waktu yang diperlukan biasanya lebih lama daripada membangun ulang sistem.

Ketiga, daftar paket yang rusak tidak berkurang. Jika Anda telah menjalankan dpkg --configure -a dan apt --fix-broken install berulang kali selama lebih dari satu jam, dan setiap proses menemukan paket baru alih-alih menyelesaikan paket sebelumnya, berarti sistem membawa masalah ke dalam proses upgrade yang tidak disebabkan oleh upgrade tersebut: file di bawah /usr yang diedit secara manual, paket yang dipin atau ditahan, repository pihak ketiga yang mengganti library inti, atau upgrade sebelumnya yang sebenarnya belum selesai. Image baru tidak memiliki masalah tersebut. Memulihkan data ke dalamnya juga membutuhkan waktu lebih singkat daripada mencari sumber masalahnya.

Membangun ulang sistem hanya murah jika data disimpan di tempat lain, bukan di server tersebut. Itulah perbedaan antara snapshot dan backup, serta alasan panduan upgrade meminta keduanya.

FAQ

Apakah saya bisa langsung menjalankan do-release-upgrade lagi setelah prosesnya terhenti?

Jangan menjadikannya langkah pertama. Jika upgrader masih berjalan dalam screen session, sambungkan kembali dengan sudo screen -d -r. Perintah do-release-upgrade kedua akan berhenti sebelum mencapai kode untuk menyambungkan kembali session-nya sendiri, karena perintah tersebut menolak berjalan selama masih ada paket yang menunggu upgrade. Jika upgrader sudah berhenti, jalankan sudo dpkg --configure -a dan sudo apt --fix-broken install terlebih dahulu. Jika source sudah mencantumkan 26.04, selesaikan dengan sudo apt full-upgrade, bukan dengan upgrader. Jika source masih mencantumkan 24.04, jalankan sudo apt full-upgrade, reboot jika /var/run/reboot-required.pkgs mencantumkan libc6, linux-base, atau kernel, lalu jalankan kembali upgrader. Proses ini juga menolak berjalan jika Prompt=never ditetapkan dalam /etc/update-manager/release-upgrades, atau jika server Ubuntu melaporkan "Release upgrade not possible right now".

Mengapa do-release-upgrade menyatakan tidak ada rilis baru setelah upgrade saya gagal?

Karena base-files, yaitu paket yang menulis /etc/os-release, termasuk salah satu paket yang berhasil di-upgrade sebelum proses terhenti. Kini tool tersebut membaca file itu, menyimpulkan bahwa Anda menggunakan 26.04, dan tidak menemukan rilis yang lebih baru untuk ditawarkan. Bandingkan grep VERSION_ID /etc/os-release dengan grep Suites /etc/apt/sources.list.d/ubuntu.sources, lalu selesaikan dengan sudo apt update && sudo apt full-upgrade.

Apakah aman melakukan reboot pada server Ubuntu yang proses upgrade-nya belum selesai?

Belum, sampai sudo dpkg --audit tidak mengembalikan apa pun. Reboot saat kernel sudah di-unpack tetapi belum dikonfigurasi, atau saat GRUB belum dibuat ulang, merupakan penyebab paling umum upgrade yang sebenarnya dapat diperbaiki dalam sepuluh menit berubah menjadi pekerjaan pemulihan melalui rescue image. Selesaikan perbaikan dpkg dan apt full-upgrade, jalankan update-initramfs -u -k all dan update-grub, lalu lakukan reboot.

Bagaimana cara mengetahui paket yang menghentikan proses upgrade?

Baca bagian akhir /var/log/dist-upgrade/apt-term.log, yang berisi output terminal dari dpkg. Paket terakhir yang disebut sebelum log berakhir adalah paket yang sedang diproses. Jika maintainer script gagal, pesan error-nya tercetak tepat di atas pesan kesalahan dari dpkg. /var/log/dpkg.log merupakan sumber informasi kedua. Baris dengan timestamp saat upgrade berhenti akan menyebutkan paket yang sama. Namun, setiap perintah yang Anda jalankan melalui dpkg setelah itu akan dicatat setelah baris tersebut, sehingga baris terakhirnya mungkin tidak menunjukkan paket yang gagal. Jika main.log justru berakhir dengan Python traceback, berarti upgrader itu sendiri mengalami crash dan tidak ada paket yang menjadi penyebabnya.

Apakah saya harus memulihkan snapshot atau terus memperbaiki sistem?

Pulihkan snapshot jika Anda tidak dapat mengetahui paket yang gagal, lebih dari satu paket macet, Anda tidak memiliki akses console, atau server harus segera kembali beroperasi. Lanjutkan perbaikan hanya jika Anda mengetahui satu hal yang rusak dan perbaikannya cukup dengan satu perintah. Salin /var/log/dist-upgrade/ ke luar server sebelum melakukan pemulihan. Jika tidak, percobaan kedua akan gagal dengan cara yang sama.