File system damage can result in the computers/servers being unable to access the operating system. This situation commonly occurs after an abnormal power outage followed by a reboot.

For instance, if a CentOS 7 server experiences an unexpected power outage, the file system may become corrupted. After rebooting, it may fail to enter the operating system and instead enter Emergency mode. Running the journalctl command may reveal critical error messages such as:

  1. Failed to recover EFIs: This error message indicates a problem with the EFI (Extensible Firmware Interface) system partition, possibly due to EFI partition corruption.
  2. Failed to mount /sysroot: /sysroot is the location where the root file system is mounted early in the boot process. If the system fails to mount this directory, it typically indicates an issue with the root file system.
  3. Dependency failed for initrd Root File System: This message implies that the initial RAM disk (initrd) failed to load necessary drivers and modules to correctly mount the root file system.
  4. Dependency failed for Reload Configuration from the Real Root: This message also indicates an inability to access the root file system.
  5. task mount:2744 blocked for more than 120 seconds: This message suggests that a process is blocked, possibly due to file system or hardware issues.

Considering the unexpected shutdown due to a power outage, it is likely that the server experienced file system damage, leading to the inability to access the operating system.

The steps to resolve the failure of unable to access the operating system due to file system damage generally consist of three stages:

  1. Enter a third-party operating system using LiveCD or similar methods.
  2. Identify the faulty file system partition.
  3. Run the appropriate repair command based on the file system type to attempt to repair the file system.

Accessing a Third-Party Operating System via LiveCD

Taking CentOS 7 as an example, boot from the CentOS 7 installation image. Once in the installation program navigation, choose Troubleshooting. When prompted to search for locally installed Linux operating systems and mount the root directory to /mnt/sysimage, select 1) Continue. This will lead you to the Shell prompt.

Identifying Faulty File System Partitions

Use commands such as fdisk -l, lsblk, blkid etc., to identify the file system partitions to be repaired based on characteristics such as partition size and file system type.

Repairing the File System

Different file system types require different repair commands.

For XFS file system type, use the xfs_repair command for repair:

xfs_repair <file system partition path>

For example:

xfs_repair /dev/mapper/centos-root

If you encounter the following error message after running the repair command:

ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and umount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair.

Follow the error message prompt and try adding the -L option to the command:

xfs_repair -L <file system partition path>

For ext4 file system type, use the e2fsck command for repair:

e2fsck -f <file system partition path>

Here, the -f option is used to ignore the ext4 file system’s clean flag (set when the file system is unmounted normally, indicating the file system was unmounted properly without detecting any errors), to check the file system for potential inconsistencies and faults.

After repair, you can use the mount command to attempt to mount the file system partition. If the repair is successful, the file system should be mounted without errors.