Boot your instance into SystemRescue to repair boot issues, fix network configs, reset passwords, and recover data — without data loss.

Rescue Mode

Rescue Mode boots your instance from a SystemRescue live ISO instead of your normal disk. Use it when your instance won't boot, the network is unreachable, you've lost the root password, or /etc/fstab is broken.

Your data is not modified. SystemRescue runs entirely from RAM — your disk sits beside it as a passive block device that you can mount, edit, and unmount.

When to Use Rescue Mode

Symptom	Likely Cause	Fix in Rescue Mode
Instance shows Running but is unreachable on SSH/HTTP	Broken network config inside the OS	Edit `/etc/sysconfig/network-scripts/` or `/etc/netplan/`
Boot hangs at "A start job is running for…"	Bad `/etc/fstab` entry (NFS/iSCSI/CIFS mount)	Comment out the failing line
Lost root password	—	`chroot` and run `passwd`
Filesystem errors on boot ("read-only", "fsck failed")	Disk corruption	Run `fsck` / `xfs_repair`
Need to recover files from a broken VM	—	Mount the disk and copy files out
Bootloader broken after kernel install	GRUB misconfigured	`chroot` and reinstall GRUB

Data Safety

Rescue Mode is non-destructive by design. Enabling it does not touch your data disk, partitions, or filesystem. Disabling it returns your instance to its original boot state.

Behind the scenes, Rescue Mode does three things:

Attaches the SystemRescue ISO to the instance's CD drive (ide2)
Changes the boot order to CD first, disk second (order=ide2;scsi0)
Stops and starts the instance so it boots from the ISO

When you disable it, the CD drive is reset and the boot order goes back to disk only (order=scsi0). Your filesystem on scsi0 is never written to by the rescue process itself.

Enabling Rescue Mode

Open the Console dashboard and navigate to your instance.
In the Power Controls section, click Rescue Mode.
Confirm the dialog. The instance will stop, then start again from the rescue ISO. Expect ~10–20 seconds of downtime.
The instance status changes to Rescue, and you'll receive a confirmation email.
Click Console to open the VNC viewer and watch the boot.

When SystemRescue finishes booting, you'll see a login prompt — log in as root with no password (you're inside an isolated rescue environment).

Connecting to Rescue Mode

You have two ways to interact with SystemRescue:

Console (always available)

Click Console on the instance page. The VNC viewer drops you straight into the SystemRescue shell. This works even when the network is broken — recommended for most recovery scenarios.

SSH (only if network is up)

SystemRescue brings up DHCP on eth0 automatically. If your provider issues a DHCP lease, you can SSH in:

# From your local machine
ssh root@<your-instance-ip>

The default rescue SSH password is shown in the SystemRescue boot banner. If you need a stable password, set one inside the rescue shell:

passwd

If your network was already broken inside the guest OS (the reason you booted into rescue), SSH inside rescue may not work either. Use the Console.

Recovering Your System

The first step is always the same — find your disk and mount it.

Step 1 — Identify the disk

lsblk

Typical output for an AlmaLinux 8 / Rocky Linux instance:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0    7:0    0  700M  1 loop /run/archiso/airootfs
sda      8:0    0  250G  0 disk
├─sda1   8:1    0    1M  0 part
├─sda2   8:2    0  100M  0 part
└─sda3   8:3    0  249G  0 part           ← your root filesystem
sr0     11:0    1  900M  0 rom

For Ubuntu / Debian instances, the root is usually sda1. Always run lsblk first — never assume.

Step 2 — Mount the root filesystem

# AlmaLinux / Rocky / CentOS (XFS on /dev/sda3)
mount /dev/sda3 /mnt

# Ubuntu / Debian (ext4 on /dev/sda1)
mount /dev/sda1 /mnt

If you need DNS resolution and full system tools (e.g. to reinstall packages), bind-mount the system directories and chroot:

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

Step 3 — Fix the problem

Pick the recipe that matches your symptom.

Fix a broken network config (most common)

# AlmaLinux / Rocky / CentOS
ls /mnt/etc/sysconfig/network-scripts/
cat /mnt/etc/sysconfig/network-scripts/ifcfg-eth0

# Restore a working baseline (DHCP)
cat > /mnt/etc/sysconfig/network-scripts/ifcfg-eth0 <<'EOF'
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
EOF

# Ubuntu (netplan)
ls /mnt/etc/netplan/
nano /mnt/etc/netplan/01-netcfg.yaml

# Validate YAML syntax — a single bad indent breaks boot

Fix a broken `/etc/fstab`

nano /mnt/etc/fstab

Comment out (#) any non-essential network mounts (NFS, CIFS, iSCSI). The boot will resume once the failing mount is removed.

Never remove the root (/) entry from fstab. If unsure which line is correct, save a backup first: cp /mnt/etc/fstab /mnt/etc/fstab.bak.

Reset the root password

chroot /mnt /bin/bash
passwd root
exit

Run a filesystem check

The disk must be unmounted before you fsck it.

umount /mnt

# XFS
xfs_repair /dev/sda3

# ext4
fsck.ext4 -y /dev/sda1

Recover specific files

mkdir /mnt/recovery
mount /dev/sda3 /mnt/recovery
cp -r /mnt/recovery/home/myuser/important /tmp/

# Then upload to a safe location, e.g. via scp from another box:
# scp root@<rescue-ip>:/tmp/important.tar.gz ~/

Reinstall GRUB

chroot /mnt
grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg
exit

Step 4 — Unmount and exit

Always unmount cleanly before disabling rescue mode:

# If you chrooted
exit

# Unmount in reverse order
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev
umount /mnt
sync

Disabling Rescue Mode

Go back to the instance detail page in the dashboard.
Click Disable Rescue in the Power Controls section.
Confirm. The instance stops, the rescue ISO is detached, the boot order is restored to disk-only, and the instance starts again.
Status returns to Running. Open the Console to confirm the OS boots normally.

If you forget to disable rescue mode, your instance will boot from the rescue ISO every time it restarts — your applications won't come back up. Always disable when finished.

Troubleshooting

The instance still won't boot after I disabled rescue mode. Re-enable rescue mode, mount the disk again, and check:

journalctl -D /mnt/var/log/journal --boot=-1 -p err (last failed boot's errors)
/mnt/etc/fstab for hidden bad entries
/mnt/etc/default/grub and re-run grub2-mkconfig

The Console shows kernel logs but no login prompt for 10+ minutes. Boot is hanging on a service waiting for the network or a mount. Force-power-off, enable rescue mode, and inspect journalctl --boot=-1.

lsblk doesn't show my disk. Force-power-off (don't graceful-shutdown — the rescue ISO is the only thing booted), wait 5 seconds, start again. If still missing, open a support ticket.

SSH into rescue mode is refused. Set a password inside rescue first (passwd), and confirm the network is up (ip a). If eth0 has no IP, your provider's DHCP is reachable — but if the underlying hypervisor network is the issue, only Console access will work.

What's Happening Behind the Scenes

For users who want to understand the mechanism, this is exactly what enabling rescue mode does on the hypervisor:

PUT /nodes/{node}/qemu/{vmid}/config
  ide2 = "local:iso/systemrescue.iso,media=cdrom"
  boot = "order=ide2;scsi0"

POST /nodes/{node}/qemu/{vmid}/status/stop
POST /nodes/{node}/qemu/{vmid}/status/start

Disabling restores ide2 to the cloud-init image and sets boot = "order=scsi0". Your scsi0 disk is never written to, attached to a different VM, or modified in any way during the process.

Next Steps

Console Access — VNC and serial terminal details
Managing Instances — Power controls, resize, rebuild, destroy
Block Storage — Attach extra volumes for persistent data
Support Tickets — Open a ticket if rescue mode can't recover your instance

Rescue Mode

On this page