Panduan Fix Kernel Panic AlmaLinux yang Gak Boot: 7 Langkah Cepat dari Pengalaman NOC

Skip basa-basi. Server kamu gak boot, layar hitam, atau stuck di pesan kernel panic sebelum login muncul. Ini dia panduan fix kernel panic AlmaLinux yang gak boot — dari yang paling cepet sampai yang paling dalam. Ikuti berurutan, jangan di-skip.

Sebelum masuk ke command, inget satu hal: kernel panic itu bukan akhir dunia. Ini cuma cara Linux bilang “gak aman buat lanjut, berhenti dulu”. Ibaratnya motor yang mati mesin pas di lampu merah — bikin jengkel, tapi hampir selalu bisa dinyalain lagi kalau kamu tau penyebabnya.

Yang sering gak disadari orang: kernel panic saat boot itu bukan satu masalah, tapi kumpulan kemungkinan yang gejalanya mirip. Makanya langkah paling penting pertama kali adalah baca pesan errornya dulu. Jangan asal restart. Restart berulang tanpa diagnosis itu kayak pencet tombol power TV berkali-kali berharap channel-nya ganti sendiri.

Apa Itu Kernel Panic dan Kenapa Bisa Terjadi di AlmaLinux?

Kernel panic di AlmaLinux adalah kondisi di mana kernel Linux gak bisa lanjut kerja dan berhenti total. Biasanya muncul pesan kayak “Kernel panic – not syncing” atau “Unable to mount root fs”. Server yang lagi boot bakal stuck, gak ada prompt login, dan harus di-restart manual.

Dari pengalaman handle ratusan server, penyebab paling umum kernel panic pas boot di AlmaLinux kurang lebih begini:

• /boot penuh — file kernel baru ketulis setengah-setengah dan korup.
• Kernel update gagal — initramfs gak kebangun bener.
• Root filesystem gak ketemu — UUID berubah, driver storage gak ke-load.
• Driver hardware bermasalah — seringnya GPU atau NIC di mesin fisik.
• RAM atau disk mulai rusak — kernel gagal baca area tertentu.
• GRUB config salah — entry kernel nyasar.

Impact-nya gak main-main kalau ini server production. Setiap menit down itu revenue hilang, antrian email numpuk, client nelpon, dan management ngechat. Karena itu kamu butuh prosedur fix yang cepet tapi aman — dan itu yang bakal aku jabarin step-by-step di bawah.

Step 1: Baca Dulu Pesan Error di Layar

Kunci fix kernel panic AlmaLinux adalah baca pesan yang muncul di layar sebelum restart. Foto atau catat. Ini tabel buat langsung nge-match:

Dari tabel di atas, dua baris pertama yang paling sering kejadian di production: “Unable to mount root fs” dan “Fatal exception”. Kalau kamu dapet salah satu dari dua ini, lanjut ke step 2 — kemungkinan besar selesainya di situ.

Step 2: Boot ke Kernel Sebelumnya di GRUB

Kalau kernel panic muncul setelah update kernel, langkah paling cepet: boot ke kernel lama. Pas server nyala, di menu GRUB pilih Advanced options for AlmaLinux, terus pilih kernel versi sebelumnya — yang terakhir ke-load normal.

Kalau menu GRUB gak muncul, tekan Esc atau Shift berkali-kali pas server mulai boot. Di VPS KVM biasanya perlu timing yang agak telat, tapi mayoritas jalan pake Esc.

Kenapa ini penting? Kalau bisa boot ke kernel lama, berarti root cause-nya hampir pasti di kernel baru atau initramfs-nya. Dan ini yang paling sering: update kernel gagal tapi filenya setengah jalan karena /boot penuh.

Step 3: Cek /boot Penuh Gak

Boot ke kernel lama dulu, terus cek ini:

df -h /boot
ls -lh /boot

Kalau usage-nya 100% atau nyaris penuh — ini dia biang keladinya. Update kernel butuh ruang buat nulis vmlinuz baru, initramfs, dan symlink. Gak ada ruang = file korup = kernel panic pas boot. Bener-bener kasus klasik yang masih aja kejadian.

Fix-nya: hapus kernel lama yang gak dipake. Tapi sebelum hapus, pastiin kamu gak lagi boot di kernel yang mau dihapus:

uname -r

Itu kernel yang lagi jalan — jangan diutak-atik. Sisanya yang versi lebih tua bisa dibersihin. Buat daftarnya:

dnf list installed kernel-core

Nah, sebelum hapus, inget dulu:

Contoh: kernel yang jalan 4.18.0-553, dan kamu mau hapus 4.18.0-513:

dnf remove kernel-core-4.18.0-513*

Abis itu rebuild initramfs biar bersih:

dracut -f

Step 4: Rebuild Initramfs atau Reinstall Kernel

Kalau /boot masih lega tapi kernel baru tetep panic, coba rebuild initramfs. Initramfs itu kotak P3K yang dipake kernel pas boot — isinya driver dan tool buat mount root filesystem. Kalau dia korup atau outdated, root gak bakal ke-mount, dan muncullah panic.

dracut -f --regenerate-all

Kalau tetep gak mempan, reinstall kernel-core yang bermasalah. Ini nge-write ulang file kernel dan initramfs dari nol dari repo resmi AlmaLinux:

dnf reinstall kernel-core kernel-modules

Terus generate ulang GRUB config. Kalau boot mode BIOS:

grub2-mkconfig -o /boot/grub2/grub.cfg

Kalau UEFI, path-nya beda dikit:

grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

Step 5: Cek UUID dan /etc/fstab

Error “Unable to mount root fs” juga sering muncul karena UUID yang di-referensi di fstab atau parameter kernel GRUB udah gak match sama kondisi disk sekarang. Ini bisa kejadian abis disk di-attach ulang, abis clone VPS, atau abis resize.

blkid
cat /etc/fstab

Bandingin UUID di fstab sama output blkid. Buat gambaran disk secara visual:

lsblk -f

Kalau beda, update UUID di fstab (atau parameter root= di GRUB). Jangan lupa: kalau bingung partisi mana yang mana, mending tahan dulu dan double-check daripada salah mount.

Step 6: Boot Rescue dengan Kernel Parameter

Kalau semua di atas gak jalan, masuk mode rescue dari rescue ISO AlmaLinux. Kalau di VPS KVM, bisa lewat VNC ke GRUB. Di menu GRUB, tekan e buat edit entry, cari baris yang mulai dengan linux, tambahin di akhir baris:

rd.break

Ini nge-drop kamu ke ramdisk sebelum root di-mount — berguna banget buat debug fstab. Kalau curiga driver video atau GPU yang bikin panic, tambahin juga:

nomodeset

Dan biar kernel panic gak bikin server loop restart, set timeout:

panic=30

Simpan perubahan dengan Ctrl+X. Mode ini gak persist, tapi cukup buat boot sekali dan liat log.

Step 7: Diagnosa dari Log Kernel

Kalau server bisa boot setelah step di atas, langsung cek log boot yang gagal. journalctl nyimpen history boot, jadi bisa liat boot sebelumnya yang panic:

journalctl -b -1 -k -p err --no-pager

Ini contoh log asli dari server yang gagal boot karena UUID root berubah — perhatiin pola baris per barisnya:

Aug 02 02:13:41 server-01 kernel: sd 2:0:0:0: [sda] No Caching mode page found
Aug 02 02:13:41 server-01 kernel: sd 2:0:0:0: [sda] Assuming drive cache: write through
Aug 02 02:13:41 server-01 kernel: dracut: Mounted root filesystem /dev/sda2
Aug 02 02:13:41 server-01 kernel: dracut: Switching root
Aug 02 02:13:41 server-01 kernel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Aug 02 02:13:41 server-01 kernel: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-362.24.1.el9_3.x86_64
Aug 02 02:13:41 server-01 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Aug 02 02:13:41 server-01 kernel: Call Trace:
Aug 02 02:13:41 server-01 kernel: dump_stack+0x5f/0x80
Aug 02 02:13:41 server-01 kernel: panic+0x17e/0x340
Aug 02 02:13:41 server-01 kernel: mount_block_root+0x1a4/0x2a0
Aug 02 02:13:41 server-01 kernel: prepare_namespace+0x143/0x180
Aug 02 02:13:41 server-01 kernel: kernel_init_freeable+0x236/0x260
Aug 02 02:13:41 server-01 kernel: kernel_init+0x1a/0x130

Baca polanya:

• Baris 3-4: initramfs (dracut) berhasil mount root sementara dan mau “Switching root”. Ini normal.
• Baris 5: ERROR — “Unable to mount root fs on unknown-block(0,0)”. Ini baris yang paling penting: kernel switch ke root asli gagal karena device gak ketemu.
• Baris 6-14: call trace biasa dari kernel panic — gak perlu dipelototin, yang penting baris 5.

Dari sini, langkah diagnosanya jelas: cek parameter root= di GRUB dan UUID di fstab vs blkid. Root cause di kasus ini: abis clone, UUID disk berubah, tapi fstab masih nyebut UUID lama.

Pro Tips: Biar Gak Kejadian Lagi

• Selalu sisain ruang di /boot minimal 500MB. Pasang monitoring disk usage biar ketahuan duluan sebelum update kernel.
• Setelah update kernel, jangan langsung reboot. Cek dulu file kernel dan initramfs-nya ketulis lengkap: ls -lh /boot | grep 5.14
• Kalau server di KVM, selalu ada snapshot atau backup sebelum touch kernel. Lebih murah daripada panik jam 2 pagi.
• Set default kernel GRUB ke versi stabil sebelum update besar. Caranya: grub2-editenv list buat liat saved_entry, terus atur manual.

Artikel Terkait

• Troubleshoot VPS KVM Boot Loop: Step-by-Step
• 7 Perintah Cek Partisi Disk Penuh di Linux
• Panduan Monitoring Server Production untuk NOC
• Cara Update Kernel AlmaLinux yang Aman

Gitu doang sih. Intinya: baca pesannya, boot kernel lama, cek /boot, rebuild initramfs, baru mikirin hardware. Sebelum close ticket, pastiin udah cek: 1) log error, 2) ruang /boot, 3) UUID root. Kalau semua oke, case closed. Done.