How to Fix Linux Boot Failure Due to File System Errors? A Complete Guide

CloudNetOps

CloudNetOps

— 3 min read
"Stability is the goal of IT operations, but anomalies are the daily reality."
Photo by Gabriel Heinzer / Unsplash

File system corruption is a common but tricky issue on Linux servers and personal computers. Especially after unexpected power failures, disk damage, or incorrect operations, you may encounter errors like:

checking root filesystem
/dev/sdb5 contains a file system with errors, check forced
/dev/sdb5: Unattached inode 68338812
/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
FAILED
*dropping you to a shell; the system will reboot when you leave the shell*
Press enter for maintenance (or type Control-D to continue):
give root password for maintenance

This usually means that Linux cannot boot properly due to file system errors, disk corruption, superblock damage, or improperly unmounted partitions. In this guide, we will analyze the causes of the problem in detail and provide safe and effective methods to fix it.

1. Why Do File System Errors Occur?

Linux primarily uses the ext3/ext4 file systems, which utilize a journaling mechanism to automatically repair minor errors after crashes or unexpected shutdowns. However, when the errors are too severe, the system will require a manual fsck repair.

🔹 Possible Causes

(1) Unexpected Power Failure or Improper Shutdown

When a Linux server or PC is abruptly powered off while read/write operations are still ongoing, the system may:

  • Lose partial file metadata, causing inode record errors.
  • Fail to replay the journal log, triggering an UNEXPECTED INCONSISTENCY.
  • Produce unattached inodes, where file data still exists but the index is lost.

(2) Disk Damage or Bad Sectors

If certain sectors of the hard drive are damaged, the file system metadata stored in them may become unreadable, leading to:

  • fsck reporting errors in inode structure or block bitmaps.
  • The root file system (/dev/sdb5) failing to mount correctly.

👉 Check Disk Health Status

smartctl -a /dev/sdb

(3) File System Metadata Corruption

When running fsck, you might see errors like:

Inode 68338812 ref count is 2, should be 1. Fix? yes
Unattached inode 68338812 Connect to /lost+found? yes

This indicates:

  • File system metadata inconsistencies, leading to incorrect inode reference counts.
  • A deep scan and repair by fsck is required.

2. How to Fix File System Errors?

Best for: Minor inode corruption or improperly unmounted file systems.

1️⃣ Enter Single-User Mode

init 1
Why? Ensures that no processes are accessing /dev/sdb5, preventing further damage.

2️⃣ Check if the Partition is Mounted

lsof | grep /dev/sdb5

If the partition is still in use, force unmount it:

umount -l /dev/sdb5

3️⃣ Manually Run fsck (Safe Mode)

fsck.ext3 /dev/sdb5
Tip: fsck will check inodes, directory structures, and data blocks, prompting you for confirmation when fixing errors.

4️⃣ If Confident, Run Auto Repair

fsck.ext3 -y /dev/sdb5

⚠️ Warning:

  • The -y option automatically accepts all repairs, which may cause data loss.
  • If you are unsure about which data is important, fix errors manually one by one.

5️⃣ Remount and Verify

mount /dev/sdb5 /mnt
df -hT /mnt

🔍 Solution 2: Repair Using a Backup Superblock

Best for: If fsck fails, the superblock may be damaged.

1️⃣ Find Alternative Superblocks

mke2fs -n /dev/sdb5

Sample output:

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

2️⃣ Use an Alternative Superblock for Repair

fsck.ext3 -b 32768 /dev/sdb5

3️⃣ After Repair, Try Re-Mounting

mount /dev/sdb5 /mnt

🔍 Solution 3: Check Disk Health

Best for: If fsck fails multiple times, the disk may have physical damage.

1️⃣ Use SMART to Check Disk Health

smartctl -a /dev/sdb

Key parameters to monitor:

  • Reallocated_Sector_Ct (Reallocated bad sectors count)
  • Current_Pending_Sector (Pending sectors that need repair)

2️⃣ Mark Bad Blocks (Logical Repair)

badblocks -v /dev/sdb5
fsck -c /dev/sdb5

3️⃣ If There Are Many Bad Sectors, Consider Replacing the Disk!

3. How to Prevent File System Errors?

💡 Back Up Data Regularly!

tar -czf /backup/system_backup.tar.gz /

💡 Check Disk Health Regularly

smartctl -a /dev/sdb

💡 Use a UPS (Uninterruptible Power Supply) to Prevent File System Damage!

💡 Shut Down Properly

shutdown -h now

Avoid using force shutdown (poweroff).

4. Summary

Issue Solution
fsck Reports UNEXPECTED INCONSISTENCY Enter Single-User Mode (init 1), run fsck.ext3 /dev/sdb5 for manual repair.
inode Count Error (Unattached inode 68338812) Use fsck.ext3 -y /dev/sdb5 for automatic repair, but it may result in some data loss.
Superblock Corruption, fsck Fails Use fsck.ext3 -b 32768 /dev/sdb5 to fix it.
Disk Bad Sectors, fsck Can't Fix Use smartctl -a /dev/sdb to check disk health and replace if necessary.

👉 By following these methods, you can effectively fix Linux file system errors and ensure system stability. If you've encountered similar issues, feel free to share your experience in the comments! 🚀

If you still find a large number of unknown files in the /lost+found directory after running fsck and are unsure how to recover them, check out 👉 How to Recover Files from the Linux lost+found Directory?.

Read more