Fix GRUB Rescue Error After Disk Resize on KVM

Kecepatan:

Introduction

My client — an edutech company — called me out of nowhere. Voice panicking: “Everything is down!” But this time what caught my interest: the error turned out to be more complex than I expected. Think of it like your front door being locked from the inside — you have knocked several times, but nobody answers. That is what it feels like to hit a connectivity error on a server.

So here is the story — a grub rescue error is one of the errors I come across most often in the field. From handling dozens of cases, I have learned that this error has many “faces” — sometimes it is an easy fix, sometimes it drives you up the wall. Seriously, this problem is tricky.

In this article I will break down this error completely — from the cause, symptoms, fix steps, all the way to prevention so it does not happen again. Everything based on real experience, not empty theory. Let us get started.

Symptoms and Error Messages

The VM fails to boot after a disk resize process. The console stops at the prompt:

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

At the grub rescue> prompt, when you type ls, the output is limited to something like:

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

Or even worse — just (hd0) with no sub-partitions at all. Sub-partitions like msdos1 or gpt1 are completely gone.

Root Cause: Why This Happens

Based on my experience handling dozens of similar cases, this happens because the disk resize process in Virtuozzo hangs or fails midway through.

Here is the analogy: imagine you are widening a road that already has cars parked on the side. The widening process involves rewriting road markings (the partition table). Now, if this widening project fails halfway — whether from a timeout, storage node I/O overload, or a hypervisor crash — what happens is:

The road markings (MBR/dos partition table) collapse — corrupted or completely unreadable.
But the parked cars (data on the ext4 filesystem) are still sitting there untouched.
All that needs to be fixed is the road markings — meaning the partition table.

💡 Pro Tip: Before you panic and think about reformatting, always remember this: “This is not filesystem corruption — this is a messed-up partition table.” Format = data gone. Rebuild partition table = data safe.

Step 1: Enable Rescue Mode

From the Virtuozzo panel, go to the problematic VM, click the Rescue button → Enable Rescue Mode. Select the ISO distribution that matches your VM OS (CentOS/AlmaLinux/Rocky/Debian/Ubuntu).

After rescue mode is active, access via the Console in the Virtuozzo panel. In the rescue environment, the original VM disk usually shows up as /dev/vdb, not /dev/vda (which is the rescue ISO).

fdisk -l /dev/vdb

If the output says “does not contain a valid partition table” — good news. That confirms our suspicion: the partition table is broken, but the data is still safe.

Step 2: Verify Data Is Still Intact

This is the most crucial step that people often skip. Run:

wipefs /dev/vdb

Expected output:

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

What this means: the ext4 filesystem signature is still detected. This is proof that your data is still intact even though the partition table is corrupted.

⚠️ WARNING: DO NOT run wipefs -a /dev/vdb. The -a flag means “all” — it will erase ALL filesystem signatures. Your data will be permanently gone. I have seen a junior engineer do this and the consequences were fatal.

Step 3: Rebuild the Partition Table

Now we rebuild the partition table. Do this carefully:

fdisk /dev/vdb

Inside the fdisk session, follow these steps exactly:

#	Command	Description
1	`g`	Create a new GPT partition table (removes the corrupted MBR/dos)
2	`n`	Create a new partition
3	`1`	Partition number: 1
4	`Enter`	First sector — leave at default (2048)
5	`Enter`	Last sector — leave at default (use the entire disk)
6	`w`	Write changes to disk

⚠️ CRITICAL: After you press w, fdisk will detect the ext4 signature and ask:

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

Answer: N (No). Never answer Y. Y = delete filesystem metadata = data gone. I will say it again: answer N.

💡 Pro Tip: If your reflex answered Y… do not panic yet. As long as there has been no further write operation to the disk, try testdisk or ext4magic for recovery. But the process is 10x more complicated than just answering N in the first place.

Step 4: Repair and Expand the Filesystem

4.1 Check the New Partition

fdisk -l /dev/vdb

Make sure /dev/vdb1 shows up. If it does, we move on.

4.2 Repair the Filesystem

e2fsck -fp /dev/vdb1

The -fp flags = force check + auto-repair. Let e2fsck clean up the inconsistencies caused by the partition table rebuild. This usually takes anywhere from a few seconds to 2 minutes, depending on disk size.

4.3 Resize the Filesystem

Expand the filesystem to the new disk capacity (this is the whole reason you resized in the first place):

resize2fs /dev/vdb1

Verify the final size:

resize2fs -P /dev/vdb1

Step 5: Reinstall GRUB

5.1 Mount and 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 Verify

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

5.4 Cleanup and Reboot

exit
umount -R /mnt

Go back to the Virtuozzo panel, Disable Rescue Mode, then Reboot the VM.

Final Verification

After reboot, check the following:

Item	How to Check	Expected Result
Normal boot	Watch the console	Login prompt appears, no grub rescue
Disk capacity	`lsblk`	Root partition matches the new size (e.g., 90GB)
Filesystem usage	`df -h /`	Usage percentage drops significantly — from 95% down to 40%
Bootloader test	Reboot the VM	No GRUB errors appear

FAQ: Frequently Asked Questions

Q: If I already answered Y at the “remove signature” prompt, can it still be saved?

A: Yes, but it is much harder. The tools: testdisk (scan filesystem signatures) or ext4magic (recover from journal). But the success rate is not 100%. That is why I keep emphasizing: answer N.

Q: Why use GPT instead of MBR/dos for the partition table?

A: GPT is more modern, supports disks larger than 2TB, and has a backup table at the end of the disk. If the primary GPT is corrupted, the backup can be used. MBR/dos does not have this feature.

Q: Does this procedure work for all distros?

A: Yes, for the partition rebuild and filesystem repair parts. The only difference is the GRUB command: CentOS/RHEL uses grub2-install, Debian/Ubuntu uses grub-install. Make sure you chroot into the correct environment before installing GRUB.

Q: How long does the whole process take?

A: Depends on disk size. For a 50-100GB disk: partition rebuild 2 minutes, e2fsck 1-5 minutes, resize2fs 1-5 minutes, GRUB install 1 minute. Total 5-15 minutes. For disks over 500GB, e2fsck and resize2fs can take 20-30 minutes.

Q: What should I avoid when resizing disks in Virtuozzo to prevent this from happening again?

A: Three things: (1) do not resize while the VM is under high I/O, (2) make sure the Virtuozzo storage node is not overloaded, (3) if possible, shut down the VM before resizing — a cold resize is much safer than a hot resize.

Related Issues

If this article helped, you might also need the following guides:

VM stuck in emergency mode after kernel update — different symptoms but similar recovery pattern
LVM extension on CentOS/RHEL — if your partition uses LVM, the procedure is different
VM migration between hypervisors without downtime — an alternative if resizing is too risky

Conclusion

A GRUB rescue “no such partition” error after a disk resize on Virtuozzo KVM is not a disaster. It is just a corrupted partition table. Follow the 5 steps above — rescue mode, data verification, partition rebuild, filesystem repair, GRUB reinstall — and the VM will be back to normal.

The only dangerous point is when fdisk asks “remove signature?” — answer N, and your data is 100% safe.

If you encounter a variation not covered here, or are still stuck after following all the steps, leave a comment. I check daily.

Also read: Fix inode limit reached — cannot create files on VPS: Full Troubleshooting Checklist | Troubleshooting Connection timed out on port 22 on VPS: From Diagnosis to Solution | 502 Bad Gateway on VPS: Causes, Solutions, and Prevention.