![](\"\/support\/wp-content\/uploads\/sites\/55\/2025\/05\/0f4cf5ed-a356-4a19-96a4-27bea10739a8.jpg\")
<\/div>\n<\/p>
Once there, go to the Emergency mode<\/b> tab and toggle Turn on Emergency mode<\/a><\/b>.<\/p> Wait a few minutes for Emergency Mode to fully activate. <\/p> \n<\/p> \n<\/p> Once enabled, you will be able to connect to your VPS via SSH using the provided credentials.<\/p> \n<\/p> Connect to your VPS using SSH<\/a>:<\/p> \n<\/p> \n<\/p> Since the VPS is in Emergency Mode, you need to identify which disk is corrupted to be able to fix it.<\/p> In your SSH connection, run the following command:<\/p> \n<\/p> To identify where your original OS is stored. The result will show something like:<\/p> \n<\/p> \n<\/p> The main partition can be identified as the largest in size. In the example above, the largest partition is \n<\/p> In Emergency Mode, your original (corrupted) system is automatically mounted under \n<\/p> Now you have identified your main partition, you can run the filesystem check command. Replace \n<\/p> The output will show the reasons why your VPS was corrupted:<\/p> \n<\/p> \n<\/p> After repairing the file system on your main partition, return to your hPanel VPS settings and turn off Emergency Mode.<\/p> \n<\/p> Once Emergency Mode is disabled, restart your VPS server<\/a>. After restarting, your VPS should be fully operational with Browser Terminal access restored.<\/p> \n<\/p> If Browser Terminal still shows a blank screen after following these steps:<\/p> Try running the repair command with automatic confirmation: Repeat the entire process to ensure all errors were addressed<\/p>\n<\/li>\n If issues persist, we recommend backing up any recoverable data and recreating the server entirely or restoring your VPS from backups.<\/a><\/p>\n<\/li>\n<\/ul>![](\"\/support\/wp-content\/uploads\/sites\/55\/2025\/05\/0e6c1fec-a65c-42b6-9f54-01516a0ce4b1.jpg\")
<\/div>ssh root@your-server-ip<\/code><\/pre>Step 2 – Identify your main partition<\/b><\/h2>
lsblk<\/code><\/pre>root@machine:\/# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 63.4M 1 loop \/snap\/core20\/1974
loop1 7:1 0 111.9M 1 loop \/snap\/lxd\/24322
loop2 7:2 0 53.3M 1 loop \/snap\/snapd\/19457
loop3 7:3 0 40.9M 1 loop \/snap\/snapd\/20290
loop4 7:4 0 63.5M 1 loop \/snap\/core20\/2015
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 49.9G 0 part \/mnt\/sda1
├─sda14 8:14 0 4M 0 part
└─sda15 8:15 0 106M 0 part \/mnt\/sda15
sdb 8:16 0 2.2G 0 disk
├─sdb1 8:17 0 2.1G 0 part \/
├─sdb14 8:30 0 4M 0 part
└─sdb15 8:31 0 106M 0 part
sr0 11:0 1 4M 0 from<\/code><\/pre>sda1<\/code><\/b>, designated with the mount point \/mnt\/sda1<\/code><\/b>.<\/p>\/mnt<\/code>, while the current emergency environment runs from a separate partition.<\/p>Step 3 – Repair your VPS<\/b><\/h2>
sda1<\/code><\/b> with your actual main partition:<\/p>fsck \/dev\/sda1<\/code><\/p>fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
cloudimg-rootfs: recovering journal
fsck.ext4: unable to set superblock flags on cloudimg-rootfs
cloudimg-rootfs: ***** FILE SYSTEM WAS MODIFIED *****
cloudimg-rootfs: ********** WARNING: Filesystem still has errors **********
Here, it shows that fsck successfully made some repairs (journal recovery, using backup group descriptors), but not all issues were fixed. The key line is:
**cloudimg-rootfs: ********** WARNING: Filesystem still has errors ************
This means the file system is still in a bad state.
To fix remaining errors, run:
fsck -f \/dev\/sda1<\/code><\/pre>-f<\/code><\/b> means that it will force a full check. You can use -fy<\/code><\/b> if you want to auto-confirm all fixes automatically.<\/p>Step 4 – Exit Emergency Mode and restart your VPS<\/b><\/h2>
Troubleshooting<\/b><\/h2>
\n
fsck -fy \/dev\/sda1<\/code><\/p>\n<\/li>\n