What to do if your VPS won’t boot (kernel, filesystem & mount errors)

There are several reasons why a Linux VPS might no longer boot and display an error message. In most cases, this is due to a misconfiguration of the VPS, which often becomes apparent later — for example, after a reboot. These problems are often technical and may be complex to resolve. Restoring a backup is not always desirable or possible.

In this guide, we present a series of possible problems and explain how to resolve them.

Important: Create a snapshot of your VPS before starting the steps in this guide, so you have a backup copy in case something goes wrong.

CentOS Stream / AlmaLinux / Rocky Linux: In some cases, SELinux requires a “relabel” process after changes. After completing the steps in this article, use the journalctl command to check if a related message appears. If so, run the suggested command (usually sudo touch /.autorelabel; reboot).

---

Booting into Linux Rescue Mode

Many of the errors described in this article require entering Rescue Mode to resolve them. You can boot your VPS into Linux Rescue Mode by following these steps:

Step 1

Log in to the control panel, click “VPS,” and then search for or select the desired server.

Step 2

In the VPS console, click “Boot in rescue.”

A window will appear. Make sure “RescueLinux” is selected and then click “Boot image.”

Step 3

Click the “pop-out” button at the bottom right to open the console in a new window. This makes it easier to copy and paste commands using the “Paste in console” option.

It takes a few minutes for Rescue mode to start. You might see a message like the one below:

error: file '/vmlinuz-<version>-generic' not found.<br>error: you need to load a kernel first

As the message indicates, the kernel cannot be found. It is normally located in the /boot/ directory.

Before continuing, note down the kernel version shown in the message — e.g. 6.8.0-54 in error: file '/vmlinuz-6.8.0-54-generic' not found.

In CentOS Stream, AlmaLinux, and Rocky Linux, you might see more information, but in any case note the kernel version — e.g. vmlinuz-5.14.0-503.26.1.el9_5.x86_64.

---

Step-by-Step Recovery Process

Step 1

Boot the VPS into Linux Rescue Mode as described above.

Step 2

Check which block devices are available:

lsblk

The command output will look similar to this:

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     253:0    0  100G  0 disk
├─vda1  253:1    0   99G  0 part /
├─vda14 253:14   0    4M  0 part
├─vda15 253:15   0  106M  0 part /boot/efi
└─vda16 259:0    0  913M  0 part /boot

Ubuntu / Debian:

mount /dev/vda1 /mnt

CentOS Stream / AlmaLinux / Rocky Linux:

mmount /dev/vda2 /mnt
mkdir /mnt/boot
mount /dev/vda1 /mnt/boot

Step 3

Mount the dev, proc, sys, and tmp folders so that they can be accessed within the chroot environment:

mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /tmp /mnt/tmp

Step 4

Enter the chroot environment:

chroot /mnt /bin/bash

Step 5

Reinstall GRUB and update the boot configuration.

Ubuntu / Debian:

grub-install /degrub-install /dev/vda
update-grub

CentOS Stream / AlmaLinux / Rocky Linux:

UUID=$(blkid /dev/vda2 -o value -s UUID) KERNELCONF=$(basename "$(ls UUID=$(blkid /dev/vda2 -o value -s UUID)
KERNELCONF=$(basename "$(ls /boot/loader/entries/*.conf | sort | tail -n 1)" .conf)
grub2-editenv - set "saved_entry=$KERNELCONF"
grub2-editenv - set "boot_succes=0"
grub2-editenv - set "boot_indeterminate=0"
grub2-editenv - set "kernelopts=root=UUID=$UUID ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M net.ifnames=0 rhgb quiet"
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/vda
grub2-mkconfig -o /boot/grub2/grub.cfg

To verify that the variables are correctly set:

cat /boot/loader/entries/$KERNELCONF | grep options
grub2-editenv list

The kernelopts variable must exist, as it is required for a successful boot.

Step 6

Exit the chroot environment:

exit

Step 7

Unmount all mounted folders. The -l (“lazy”) option forces unmounting even if a “busy” error occurs.

umumount -l /mnt/tmp
umount -l /mnt/sys
umount -l /mnt/proc
umount -l /mnt/dev
umount -l /mnt

Step 8

Restart the VPS using the “Restart” button in the control panel. The reboot command does not work in Rescue Mode.

Result: Your VPS should now boot normally (it may take a few minutes).

---

Probably out of disk space / <service>.service: Failed with the result ‘exit-code’.

This type of error message usually doesn’t prevent the VPS from booting, but it can stop a service (such as MariaDB) from starting. During startup, a red message may appear indicating that the service failed to start. One possible cause is a lack of disk space. The steps below can help you identify and fix the issue.

Step 1

When a service fails to start, a good first step is to check its log files. You can do this with the following command, replacing <service> with the name of the service (e.g. mariadb, apache2, or httpd):

journalctl -xe -u <service>

Step 2

The command will display a lot of text, but focus on lines containing [ERROR]. For example, in a MariaDB error you may see:

[ERROR] InnoDB: preallocating 12582912 bytes for file ./ibtmp1 failed with error 28 [ERROR] InnoDB: Could not set the file size of './ibtmp1'. Probably out of disk space 
[ERROR] InnoDB: Plugin initialization aborted with error Generic error 
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 
[ERROR] Unknown/unsupported storage engine: InnoDB 
[ERROR] Aborting

The most critical line is:

Could not set the file size of './ibtmp1'. Probably out of disk space

This indicates that the disk is full and there’s not enough free space for the service to run properly.

Step 3

To check available disk space, run:

df -h

The output might look like this:

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           1.8G     0  1.8G   0% /dev/shm
tmpfs           732M  8.6M  724M   2% /run
/dev/vda2       147G  139G   12M 100% /
/dev/vda1       504M  480M     0 100% /boot
tmpfs           366M     0  366M   0% /run/user/1000

As shown, both the main filesystem (/) and the /boot partition are full. The next step is to identify which files or folders take up the most space.

Step 4

For the /boot partition, there may be old kernel files that are no longer needed. You can remove them as follows:

Ubuntu / Debian:

sudo apt -y autoremove --purge

CentOS / AlmaLinux / Rocky Linux:

package-cleanup --oldkernels --count=2

This command removes old kernels, keeping only the two most recent ones. If you receive an error saying the required package is missing and there’s no space to install it, use this alternative:

dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q)

To find out what is using the most space on your system, use:

du -ah / 2>/dev/null | sort -rh | head -n 20

This command lists the 20 largest files or directories. For example:

127G / 
118G /tmp 
118G /tmp/fullfile 
3.2G /usr 
3.1G /data/registry/docker/registry/v2/blobs/sha256 
...

Here, we see that the /tmp folder contains a file called fullfile of 118GB, which can be safely deleted:

sudo rm /tmp/fullfile

If you wish to delete a whole folder, use:

sudo rm -rf <folder>

Warning: Do not delete system directories such as /boot/ or /etc/. Use this command only for temporary or user folders, for example /home/username/example/.

Step 5

After freeing up space, restart the affected service or, preferably, reboot the entire VPS to ensure all services start properly.

sudo systemctl restart <service>
sudo reboot

After rebooting, the service should start normally, and your VPS should operate without issues.