Rescue ISO Recovery: Repair Bootloaders & GRUB Errors

When a VPS fails to boot, the issue usually lies deep in the bootloader or the root filesystem. Most cloud providers, including AtoZNode, supply a “Rescue ISO” that boots the server into a lightweight, network‑enabled environment. From that environment you can repair GRUB, rebuild the bootloader, or chroot into the damaged system and run standard Linux utilities.

What Is a Rescue ISO and When Do You Need It?

• Rescue ISO is a small Linux image that runs entirely from RAM. It is typically based on Debian/Ubuntu or AlmaLinux/Rocky.
• The image provides SSH access, a functional network stack, and common tools such as fdisk, lsblk, mkfs, and grub‑install.
• Typical scenarios that require a rescue environment:
  • Corrupted GRUB configuration or a missing grub.cfg.
  • Accidental overwrite of the /boot partition.
  • Filesystem errors that prevent the kernel from mounting the root partition.
  • Mis‑configured fstab that drops the system to an emergency shell.

Booting Into the Rescue ISO

Log in to the AtoZNode control panel, select your VPS, and choose the “Rescue Mode” or “Boot from ISO” option. Attach the provided ISO image and reboot the instance. Once the server finishes booting, it will assign an IP address and provide SSH credentials (usually the same root password you use for the normal system).

Connect via SSH:

ssh root@<VPS_IP>

After logging in you will see a prompt that looks like #. The rescue system is now ready for you to mount the broken disks.

Identifying and Mounting the Affected Disks

First, list all block devices:

# lsblk -f

Identify the partition that contains your root filesystem (e.g., /dev/vda1 or /dev/sda2). Note its filesystem type (ext4, XFS, Btrfs) and any mount‑point label.

Mount the root partition to /mnt (replace the device name as needed):

# mount /dev/vda1 /mnt

If you have a separate /boot partition, mount it under the chroot as well:

# mkdir -p /mnt/boot
# mount /dev/vda2 /mnt/boot

For LVM setups, activate the volume groups first:

# vgchange -ay
# mount /dev/mapper/vg-root /mnt
# mount /dev/mapper/vg-boot /mnt/boot   # if a separate boot LV exists

Repairing GRUB on Debian/Ubuntu‑Based VPSes

These steps assume the rescue ISO is based on Debian/Ubuntu. All commands are executed in the rescue environment before entering the chroot.

1. Bind‑mount essential pseudo‑filesystems:

# mount --bind /dev  /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys  /mnt/sys
# mount --bind /run  /mnt/run

1. Enter the chroot:

# chroot /mnt /bin/bash

You are now operating inside the broken system as if it had booted normally.

1. Update the GRUB configuration:

# update-grub

This command scans all partitions for kernels, generates a new /boot/grub/grub.cfg, and writes it to disk.

1. Re‑install GRUB to the boot device:

# grub-install /dev/vda

Replace /dev/vda with the actual disk identifier (e.g., /dev/sda). The command writes the bootloader to the MBR or EFI partition, depending on the system.

1. Exit and clean up:

# exit
# umount -R /mnt
# reboot

The VPS should now boot normally. If it still drops to a GRUB rescue prompt, double‑check that the root and prefix variables point to the correct partitions.

Repairing GRUB on AlmaLinux/Rocky/RHEL‑Based VPSes

For systems that use dnf, the workflow is similar but the commands differ slightly.

1. Bind‑mount pseudo‑filesystems (same as above):

# mount --bind /dev  /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys  /mnt/sys
# mount --bind /run  /mnt/run

1. Enter the chroot:

# chroot /mnt /bin/bash

1. Reinstall the GRUB packages (optional but useful if files are missing):

# dnf reinstall grub2-efi grub2-common

This ensures the GRUB binaries are present and match the kernel version.

1. Generate a fresh GRUB configuration file:

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

On UEFI systems the path may be /boot/efi/EFI/almalinux/grub.cfg. Adjust accordingly.

1. Install GRUB to the disk:

# grub2-install /dev/vda

For UEFI you may need to reinstall the EFI boot entry:

# efibootmgr -c -d /dev/vda -p 1 -L "AlmaLinux" -l \\EFI\\almalinux\\grubx64.efi

1. Exit and reboot:

# exit
# umount -R /mnt
# reboot

Using Chroot for General System Repairs

Beyond GRUB, the rescue environment lets you run any standard Linux tool on the broken system. Common tasks include:

• Filesystem checks: fsck.ext4 /dev/vda1 (run on the unmounted partition).
• Repairing fstab entries: Edit /etc/fstab inside the chroot with nano or vi to correct UUIDs or mount options.
• Reinstalling missing packages: apt install --reinstall linux-image-generic or dnf reinstall kernel.
• Updating initramfs: update-initramfs -u -k all (Debian/Ubuntu) or dracut --force (RHEL‑based).

Inside the chroot the environment behaves like a normal booted system, so you can also check logs (journalctl -xb), reset passwords (passwd), or modify network configuration files.

Windows Server Instances: What’s Different?

If your VPS runs Windows Server, the rescue process uses a Windows recovery console (often a WinPE image). The steps involve mounting the system drive and running bootrec /fixmbr and bootrec /rebuildbcd to repair the bootloader. The overall concept is the same—boot into a minimal environment, access the disk, and run the appropriate repair commands—but the commands are Windows‑specific.

Conclusion

A broken bootloader or corrupted /boot partition can make a VPS appear dead, but the Rescue ISO turns a non‑booting instance into a fully functional troubleshooting workstation. By mounting the disks, chrooting into the original system, and using the appropriate GRUB tools for Debian/Ubuntu or AlmaLinux/Rocky, you can restore the boot process without reinstalling the server. Verify disk identifiers, bind‑mount the pseudo‑filesystems, regenerate the GRUB configuration, and reinstall the bootloader. With these steps most boot‑related failures are resolved quickly, keeping your applications and websites online.