Cara Fix Error Upgrade AlmaLinux ELevate: Panduan Step-by-Step Lengkap

Tolong ya, jangan upgrade production server kalau belum nyiapin jaring pengaman dulu. Serius nih. Bukan maksudku sok jagoan, tapi aku udah berkali-kali lihat server client yang berubah jadi batu bata gara-gara upgrade ELevate yang error di tengah jalan. Padahal fix error upgrade AlmaLinux ELevate itu sebenernya bisa dicegah dari awal, kalau mau meluangkan waktu. Dan bagian yang paling nyesek? Hampir semua gagal karena kesalahan yang sama.

Gak kerasa ya, CentOS 7 itu udah lama banget masuk EOL, dan baru sekarang banyak yang panik mau migrasi. Nah, justru di momen panik itulah kesalahan fatal paling gampang terjadi. Makanya artikel ini aku tulis dari sudut pandang yang udah kena berkali-kali, biar kamu gak ngalamin hal yang sama. Baca sampai habis, oke?

Oke, kita luruskan dulu biar gak salah paham soal istilah. ELevate itu tool yang dikembangkan tim AlmaLinux buat in-place major version upgrade, misalnya dari AlmaLinux 8 ke AlmaLinux 9, atau migrasi CentOS 7 ke AlmaLinux 8. Di balik layar, tool ini pakai framework leapp dari Red Hat plus data upgrade resmi dari Red Hat Upgrade Tool. Konsepnya sebenernya pintar dan udah teruji di banyak kasus. Tapi di dunia nyata, upgrade major version semacam ini jarang banget mulus tanpa persiapan matang, apalagi kalau server-nya udah dipake bertahun-tahun dan penuh paket aneh yang nempel dari zaman dulu.

Yang bikin gemes, error-nya biasanya muncul bukan di awal, tapi pas sistem udah setengah jalan. Kalau udah kena fase itu, kamu gak bisa cuma “restart terus beres”. Kadang harus rollback ke snapshot, kadang harus restore total, dan kalau backup-nya gak ada, ya cuma doa yang bisa bantu. Itulah kenapa langkah pertama di artikel ini bukan soal error-nya, tapi soal nyiapin jaring pengaman dulu. Jangan dilewatin, meskipun kamu merasa “ah, ini cuma server kecil”.

Aku juga mau jujur dari awal: sebagian error ELevate itu sebenernya gampang banget dibenerin. Cuma masalahnya, teks error-nya kelihatan horor padahal solusinya cuma ngisi satu baris di answer file, atau menghapus satu paket yang gak didukung. Nah, di artikel ini aku kumpulin error paling umum yang aku temuin di lapangan, plus cara fix-nya satu-satu. Jangan diskip, apalagi kalau kamu handle server yang dipake client atau banyak user sekaligus.

Kenapa Error Upgrade ELevate Sering Terjadi?

Sebelum masuk ke daftar error, penting buat paham kenapa proses ini sering banget gagal. Sebenernya akar masalahnya cuma beberapa hal, dan sisanya cuma efek samping dari situasi yang sama. Lima penyebab yang paling sering aku temuin di lapangan:

• Repository yang gak kompatibel — repo third-party kayak EPEL versi lama, Remi, atau repo custom yang nempel sejak zaman CentOS 7, sering bikin leapp nolak jalan.
• Paket yang diblokir atau gak didukung — kernel custom, driver propietary, atau paket yang cuma tersedia di distro lama bakal bikin transaksi RPM gagal di tengah jalan.
• Disk space gak cukup — leapp butuh ruang kosong di beberapa direktori penting. Kalau / udah mau penuh, upgrade dijamin gagal.
• Gak baca laporan preupgrade — ini yang paling nyebelin. leapp preupgrade itu udah ngasih tahu masalah apa aja yang bakal muncul, tapi banyak yang langsung skip.
• Answer file belum diisi — beberapa pertanyaan konfirmasi (misal soal VDO) harus dijawab dulu. Kalau gak, upgrade langsung berhenti di tengah.

Intinya, hampir semua error yang bakal kita bahas di bawah itu muncul dari lima hal di atas. Kalau kamu bisa duduk tenang, cek satu per satu, dan gak buru-buru, sebagian besar masalah bakal kelar sebelum proses upgrade dimulai. Makanya step-by-step di artikel ini aku urutin biar kamu gak bolak-balik mikir “kok bisa gini sih”.

Seperti Apa Error-nya di Lapangan?

Biar kamu gak kaget, ini contoh potongan log dari leapp-upgrade.log pas upgrade gagal di tengah jalan. Perhatiin polanya: awal cuma warning, makin lama makin serius, dan di akhir ketauan root cause-nya.

2026-08-02 02:11:07.123 INFO Preparing system for upgrade
2026-08-02 02:11:09.487 WARNING One or more repositories are disabled
2026-08-02 02:11:14.002 WARNING Package zram-generator is not supported in target OS
2026-08-02 02:11:22.877 INFO Executing RPM transaction (phase 1/2)
2026-08-02 02:11:28.331 ERROR Transaction check error:
2026-08-02 02:11:28.331 ERROR   file /usr/lib/modules-load.d/zram.conf conflicts between
2026-08-02 02:11:28.332 ERROR   attempted installs of zram-generator and kmod-zbud
2026-08-02 02:11:28.910 ERROR Upgrade cannot continue, please check the report

Baris pertama sampai ketiga itu gejala. Sistem lagi nyiapin upgrade, terus muncul warning soal repo yang mati dan paket zram-generator yang gak didukung. Baris tengah, “Transaction check error”, itu pola yang muncul pas RPM nyoba nge-install dan ketemu file yang bentrok. Nah, baris terakhir itu root cause-nya: ada konflik file antara zram-generator dan kmod-zbud. Kalau dibaca dari atas ke bawah, semuanya nyambung ke satu masalah yang sama: paket zram yang gak didukung di target OS. Dan ini semua bisa dihindari dari awal kalau laporan preupgrade dibaca teliti.

Peringatan Keras Sebelum Upgrade

Step 1 — Backup dan Snapshot Dulu

Ini bukan saran, ini syarat. Upgrade major version itu ibarat pindah rumah: semua barang udah masuk truk, baru ketauan ada lemari yang gak muat. Nah, di fase itu kamu gak bisa mundur. Snapshot di panel VPS (Proxmox, Vultr, DigitalOcean, dan lain-lain) itu paling gampang dan paling aman. Kalau server-nya bare-metal, pakai backup penuh kayak image rsync atau tool backup yang biasa kamu pake.

Setelah snapshot jadi, verifikasi. Buka menu snapshot, pastikan udah kebentuk, kalau bisa tes restore di server lain dulu. Aku pernah lihat kasus snapshot-nya ternyata gagal kebentuk tapi gak ada yang ngecek, pas butuh malah gak ada. Nggih, jangan sampe.

Step 2 — Update Semua Paket dan Bersihkan Cache

Server yang udah jalan lama biasanya punya ratusan paket yang ketinggalan update. Update dulu semua, bersihin cache, lalu pastikan versi OS dan kernel-nya jelas.

cat /etc/redhat-release
uname -r
dnf update -y
dnf clean all

Kalau kamu masih di CentOS 7, perintahnya pakai yum, bukan dnf. Dan penting: pastikan kernel-nya yang terbaru dari repo resmi, bukan kernel custom. ELevate butuh kernel standar biar modul leapp-nya bisa dimuat pas reboot. Kernel custom yang aneh-aneh itu biasanya sumber inhibitor “Unable to load kernel module”.

Step 3 — Periksa dan Matikan Repository Bermasalah

List semua repo yang aktif, lalu matikan repo third-party yang gak dibutuhkan selama upgrade. Kalau dimatiin, kamu bisa nyalain lagi setelah upgrade selesai.

dnf repolist
dnf config-manager --set-disabled epel

Repo kayak EPEL, Remi, dan repo sejenisnya sering nahan upgrade karena ada paket di dalamnya yang bentrok sama target OS. Kamu gak perlu hapus paketnya dulu di tahap ini, cukup disable repo-nya aja. Nanti pas preupgrade, laporan yang bakal ngasih tahu paket mana yang musti dibuang. Kalau nemu repo yang udah gak jelas asal-usulnya, lebih baik disable semua dulu biar aman.

Step 4 — Install ELevate dan leapp

Pakai repositori resmi dari repo.almalinux.org. Perintahnya beda dikit antara AlmaLinux 8 dan CentOS 7.

# AlmaLinux 8
dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm -E %rhel).noarch.rpm
dnf install -y leapp-upgrade leapp-data-almalinux

# CentOS 7
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm -E %rhel).noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux

Setelah install, cek versinya biar yakin gak ada yang kelewat:

rpm -qa | grep -Ei "leapp|elevate"

Kalau dua-duanya keliatan, lanjut ke tahap preupgrade.

Step 5 — Jalankan leapp preupgrade

Ini langkah yang paling sering dilewatin, padahal justru yang paling penting. leapp preupgrade gak mengubah apa pun di sistem, dia cuma baca kondisi server dan nulis laporan. Jalanin dengan tenang, dan siapin kopi dulu karena bisa agak lama, tergantung jumlah paket.

leapp preupgrade

Kalau prosesnya selesai tanpa masalah berarti bagus. Tapi jangan seneng dulu, biasanya ada aja inhibitor atau warning yang harus dibaca. Cek laporannya di langkah berikutnya.

Step 6 — Baca Laporan dengan Teliti

Semua hasil preupgrade disimpan di /var/log/leapp/. File yang paling penting adalah leapp-report.txt. Ini contoh laporan yang sering banget aku lihat di server production:

[INHIBITOR] Some installed RPMs are blocked
Summary: The following RPMs are known to be problematic:
  - kmod-zbud-3.0-1.el8.x86_64
  - zram-generator-0.1.4-3.el8.x86_64
These packages are not supported in the target OS and must be removed.
Remediation: [command]dnf remove kmod-zbud zram-generator[/command]
Risk Factor: high

[INHIBITOR] Required space for the ''' directory is not sufficient
Summary: A required space of about 525 MB is missing on the ''' filesystem.
Remediation: [command]dnf clean all && rm -rf /var/cache/dnf/*[/command]
Risk Factor: high

[CONF] Custom SSH configuration file was detected
Summary: The system is configured with a custom sshd_config.
Remediation: Review and manually apply necessary changes after the upgrade.
Risk Factor: low

Nah, perhatiin polanya. Bagian [INHIBITOR] itu artinya proses bakal berhenti kalau gak diselesaikan. Baris “Summary” jelasin apa masalahnya, dan baris “Remediation” ngasih tau perintah fix-nya. Baris [CONF] dan [WARN] cuma peringatan, gak menghentikan upgrade, tapi tetep harus diperhatiin. Kalau ada yang bikin penasaran, kamu bisa baca versi detailnya di leapp-preupgrade.json.

Jangan pernah skip laporan ini. Mungkin keliatan panjang, tapi justru di sini semua solusi udah dikasih tau sama leapp. Kamu tinggal eksekusi perintah remediasinya satu-satu.

Step 7 — Beresin Semua Inhibitor

Hapus paket yang diblokir

Kalau laporan nyebut paket tertentu yang harus dihapus, pastikan dulu paket itu beneran yang dimaksud dan memang gak kepake:

rpm -qa | grep -Ei "zbud|zram"

Cek output-nya. Kalau yang muncul cuma paket yang memang gak kamu pake, baru hapus. Kalau ada yang ragu, tanyain dulu ke tim atau catat dulu nama paketnya. Jangan asal hapus, apalagi kalau paket itu ternyata dipake aplikasi tertentu di atasnya.

dnf remove kmod-zbud zram-generator

Isi answer file

Kalau di laporan ada inhibitor yang isinya pertanyaan konfirmasi (biasanya soal VDO atau modul lain), kamu harus jawab duluan. Caranya gampang:

leapp answer --add --section check_vdo.confirm=True

Atau kamu juga bisa edit file answerfile langsung di /var/log/leapp/answerfile. Buka file-nya, cari baris yang masih default, terus ubah jadi True. Yang penting jawabannya udah jelas sebelum upgrade jalan, biar gak berhenti di tengah.

Kosongkan ruang disk

Kalau inhibitor-nya soal space, cek dulu partisi mana yang kekurangan:

df -h / /usr /var /boot

Lalu kosongin cache dan log yang gak perlu. Perhatiin dulu isi direktori cache-nya sebelum hapus:

ls /var/cache/dnf/
dnf clean all
rm -rf /var/cache/dnf/*
journalctl --vacuum-size=200M

Setelah itu cek lagi df -h. Kalau masih kurang, perbesar partisi lewat panel atau resize filesystem.

Jalanin preupgrade lagi

Setelah semua inhibitor di-fix, jalanin leapp preupgrade sekali lagi buat mastiin bersih:

leapp preupgrade

Kalau gak ada inhibitor baru yang muncul, baru lanjut ke tahap berikutnya. Monggo, pelan-pelan aja gak apa-apa. Lebih baik lama dikit daripada upgrade gagal di tengah.

Step 8 — Jalankan leapp upgrade

Ini tahap yang sebenernya. leapp upgrade bakal nyiapin sistem, download paket, dan pasang semuanya. Setelah selesai, sistem bakal minta reboot, dan di fase reboot inilah proses upgrade beneran kelar. Kalau kamu akses lewat SSH, koneksi bakal putus. Itu normal, jangan panik.

leapp upgrade

Tips dari pengalaman: jalankan leapp upgrade dari tmux atau screen biar kalau koneksi SSH kamu putus di tengah jalan, prosesnya tetep jalan dan log-nya tetep kebaca nanti. Dan jangan, aku ulangi, JANGAN reboot manual pas proses ini masih jalan. Biarin leapp yang ngatur reboot-nya sendiri.

Step 9 — Reboot dan Verifikasi

Setelah leapp selesai dan minta reboot, baru kamu reboot:

reboot

Sesudah nyala lagi, cek versi OS-nya:

cat /etc/redhat-release
cat /etc/os-release
uname -r

Kalau keluarnya AlmaLinux 9 dan kernel-nya versi baru, berarti upgrade sukses. Terakhir, aktifin lagi repo yang tadi kamu matiin, terus jalanin update kecil buat ngebenerin sisa paket yang mungkin beda versi:

dnf config-manager --set-enabled epel
dnf update -y

Pro Tips dari Pengalaman

• Selalu tes di staging dulu. Clone server production, upgrade di clone-nya, baru sentuh yang asli. Ini nyawa.
• Pilih maintenance window yang longgar. Upgrade bisa makan waktu 20-60 menit di fase persiapan, belum lagi reboot-nya.
• Siapin akses console (noVNC/KVM) dari panel VPS. Kalau SSH putus dan server gak balik, console adalah jalur penyelamatan.
• Catat kernel dan versi OS sebelum upgrade, biar gampang dibandingin pas verifikasi.
• Jangan jalanin leapp upgrade dua kali. Kalau yang pertama gagal, cek laporan dulu, baru perbaiki dan ulangi.

Tabel Troubleshooting Error Umum

Ini rangkuman error yang paling sering aku temuin, lengkap sama penyebab dan solusinya. Simpan tabel ini, bisa jadi referensi cepat pas ada ticket masuk.

Error Message	Penyebab	Solusi
Could not retrieve the upgrade data for 8.9 to 9.4	Repo data elevation gak kebaca atau akses ke repo.almalinux.org terganggu	Cek koneksi internet dan isi file /etc/leapp/files/leapp_upgrade_repositories.repo
Required space for the ”’ directory is not sufficient	Partisi / gak cukup ruang	Kosongkan cache dan log, atau perbesar partisi
Some installed RPMs are blocked	Paket gak didukung target OS	Hapus paket sesuai remediasi di laporan
Transaction check error	Konflik antar RPM	Disable repo third-party dan hapus paket yang bentrok
Detected VDO feature (perlu konfirmasi)	Parameter wajib belum dijawab	Isi answer file dengan leapp answer
You need to be root	Jalan leapp pake user biasa	Login as root atau sudo su
Unable to load kernel module	Kernel terlalu lama atau custom	Update kernel ke versi terbaru dari repo resmi
Server gak balik setelah reboot	Upgrade gagal di fase boot	Akses console, boot ke kernel lama, lalu rollback atau restore snapshot

FAQ

Artikel Terkait

Kalau kamu baru mau nyiapin server sebelum upgrade, atau mau mastiin server tetep aman setelah upgrade, beberapa artikel ini bisa bantu:

• Panduan lengkap backup server produksi — wajib dibaca sebelum upgrade apa pun.
• Monitoring server dengan Netdata — biar bisa pantau kondisi server setelah upgrade.
• Cara hardening SSH server — jaga akses server setelah proses upgrade.

Tolong ya, jangan ngulang kesalahan yang sama kayak yang aku ceritain di atas. Sebelum close ticket atau sebelum mulai upgrade, pastiin kamu udah cek tiga hal: 1) backup dan snapshot yang beneran bisa direstore, 2) laporan leapp preupgrade yang udah dibaca teliti, 3) answer file yang udah diisi. Kalau tiga itu beres, upgrade ELevate bakal jalan jauh lebih mulus. Take it seriously, ya. Matur nuwun udah baca sampai sini.