Rescue mode is not your original system, nor is it a simple web terminal. It's usually a temporary Linux environment provided by the hosting provider; after booting, it presents the original VPS disk as a data disk.

You can think of it like this:

• The original system is broken, so don't boot from it first.
• The provider boots a clean minimal system for you.
• You mount the original disk inside this minimal system.
• Then you modify files in the original system, repair boot, and copy data.

It's also different from VNC/console. VNC shows you the original system's screen; Rescue Mode swaps in a temporary system to repair the original disk. Often the two are used together: first use VNC to see where boot is stuck, then enter rescue mode to fix it.

These scenarios are suitable for Rescue Mode:

A simple rule: if the original system can still be reached via SSH, prioritize online diagnosis; if the original system can't be reached, won't boot, or the root partition can't be safely repaired, consider rescue mode.

First, take a snapshot if you can. Rescue mode modifies files in the original system; if you accidentally delete something or perform fsck incorrectly, you may lose data.

Second, check the console/VNC first. Confirm whether the system is stuck at boot, has a password problem, a firewall problem, or a filesystem problem. Don't just blindly run fsck right away.

If you suspect an intrusion, preserve evidence first: don't reboot immediately, don't clear logs, and try to take a snapshot or disk image first. Rescue mode changes mount state and some timestamps, so be extra careful in forensic scenarios.

Entry points differ by provider, but the names are usually similar:

• Rescue Mode
• Boot to rescue
• Recovery mode
• Rescue ISO
• VNC + ISO

After enabling it, the VPS reboots into the temporary system. Some providers email the temporary root password; others display login info in the console. Once inside the rescue system, check the disks first:

lsblk
fdisk -l

Common disk names include:

• /dev/vda
• /dev/sda
• /dev/nvme0n1

Partitions may be /dev/vda1, /dev/sda1, /dev/nvme0n1p1. Don't copy device names from tutorials; confirm with lsblk first.

Assume the root partition is /dev/vda1:

mkdir -p /mnt/sysroot
mount /dev/vda1 /mnt/sysroot

If the system has a separate /boot partition, mount it too:

mount /dev/vda2 /mnt/sysroot/boot

If it's LVM, activate the volume group first:

vgscan
vgchange -ay
lsblk

Then mount the corresponding logical volume.

After mounting, confirm it's the original system:

ls /mnt/sysroot
cat /mnt/sysroot/etc/os-release

If you can see etc, var, home, usr, it's basically the original system root.

Many repair operations need to run in the original system environment, so bind a few system directories:

mount --bind /dev /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys /mnt/sysroot/sys
mount --bind /run /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash

After entering, the / you see is the original system root. Now you can change configuration just like logging into the original system.

Run inside chroot:

passwd root

If the system has disabled root SSH login, also check:

nano /etc/ssh/sshd_config

Focus on:

PermitRootLogin
PasswordAuthentication

Don't leave root password login enabled long-term just for convenience. The safer approach is to reset, log in once, reconfigure keys, then disable password login.

If you misconfigured /etc/fstab, the system may hang in emergency mode. After entering chroot, check:

nano /etc/fstab

For temporary diagnosis, you can comment out suspicious mount lines first. Especially newly added data disks, network disks, object storage mounts, and wrong UUIDs.

View partition UUIDs:

blkid

After confirming, write back to fstab. Don't treat device names from the rescue system as permanent configuration; prefer UUIDs.

Be careful with fsck. The principle is: never fsck a partition that is already mounted.

If you've already mounted the root partition, exit chroot and unmount first:

exit
umount /mnt/sysroot/run
umount /mnt/sysroot/sys
umount /mnt/sysroot/proc
umount /mnt/sysroot/dev
umount /mnt/sysroot

Then run:

fsck -f /dev/vda1

If you're sure you want to auto-answer yes:

fsck -fy /dev/vda1

But for important data disks, don't jump straight to -y. Read the error first, then decide whether to auto-repair.

If VNC shows grub rescue>, the kernel can't be found, or boot fails after a kernel upgrade, try reinstalling GRUB.

First remount and enter chroot:

mount /dev/vda1 /mnt/sysroot
mount --bind /dev /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys /mnt/sysroot/sys
mount --bind /run /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash

Common repair for BIOS boot:

grub-install /dev/vda
update-grub

Note: grub-install is usually followed by the disk /dev/vda, not the partition /dev/vda1.

For UEFI machines, paths and commands may differ; confirm whether the EFI partition is mounted at /boot/efi. If unsure, check first:

lsblk -f
findmnt /boot/efi

If you misconfigured the SSH port, firewall rules, or sshd_config, you can fix it in chroot:

nano /etc/ssh/sshd_config

You can also disable dangerous firewall rules first. For example, UFW:

ufw disable

If you use iptables/nftables, the rescue environment may not fully reflect the original system's running state. The more reliable approach is to modify the original system's rule files or startup scripts, not just look at the current temporary environment.

After fixing, don't just click reboot in the panel; exit and unmount in order:

exit
umount /mnt/sysroot/run
umount /mnt/sysroot/sys
umount /mnt/sysroot/proc
umount /mnt/sysroot/dev
umount /mnt/sysroot/boot 2>/dev/null
umount /mnt/sysroot

If it reports busy, check who's using it first:

lsof +f -- /mnt/sysroot

After confirming unmount is complete, go to the provider panel, disable Rescue Mode, switch back to disk boot, then reboot the VPS.

After booting, check immediately:

systemctl --failed
journalctl -b -p warning
ss -lntp

Confirm SSH, the website, and the database are all working, then remove temporary weak passwords, restore firewall, security group, and backup plans.

Rescue mode isn't a panacea, but it's the last line of insurance every VPS user must know. It's best suited for three kinds of problems: boot failure, locking yourself out, and needing offline repair of original system files.

The truly reliable workflow is: check the console first to diagnose the problem, take a snapshot, enter Rescue Mode, mount the original system, chroot if necessary, and after fixing, unmount properly and switch back to disk boot. As long as you don't blindly fsck -y or delete files carelessly, most "can't SSH in, must reinstall" scenarios actually still have a way out.