Console and Rescue Access

Sooner or later every administrator locks themselves out: a firewall rule that forgot SSH, a network config typo, a bad kernel update, a full disk. Every NoBull Networks VPS includes two ways back in that do not depend on the operating system cooperating: a browser-based VNC console and a rescue environment. Both are reached from your server's page in the cloud portal at cloud.nobullnetworks.com.

Power controls first#

Open the server in the cloud portal. The controls across the top of its page show the current power state and the standard actions: start, restart, and stop (a graceful shutdown, when the guest OS responds), plus a hard power off for when it does not. A stopped server billed to your account is still your server; power it back on from here at any time.

The VNC console#

The console is a virtual keyboard and monitor attached directly to the VM, delivered over your browser (noVNC). It works even when networking inside the guest is completely broken, which makes it the first stop for any "I cannot SSH in" problem.

1. Click the VNC icon in the top-right corner of the server's page. The console opens in a new tab with the server's screen.
2. Log in locally with the root (or your sudo user's) password. Key-only SSH restrictions do not apply here; the console is a local login.
3. Fix the problem, for example allow SSH in the firewall, restart the SSH service, correct /etc/netplan or /etc/network/interfaces, or free disk space.
4. Close the console tab when done and reconnect over SSH.

Rescue mode#

Rescue mode boots the VM from a small, separate Linux image (an Ubuntu-based rescue ISO) with your normal disk attached but not running. It is the tool for problems that stop the operating system from booting at all: a broken bootloader, a bad /etc/fstab entry, filesystem errors, or a lost root password.

1. Open the Boot & Rescue tab on the server's page (older portal versions label it Rescue) and click Boot from Rescue ISO.
2. Restart the server with the restart control and confirm. It comes back up inside the rescue environment.
3. Log in. Use the VNC console, or SSH to the server's IP address; the rescue system accepts the server's root password or the SSH keys already on the server.
4. Mount your disk. Identify the root partition with lsblk (it appears as /dev/sda1, /dev/vda1, or similar), then mount it:

   lsblk
   mkdir -p /mnt/sda1
   mount /dev/sda1 /mnt/sda1

   Mount /boot and any separate partitions the same way if you have them.
5. Repair. Run fsck on an unmounted filesystem, edit /mnt/sda1/etc/fstab, copy data off the server, or chroot /mnt/sda1 to reinstall the bootloader or reset a password with passwd.
6. Leave rescue mode. Back on the Boot & Rescue tab click Boot from Disk, then restart the server. If it now boots, reconnect over SSH and confirm your changes stuck.

When to reinstall instead#

If the operating system is compromised, or the fix is turning into an archaeology project, a clean reinstall plus a restore from backup is faster and safer. Rescue mode still helps here: mount the disk and copy anything worth saving off the server first.

Still stuck?#

The activity log on the server's page shows every power action, so you can confirm what happened and when. If the console will not open, the server will not respond to power actions, or you suspect the problem is below the operating system, that is infrastructure and it is ours. Open a ticket with the server name and what you tried; an engineer will take it from there.