Diagnose a VPS that will not boot

3 min read07 November 2026

A VPS that no longer answers on SSH is not necessarily stopped. It may be stuck at boot, have a full disk, a failing service or a broken network configuration. In a system container, diagnosis happens from the dashboard console, because there is no GRUB or rescue menu to select.

Start with the console

Open the noVNC console from the dashboard. Three cases appear:

no output and the container shows as stopped: use the power action, then watch the boot;
messages loop: the system boots but a service or mount fails;
a login prompt appears: the system is up, the problem is network or SSH.

In the third case, log in as root from the console and check ip -6 addr, systemctl status ssh and ss -ltnp before blaming hardware.

Read the boot logs

Bash

systemctl --failed
journalctl -b -p err
journalctl -b -1 -p err
dmesg | tail -n 50

-b is the current boot, -b -1 the previous one. That distinction matters: the failed boot log holds the cause, the current one only shows the repair attempt. If the journal is not persistent, the previous boot may be gone; check that /var/log/journal exists.

Common causes

Symptom	Likely cause	Check
Loop, failed mount	invalid `/etc/fstab` entry	`mount -a`, journal
Write errors	disk or inodes full	`df -h`, `df -i`
Failed service	interrupted upgrade	`dpkg --configure -a`
SSH missing	configuration or permissions	`sshd -t`, `ls -l /etc/ssh`
Very slow boot	service waiting for network	`systemctl list-jobs`

An fstab entry pointing to a disk that no longer exists is a classic: the system waits, then drops to a degraded mode.

Repair from the console

If the system offers a maintenance prompt, remount the root filesystem read-write:

Text

mount -o remount,rw /

Free space if needed with journalctl --vacuum-size=200M, then fix the cause. For a faulty fstab line, comment it with # and test mount -a before rebooting. For an interrupted upgrade:

Bash

dpkg --configure -a
apt -f install

Fix the usual permissions if needed: /etc and /etc/ssh at 755, sshd_config at 600. Always test the SSH configuration with sshd -t before restarting the service, and keep a console session open while you work.

Last resort

If the system no longer boots at all, recover the data from the console (archive it in an accessible path) before any reinstall. Reinstalling from the dashboard wipes the disk: do it only after a backup, or if the data has no value. If the cause is unclear, contact support before reinstalling: a platform problem cannot be fixed inside the container.