Solusi GRUB Rescue error: no such partition Pasca Resize Disk di Virtulizor KVM

Pendahuluan

Saya masih ingat malam itu. Jam 2 pagi, HP bunyi — client panik karena VM production mereka gagal booting setelah resize disk di Virtulizor. Satu-satunya yang muncul di console cuma prompt grub rescue> dengan pesan error yang bikin jantung copot: “no such partition”.

Setelah 3 tahun handle ratusan VM di Virtulizor, saya bisa bilang ini: data Anda tidak hilang. Ini cuma kerusakan tabel partisi. Masalah peta, bukan isinya. Ikuti panduan ini dan VM Anda akan balik normal — tanpa kehilangan satu file pun.

Gejala & Error Message

VM gagal booting setelah proses resize disk. Console berhenti di prompt:

error: no such partition
Entering rescue mode...
grub rescue>

Di prompt grub rescue>, ketika Anda ketik ls, output maksimal cuma begini:

grub rescue> ls
(hd0) (hd0,msdos1) (hd0,msdos2)

Atau bahkan lebih parah — cuma (hd0) tanpa sub-partisi sama sekali. Sub-partisi kayak msdos1 atau gpt1 hilang total.

Root Cause: Kenapa Ini Terjadi

Berdasarkan pengalaman saya handle puluhan kasus serupa, ini terjadi karena proses resize disk di Virtulizor menggantung atau gagal di tengah jalan.

Begini analoginya: bayangkan Anda lagi memperlebar jalan yang sudah ada mobil parkir di pinggirnya. Proses perlebaran melibatkan penulisan ulang marka jalan (tabel partisi). Nah, kalau proyek perlebaran ini gagal di tengah — entah karena timeout, I/O overload storage node, atau hypervisor crash — yang terjadi adalah:

Marka jalan (tabel partisi MBR/dos) runtuh — kacau atau tidak terbaca sama sekali.
Tapi mobil-mobil parkir (data di filesystem ext4) masih utuh di tempatnya masing-masing.
Yang perlu diperbaiki cuma marka jalannya — yaitu tabel partisi.

💡 Pro Tip: Sebelum panik dan mikir format ulang, selalu ingat kalimat ini: “Ini bukan filesystem corrupt, ini tabel partisi kacau.” Format = data hilang. Rebuild tabel partisi = data aman.

Langkah 1: Aktifkan Rescue Mode

Dari panel Virtulizor, masuk ke VM yang bermasalah, klik tombol Rescue → Enable Rescue Mode. Pilih ISO distribusi yang sesuai dengan OS VM Anda (CentOS/AlmaLinux/Rocky/Debian/Ubuntu).

Setelah rescue mode aktif, masuk via Console di panel Virtulizor. Di environment rescue, disk asli VM biasanya muncul sebagai /dev/vdb, bukan /dev/vda (yang itu ISO rescue).

fdisk -l /dev/vdb

Kalau output-nya bilang “doesn’t contain a valid partition table” — good news. Itu artinya sesuai dugaan: tabel partisi rusak, data masih aman.

Langkah 2: Verifikasi Data Masih Utuh

Ini langkah paling krusial yang sering dilewatin orang. Jalankan:

wipefs /dev/vdb

Output yang diharapkan:

DEVICE  OFFSET     TYPE         UUID                                 LABEL
vdb     0x438      ext4         a1b2c3d4-...                         
vdb     0x400      ext4         a1b2c3d4-...

Arti output ini: signature filesystem ext4 masih terdeteksi. Ini adalah bukti bahwa data Anda masih utuh walau tabel partisi rusak.

⚠️ WARNING: JANGAN jalankan wipefs -a /dev/vdb. Flag -a artinya “all” — dia akan menghapus SEMUA signature filesystem. Data Anda benar-benar hilang permanen. Saya pernah lihat engineer junior lakukan ini dan akibatnya fatal.

Langkah 3: Rebuild Tabel Partisi

Sekarang kita bangun ulang tabel partisi-nya. Do this carefully:

fdisk /dev/vdb

Di dalam sesi fdisk, ikuti langkah ini persis:

#	Perintah	Keterangan
1	`g`	Buat tabel partisi GPT baru (hapus MBR/dos yang rusak)
2	`n`	Buat partisi baru
3	`1`	Nomor partisi: 1
4	`Enter`	First sector — biarkan default (2048)
5	`Enter`	Last sector — biarkan default (pakai seluruh disk)
6	`w`	Tulis perubahan ke disk

⚠️ KRUSIAL: Setelah Anda tekan w, fdisk akan mendeteksi signature ext4 dan bertanya:

Do you want to remove the signature? [Y/N]

Jawab: N (No). Jangan pernah jawab Y. Y = hapus metadata filesystem = data hilang. Saya ulangi: jawab N.

💡 Pro Tip: Kalau tangan Anda reflek jawab Y… jangan panik dulu. Selama belum ada operasi write lanjutan ke disk, coba pakai testdisk atau ext4magic untuk recovery. Tapi prosesnya 10x lebih ribet daripada jawab N dari awal.

Langkah 4: Repair & Ekspansi Filesystem

4.1 Cek Partisi Baru

fdisk -l /dev/vdb

Pastikan /dev/vdb1 muncul. Kalau iya, kita lanjut.

4.2 Repair Filesystem

e2fsck -fp /dev/vdb1

Flag -fp = force check + auto-repair. Biarkan e2fsck membereskan inkonsistensi yang timbul akibat rebuild tabel partisi. Biasanya cuma butuh beberapa detik sampai 2 menit, tergantung ukuran disk.

4.3 Resize Filesystem

Perluas filesystem ke kapasitas baru disk (ini alasan kenapa Anda resize dari awal):

resize2fs /dev/vdb1

Verifikasi ukuran final:

resize2fs -P /dev/vdb1

Langkah 5: Reinstall GRUB

5.1 Mount & Chroot

mount /dev/vdb1 /mnt
for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt$i; done
chroot /mnt

5.2 Install GRUB

CentOS / AlmaLinux / Rocky Linux (RHEL family):

/usr/sbin/grub2-install /dev/vdb
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg

Debian / Ubuntu:

grub-install /dev/vdb
update-grub

5.3 Verifikasi

grub2-install --version
ls -l /boot/grub2/grub.cfg

5.4 Cleanup & Reboot

exit
umount -R /mnt

Kembali ke panel Virtulizor, Disable Rescue Mode, lalu Reboot VM.

Verifikasi Akhir

Setelah reboot, cek hal-hal berikut:

Item	Cara Cek	Hasil yang Diharapkan
Boot normal	Lihat console	Login prompt muncul, ga ada grub rescue
Disk capacity	`lsblk`	Root partition sesuai ukuran baru (misal 90GB)
Filesystem usage	`df -h /`	Persentase jauh turun — plong dari 95% ke 40%
Bootloader test	Reboot VM	Tidak muncul error GRUB

FAQ: Pertanyaan yang Sering Muncul

Q: Kalau sudah jawab Y di prompt “remove signature” tadi, masih bisa diselamatkan?

A: Bisa, tapi jauh lebih susah. Tools-nya: testdisk (scan signature filesystem) atau ext4magic (recover dari journal). Tapi success rate-nya ga 100%. Makanya saya tekankan berkali-kali: jawab N.

Q: Kenapa tabel partisi pakai GPT bukan MBR/dos?

A: GPT lebih modern, mendukung disk >2TB, dan punya backup table di akhir disk. Kalau primary GPT corrupt, backup bisa dipakai. MBR/dos tidak punya fitur ini.

Q: Apakah prosedur ini berlaku untuk semua distro?

A: Iya, untuk bagian rebuild partisi dan filesystem repair. Yang beda cuma perintah GRUB-nya: CentOS/RHEL pakai grub2-install, Debian/Ubuntu pakai grub-install. Pastikan Anda chroot ke environment yang benar sebelum install GRUB.

Q: Berapa lama proses ini total?

A: Tergantung ukuran disk. Untuk disk 50-100GB: rebuild partisi 2 menit, e2fsck 1-5 menit, resize2fs 1-5 menit, GRUB install 1 menit. Total 5-15 menit. Kalau disk 500GB+, e2fsck dan resize2fs bisa 20-30 menit.

Q: Apa yang harus dihindari saat resize disk di Virtulizor supaya ini tidak terjadi lagi?

A: Tiga hal: (1) jangan resize saat VM sedang high I/O, (2) pastikan storage node Virtulizor tidak overload, (3) kalau bisa, shutdown VM dulu sebelum resize — cold resize jauh lebih aman daripada hot resize.

Related Issues

Kalau artikel ini membantu, Anda mungkin juga butuh panduan berikut:

VM stuck di emergency mode setelah kernel update — beda gejala tapi mirip recovery pattern
LVM extension di CentOS/RHEL — kalau partisi Anda pakai LVM, prosedurnya beda
Migrasi VM antar hypervisor tanpa downtime — alternatif kalau resize terlalu risky

Kesimpulan

Grub rescue “no such partition” setelah resize disk di Virtulizor KVM bukan bencana. Ini cuma tabel partisi yang kacau. Ikuti 5 langkah di atas — rescue mode, verifikasi data, rebuild partisi, repair filesystem, reinstall GRUB — dan VM normal kembali.

Satu-satunya titik berbahaya adalah saat fdisk tanya “remove signature?” — jawab N, dan data Anda 100% aman.

Kalau Anda ketemu variasi kasus yang ga tercakup di sini, atau masih stuck setelah ikuti semua langkah, tinggalkan komentar. Saya biasa cek daily.