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

1. PENDAHULUAN & GEJALA MASALAH

VM Anda tidak bisa boot setelah resize disk di Virtulizor. Layar berhenti di prompt grub rescue> dengan pesan:

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

Ketika diketik ls di prompt tersebut, output hanya menunjukkan:

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

…atau bahkan yang lebih parah, hanya menyisakan (hd0) tanpa sub-partisi sama sekali.

Sub-partisi seperti msdos1 atau gpt1 hilang total — hanya raw disk (hd0) yang terdeteksi.

Analisis Root Cause

Masalah ini terjadi karena proses resize disk di Virtulizor yang menggantung atau gagal di tengah jalan. Saat Virtulizor memperluas disk, ia menulis ulang tabel partisi (MBR/dos). Jika proses ini terputus — entah karena timeout, overload I/O, atau crash hypervisor — yang terjadi adalah:

Pagar pembatas (tabel partisi MBR/dos) runtuh — struktur partisi menjadi kacau atau tidak terbaca.
Namun metadata/signature filesystem (ext4) di dalam cluster disk sebenarnya masih utuh.
Data VM tidak hilang. Hanya petanya (tabel partisi) yang perlu dibangun ulang.

Kesimpulan: Ini bukan kerusakan data. Ini kerusakan peta. Jangan panik, jangan format.

2. PROSEDUR ISOLASI & PENYELAMATAN DATA (RECOVERY MODE)

2.1. Aktifkan Rescue Mode

Dari panel Virtulizor, aktifkan Rescue Mode untuk VM yang bermasalah. Pilih distribusi ISO yang sesuai (CentOS/AlmaLinux/Rocky/Debian/Ubuntu). Setelah aktif, masuk via Console atau SSH Rescue.

2.2. Identifikasi Disk VM

Di lingkungan rescue, disk asli VM biasanya muncul sebagai /dev/vdb (bukan /dev/vda yang merupakan disk rescue ISO).

fdisk -l /dev/vdb

Jika output menunjukkan “doesn’t contain a valid partition table” atau tabel partisi kacang, lanjut ke step verifikasi signature:

wipefs /dev/vdb

Anda akan melihat output seperti ini — ini TANDA BAIK:

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

Arti dari output wipefs di atas: Signature ext4 masih utuh walau tabel partisi rusak. Ini konfirmasi bahwa data aman.

JANGAN jalankan wipefs -a dalam kondisi apapun. Itu akan menghapus signature dan membuat data benar-benar hilang.

3. LANGKAH EKSEKUSI REBUILD TABEL PARTISI (TANPA FORMAT DATA)

Kita akan membangun ulang pagar partisi menggunakan fdisk. Target: satu partisi utama (/dev/vdb1) yang mencakup seluruh kapasitas disk.

fdisk /dev/vdb

Di dalam sesi fdisk, ikuti langkah berikut secara berurutan:

Langkah	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 (gunakan seluruh disk)
6	`w`	Tulis perubahan

⚠️ PERINGATAN KRUSIAL — BACA INI DENGAN SEKSAMA:

Setelah menekan w, jika fdisk mendeteksi signature ext4 dan bertanya:

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

JAWAB: N (No)

JANGAN PERNAH memilih Y. Memilih Y akan menghapus metadata filesystem dan Anda akan kehilangan semua data. Signature inilah yang membuat filesystem masih bisa dikenali setelah rebuild.

Jika Anda terlanjur memilih Y — data masih bisa diselamatkan selama belum ada proses write lanjutan, tetapi akan membutuhkan alat recovery terpisah seperti testdisk atau ext4magic yang tidak dibahas di artikel ini.

4. EKSPANSI FILESYSTEM & REINSTALL BOOTLOADER (CHROOT)

4.1. Cek Partisi Baru

fdisk -l /dev/vdb

Pastikan /dev/vdb1 muncul dengan ukuran yang sesuai (misal 90GB setelah resize).

4.2. Cek dan Repair Filesystem

e2fsck -f /dev/vdb1

Biarkan e2fsck memperbaiki inkonsistensi yang mungkin timbul karena perubahan tabel partisi. Ketik y jika ada prompt perbaikan, atau gunakan -p untuk auto-repair:

e2fsck -fp /dev/vdb1

4.3. Online Resize Filesystem

Perluas filesystem ke kapasitas baru disk:

resize2fs /dev/vdb1

Verifikasi:

resize2fs -P /dev/vdb1

4.4. Mount & Chroot

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

4.5. Reinstall GRUB

Untuk distro RedHat-based (CentOS/AlmaLinux/Rocky Linux 7/8/9):

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

Untuk CentOS 6 atau versi lawas yang masih menggunakan GRUB Legacy:

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

Untuk distro Debian/Ubuntu-based:

grub-install /dev/vdb
update-grub

4.6. Verifikasi GRUB

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

5. KESIMPULAN & VERIFIKASI AKHIR

5.1. Cleanup & Reboot

exit
umount -R /mnt

Matikan Rescue Mode dari panel Virtulizor, lalu Reboot VM via panel.

5.2. Checklist Verifikasi

Item	Perintah Cek	Harapan
Boot normal	Lihat console VM	Login prompt muncul tanpa error GRUB
Disk capacity	`lsblk` atau `df -h`	Root partition terdeteksi dengan ukuran baru (misal 90GB)
Filesystem usage	`df -h /`	Persentase penggunaan turun drastis — plong dari 95% ke 40% misalnya
Bootloader	Reboot test	Tidak muncul prompt grub rescue

5.3. Final Notes

Jika setelah reboot VM masih stuck di grub rescue, ulangi langkah 3-4. Kemungkinan ada mismatch antara device name di GRUB dan partisi aktual. Di chroot, regenerate GRUB seperti langkah 4.5.

Seluruh prosedur di atas zero data loss jika diikuti dengan disiplin. Satu-satunya risiko ada di langkah 3 saat menjawab prompt “remove signature” — jawab N, dan data Anda aman.

Dokumentasi ini bersifat taktis untuk piket malam. Jika menemukan variasi kasus yang tidak tercakup, dokumentasikan di artikel terpisah.