Boot failures, read errors, and emergency mode drops are stressful, especially when your data sits on a partition you cannot mount. If your system is telling you the filesystem state is “not clean,” you need to repair a corrupted ext4 filesystem with fsck from a Live USB before things get worse. I have walked through this exact process on dozens of Linux machines over the years, from personal laptops to production servers that went down hard after a power outage.
fsck (filesystem check) is a Linux command-line utility that checks and repairs filesystems by scanning metadata structures like inodes, the superblock, and the journal. For ext4 partitions, fsck internally calls e2fsck to do the heavy lifting. The tool finds inconsistencies, reconnects orphaned data, and rebuilds broken metadata so your filesystem mounts normally again.
This guide covers the entire procedure from start to finish. You will learn how to create bootable rescue media, identify the right partition, run fsck safely, interpret its output, handle severe superblock corruption, and recover files that land in lost+found. Every command below includes context so you understand what it does before you run it.
Table of Contents
What Causes ext4 Filesystem Corruption?
ext4 filesystem corruption happens when the filesystem metadata gets out of sync with the actual data on disk. The filesystem journal normally protects against this, but it cannot save you from every scenario. Understanding the cause helps you pick the right repair strategy.
Common Signs Your ext4 Filesystem Is Corrupted
Corruption rarely happens silently. Your system usually tells you something is wrong through specific symptoms that escalate over time.
You might see any of these warning signs:
System drops to emergency mode (also called maintenance mode) during boot with a prompt to run fsck manually
Boot fails entirely with messages like “fsck failed” or “UNEXPECTED INCONSISTENCY”
Files or directories disappear, show zero bytes, or produce “Input/output error” when you try to open them
dmesg or system logs show ext4 errors like “ext4_lookup: deleted inode referenced” or “journal commit I/O error”
The filesystem mounts as read-only automatically (ext4 does this on purpose to protect data when it detects errors)
Applications crash randomly with segmentation faults when accessing certain files
Power Failures and Unclean Shutdowns
Sudden power loss is the number one cause of ext4 corruption I see in forum discussions and real-world scenarios. When the system loses power mid-write, the journal may not have finished committing transactions. On the next boot, ext4 replays the journal to restore consistency. Most of the time, this automatic journal replay fixes the problem. But if the journal itself is damaged, you need manual fsck intervention.
Hard reset (holding the power button) produces the same effect as a power outage. The filesystem is left in an unclean state with the “dirty flag” set. Forum users on r/linuxquestions frequently report needing to run fsck multiple times after repeated hard shutdowns to fully clear accumulated errors.
Hardware Issues and Failing Drives
Not all corruption is filesystem-level. Bad sectors on a dying hard drive or SSD can corrupt the data underneath the filesystem. If you repair the filesystem with fsck but the underlying hardware continues failing, the corruption returns. In these cases, you should use ddrescue to image the drive first before attempting repair on the image.
Other hardware causes include faulty RAM (which corrupts data in memory before it gets written), loose SATA cables, and failing USB adapters when repairing external drives. Always check SMART data with smartctl before assuming the filesystem is your only problem.
Critical Safety Rules Before You Start
Running fsck on the wrong partition or under the wrong conditions can destroy recoverable data. Follow these rules without exception.
Rule 1: Never run fsck on a mounted filesystem. fsck reads and modifies metadata structures that the kernel may also be modifying at the same time. Running it on a mounted partition can corrupt the filesystem beyond repair. Always unmount the target partition first. If the partition refuses to unmount, find out what process is using it with lsof or fuser, then stop that process.
Rule 2: Back up your data before attempting repair. If the drive is accessible at all, clone it first with ddrescue or dd. Work on the clone if the data is critical. Forum users repeatedly share stories of running fsck -y on a severely damaged filesystem only to lose files that could have been recovered with a more careful approach.
Rule 3: Double-check the device name. Running fsck on the wrong device (for example, /dev/sda when you meant /dev/sdb) can destroy a healthy filesystem. Verify the partition with lsblk and blkid before running any repair command.
Rule 4: Start with read-only checks. Run fsck -n (no-op mode) first to see what errors exist without making changes. Review the output, then decide whether to proceed with automatic repair.
How to Create a Live USB for Filesystem Repair?
You cannot run fsck on the root filesystem while it is mounted and active. A Live USB gives you a complete Linux environment that boots entirely from RAM, leaving every internal partition unmounted and available for repair. None of the three top-ranking competitors cover this step, so I am including it here.
Step 1: Download a Linux ISO
Download any mainstream Linux distribution ISO. Ubuntu, Linux Mint, or Fedora all include fsck and e2fsck by default. The desktop edition works fine, but the minimal or server ISO boots faster if you are comfortable with a command-line-only environment. Verify the checksum of the downloaded ISO to make sure the file is not corrupted.
Step 2: Write the ISO to a USB Drive
Insert a USB drive with at least 4 GB of storage. Identify it with lsblk, then write the ISO to the entire device (not a partition). On Linux, use dd:
sudo dd if=ubuntu.iso of=/dev/sdX bs=4M status=progress
Replace /dev/sdX with your actual USB device. Double-check the device name because dd will overwrite everything on it. On Windows or macOS, use balenaEtcher or Rufus to write the ISO to the USB drive without dealing with command-line syntax.
Step 3: Boot From the USB Drive
Insert the USB into the broken machine and power it on. Enter the BIOS or UEFI boot menu (usually by pressing F2, F12, Del, or Esc during POST). Select the USB drive as the boot device. Choose the “Try Linux” or “Live mode” option rather than installing. You will land on a desktop or terminal with full access to your system drives, none of which are mounted by default.
How to Identify the Corrupted Partition
Before running any repair command, you need to know the exact device name of the corrupted partition. In a Live USB environment, device names may differ from what you see on your installed system, so always check fresh.
Using lsblk to List Block Devices
Run lsblk to see all storage devices and their partitions in a readable tree format:
lsblk -f
The -f flag shows filesystem types, labels, and UUIDs. Look for partitions with the “ext4” filesystem type. Note the device name (such as /dev/sda2 or /dev/nvme0n1p3) for the partition you want to repair. The SIZE column helps you match partitions to what you expect.
Confirming With blkid
Cross-reference the lsblk output with blkid to confirm the filesystem type and UUID:
sudo blkid
blkid prints the device name, UUID, and filesystem type for every block device. Match the UUID to what you see in your /etc/fstab file if you have access to it. This confirms you are targeting the right partition before running any destructive operation.
Check the Filesystem Status
Use dumpe2fs to check whether the filesystem is marked clean or dirty:
sudo dumpe2fs -h /dev/sdXN | grep 'Filesystem state'
If the output says “not clean,” the filesystem was not unmounted properly and needs checking. If it says “clean with errors,” the journal detected problems it could not fix automatically. Either way, fsck is your next step.
How to Repair a Corrupted ext4 Filesystem With fsck From a Live USB
This is the core procedure. Follow these steps in order, and do not skip the unmount check.
Step 1: Unmount the Target Partition
In a Live USB environment, the partition is likely already unmounted. Verify it:
sudo umount /dev/sdXN
If the partition was auto-mounted by the Live USB, this command unmounts it. If it was not mounted, you get a “not mounted” message, which is fine. If it says “target is busy,” find what is using it with sudo lsof /dev/sdXN or sudo fuser -m /dev/sdXN, stop that process, then try again.
Step 2: Run a Read-Only Check First
Before changing anything, see what fsck finds:
sudo fsck -n /dev/sdXN
The -n flag tells fsck to check but not modify anything. Review the output carefully. If you see a small number of minor inconsistencies (like orphaned inodes or a small journal issue), proceed to automatic repair. If you see massive numbers of errors or if fsck segfaults, stop and read the superblock recovery section below.
Step 3: Run Automatic Repair
For most corruption scenarios, run fsck with the -p flag for safe automatic repair:
sudo fsck -p /dev/sdXN
The -p flag (also called “preen” mode) automatically fixes problems that are safe to fix without user interaction. It handles common issues like reconnecting orphaned inodes and clearing the dirty flag. If fsck encounters a problem it considers potentially dangerous to fix automatically, it stops and asks you.
For more aggressive repair, use -y to answer “yes” to every question fsck asks:
sudo fsck -y /dev/sdXN
The -y flag tells fsck to proceed with every repair without prompting. This is faster but riskier. Use it when you have already backed up the drive or when the data is not critical. Forum users recommend running fsck -y, then running it a second time to catch any errors that the first pass exposed.
Step 4: Force a Full Check
If the filesystem is marked clean but you suspect problems, force a full check with -f:
sudo fsck -f /dev/sdXN
By default, fsck skips the full check if the filesystem is marked clean. The -f flag overrides this and checks every inode, block bitmap, and directory entry. Combine it with -y for a comprehensive forced repair:
sudo fsck -fy /dev/sdXN
Step 5: Run fsck Multiple Times If Needed
After the first repair pass, run fsck again. Sometimes fixing one set of errors exposes additional problems that were hidden. Keep running fsck until it reports a clean filesystem with zero errors. Multiple passes are normal after severe corruption from power failures.
Understanding fsck Output and Exit Codes
fsck communicates results through exit codes rather than plain-language summaries. Knowing these codes tells you whether the repair succeeded, partially succeeded, or failed catastrophically.
Common Exit Codes
fsck uses a bitmask for exit codes, which means the number you see can be a combination of multiple conditions. Here are the individual values:
0 — No errors detected. The filesystem is clean.
1 — Filesystem errors detected and corrected. The repair succeeded.
2 — The system should be rebooted. fsck fixed something that requires a fresh boot.
4 — Filesystem errors detected but left uncorrected. You need to take manual action.
8 — Operational error. fsck could not complete, possibly due to a hardware problem.
16 — Usage or syntax error. You typed the command wrong.
32 — The fsck check was canceled by the user.
128 — Shared library error. The fsck binary itself has a problem.
Codes can combine, so an exit code of 3 means both code 1 (errors corrected) and code 2 (reboot needed). An exit code of 5 means code 1 (errors corrected) plus code 4 (errors left uncorrected). Check the code with echo $? immediately after fsck finishes.
Reading fsck Output Messages
During the repair, fsck prints messages about what it finds and fixes. Here is what the common messages mean:
“Inodes that were part of a corrupted orphan linked list found” means fsck found inodes that were being deleted when the system crashed. fsck will delete them or reconnect their data to lost+found.
“Free blocks count wrong” and “Free inodes count wrong” mean the filesystem’s accounting does not match reality. fsck recalculates these counts automatically in preen mode.
“Entry in directory has a bad inode number” means a directory points to an inode that does not exist. fsck removes the broken entry.
“Journal commit I/O error” indicates the journal could not be written or read properly. fsck will attempt to replay or rebuild the journal.
Fixing Bad Superblock Corruption
The superblock is the master record of your filesystem. It stores the total size, block size, mount count, and pointers to critical metadata structures. If the primary superblock is corrupted, fsck cannot even start checking the filesystem. In severe cases, fsck segfaults immediately. This is a known issue that forum users on r/archlinux and Ask Ubuntu report frequently.
What Is the Superblock
The superblock is the first metadata structure fsck reads. Without it, fsck has no idea where inodes, block bitmaps, or data blocks are located on the partition. ext4 protects against superblock corruption by keeping backup copies at predictable locations throughout the partition.
Step 1: Find Backup Superblocks
Use mke2fs with the -n flag to see where backup superblocks are located. This does NOT format the drive; it only prints what the filesystem layout would be:
sudo mke2fs -n /dev/sdXN
Look for a line like “Superblock backups stored on blocks:” followed by block numbers. The first backup is usually at block 32768. Note these block numbers.
Step 2: Run fsck With a Backup Superblock
Run e2fsck (the ext4-specific checker) with the -b flag pointing to one of the backup superblock locations:
sudo e2fsck -b 32768 /dev/sdXN
fsck reads the backup superblock, uses it to reconstruct the primary superblock, and then proceeds with a normal check. If the first backup does not work, try the next block number from the mke2fs output. Keep trying successive backups until one works.
Step 3: If All Superblocks Fail
If every backup superblock fails, the filesystem is severely damaged. Your remaining options are debugfs for manual inode extraction or professional data recovery services. Before giving up, try imaging the drive with ddrescue and running fsck on the image. The original drive may have bad sectors that prevent superblock reads.
What Happens to Your Files in lost+found
When fsck finds inodes that have data but are not connected to any directory, it moves them to the lost+found directory at the root of the filesystem. This happens when directory entries get corrupted and the connection between a file’s name and its data is lost.
Files in lost+found have numeric names like #12345 instead of their original filenames. This is because the filename is stored in the parent directory, not in the inode itself. When the directory entry is lost, the filename goes with it. You can recover the data, but you need to identify files manually by examining their contents.
After running fsck, mount the filesystem and navigate to the lost+found directory:
sudo mount /dev/sdXN /mntcd /mnt/lost+found
Use the file command to identify file types by their content rather than extension:
file *
Then copy recovered files to safe storage. For text files, use head or less to preview content and identify them. For images, open them with an image viewer. For documents, try the appropriate application. Rename files as you identify them and move them back to their proper locations.
Some files may be incomplete or corrupted even after recovery. fsck only reconnects the data blocks it can account for. If some data blocks were lost during corruption, those files will have missing sections or may not open at all.
Repairing the Root Filesystem Specifically
The root filesystem (/) presents a unique challenge because it is always mounted and active when the system is running. You cannot unmount it from within the running system. This is why the Live USB approach exists.
Why Root Needs Special Handling
From the Live USB environment, the root partition of your installed system is just another unmounted partition. You can run fsck on it exactly as described in the main procedure above. The Live USB approach is the cleanest and most reliable method for root filesystem repair.
Alternative: Recovery Mode
If you do not have a Live USB handy, most Linux distributions offer a recovery mode. At the GRUB boot menu, select “Advanced options” and choose a recovery mode entry. This drops you into a minimal root shell with the root filesystem mounted read-only.
From there, you can remount read-only explicitly and run fsck:
mount -o remount,ro /fsck -f /
After repair, reboot normally. If the filesystem was on a separate partition, you may need to identify it first with lsblk.
Alternative: forcefsck Flag
You can force fsck on the next boot by creating an empty file called forcefsck in the root directory:
sudo touch /forcefsck
On the next reboot, the init system detects this file and runs fsck on all filesystems listed in /etc/fstab before mounting them. The system removes the file after the check completes. This is useful for scheduled maintenance but less reliable for severely corrupted systems that cannot boot at all.
Verifying the Repair Was Successful
After running fsck, confirm the filesystem is healthy before trusting it with your data.
Run a final read-only check to make sure fsck reports no remaining errors:
sudo fsck -n /dev/sdXN
A clean filesystem prints “/dev/sdXN: clean, XXXXX/XXXXX files, XXXXX/XXXXX blocks” with no error messages. Check the filesystem state flag:
sudo dumpe2fs -h /dev/sdXN | grep 'Filesystem state'
The output should say “clean.” Then mount the filesystem and browse your files. Open several files to make sure they are intact. Run dmesg to check for any new ext4 error messages during the mount. If everything looks good, reboot into your installed system normally.
Preventing Future Filesystem Corruption
After surviving a filesystem corruption scare, you want to prevent it from happening again. A combination of filesystem tuning, hardware protection, and monitoring goes a long way.
Set Up Automatic fsck Scheduling With tune2fs
ext4 automatically checks the filesystem after a certain number of mounts or a certain number of days. View the current settings:
sudo tune2fs -l /dev/sdXN | grep -i 'mount count|interval'
Adjust the intervals to match your usage. For example, check after every 30 mounts or 30 days, whichever comes first:
sudo tune2fs -c 30 -i 30d /dev/sdXN
This ensures periodic checks catch small problems before they grow into corruption events.
Use a UPS to Prevent Power Failure Damage
Power outages are the leading cause of ext4 corruption. An uninterruptible power supply (UPS) gives your system time to shut down cleanly during an outage. Even a basic UPS that provides 5 minutes of battery backup is enough for a clean shutdown. Configure your system to shut down automatically when the UPS signals low battery using tools like apcupsd or nut.
Keep the Journal Enabled and Healthy
The ext4 journal is your first line of defense against corruption from unclean shutdowns. It records pending changes before they are written to the main filesystem, so interrupted writes can be rolled back on the next boot. Do not disable journaling unless you have a specific reason and understand the trade-off. Check journal status with:
sudo dumpe2fs -h /dev/sdXN | grep 'Journal features'
Monitor Drive Health With SMART
Failing hardware causes corruption that no filesystem tool can prevent. Monitor your drives with smartmontools:
sudo smartctl -a /dev/sdX
Look for reallocated sectors, pending sectors, and uncorrectable errors. If any of these are increasing, replace the drive before it fails completely. Set up smartd to email you when SMART attributes change.
Frequently Asked Questions
How do I repair a corrupted ext4 filesystem in Linux?
Boot from a Live USB, identify the corrupted partition with lsblk, unmount it with umount, then run fsck -p /dev/sdXN for safe automatic repair. For more thorough repair, use fsck -fy /dev/sdXN. Run fsck a second time to catch any newly exposed errors. Never run fsck on a mounted filesystem.
How to run fsck from a live USB?
Boot your computer from a Linux Live USB, open a terminal, and run lsblk -f to identify the target partition. Unmount it with sudo umount /dev/sdXN. Then run sudo fsck -p /dev/sdXN to repair automatically. The Live USB environment keeps all internal partitions unmounted by default, making it the safest way to run fsck.
What is the fsck command in Linux?
fsck (filesystem check) is a Linux command-line utility that checks and repairs filesystems. For ext4 partitions, fsck internally calls e2fsck. It scans filesystem metadata including inodes, the superblock, and the journal, then repairs inconsistencies to restore filesystem integrity. It must be run on an unmounted partition.
How to fix bad superblock ext4?
First, find backup superblock locations with sudo mke2fs -n /dev/sdXN. Then run sudo e2fsck -b 32768 /dev/sdXN to restore the primary superblock from a backup copy. If the first backup fails, try the next block number from the mke2fs output. ext4 stores backup superblocks at predictable block offsets throughout the partition.
How to check ext4 filesystem in Linux?
Run sudo fsck -n /dev/sdXN to perform a read-only check that reports errors without making changes. For a forced full check even on a clean filesystem, use sudo fsck -f /dev/sdXN. You can also use sudo dumpe2fs -h /dev/sdXN to check if the filesystem state is marked clean or not clean.
Why can fsck not run on a mounted filesystem?
Running fsck on a mounted filesystem can corrupt data because both fsck and the kernel may modify the same metadata structures simultaneously. This creates race conditions that can destroy inodes, directory entries, and block bitmaps. Always unmount the partition first, or use a Live USB where the partition is unmounted by default.
Can fsck make corruption worse?
Yes, running fsck -y on a severely corrupted filesystem can delete or rearrange data that might otherwise be recoverable. Always back up the drive first using ddrescue, then run a read-only check with fsck -n to assess damage before attempting automatic repair. Start with fsck -p for safe repairs before escalating to -y.
Conclusion
Repairing a corrupted ext4 filesystem with fsck from a Live USB is a methodical process that anyone can follow with the right commands. The key steps are: create a Live USB, identify your partition with lsblk, unmount it, run a read-only check with fsck -n, then repair with fsck -p or fsck -fy. For severe superblock corruption, restore from a backup superblock using e2fsck -b. Always verify the repair with a final read-only check and inspect lost+found for recovered files.
Remember the safety rules above all else: never run fsck on a mounted filesystem, always back up your data before repairing, and double-check device names before running any command. Prevention through UPS power protection, SMART monitoring, and tune2fs scheduling will keep you from needing this guide again. With these tools and techniques, you can recover from filesystem corruption confidently and get your Linux system back online.