Fix "Failed to Mount /sysroot" on Rocky Linux

 There are few things more heart-stopping for a System Administrator than watching a server boot, only to see it hang and drop into the dreaded Dracut Emergency Shell.

If you are seeing the error Failed to mount /sysroot followed by a prompt that looks like dracut:/#, your system has failed to load the root filesystem. On Rocky Linux (and RHEL/AlmaLinux), this is almost always caused by XFS filesystem corruption following a hard shutdown, power loss, or hypervisor crash.

---

Prerequisite: Understand the Environment

You are currently in the initramfs environment. This is a small, temporary filesystem loaded into memory before the real disk is mounted. Because the real disk is corrupted, the OS cannot transition to it.

Note: Rocky Linux uses XFS as its default filesystem. Unlike EXT4 (which uses fsck), XFS has its own set of tools, specifically xfs_repair.

---

Step 1: Identify Your Root Partition

First, you need to find the specific device name of your root partition. Since you are in a limited shell, standard commands like lsblk might not show what you expect.

Run the block ID command:

Bash

blkid

You are looking for a device labeled root or an LVM path.

• Standard Partition: /dev/sda2 or /dev/nvme0n1p2

• LVM (Most Common): /dev/mapper/rl-root or /dev/mapper/rocky-root

Can't see the /dev/mapper entries? If you use LVM (Logical Volume Manager) and don't see your volumes, they are likely inactive. Activate them manually:

Bash

lvm vgchange -ay

Run blkid again. You should now see your root volume.

---

Step 2: The Repair Process

Crucial Rule: Never run a filesystem repair on a mounted partition. Since the boot failed, your partition is likely unmounted, which is exactly what we want.

Attempt 1: Standard Repair

Run the repair command against your specific root device (replace the path below with the one you found in Step 1):

Bash

xfs_repair /dev/mapper/rl-root

Scenario A: Success If the command runs, shows a flurry of text, and ends with done, you are safe. Proceed to Step 3.

Scenario B: "Filesystem has a dirty log" If xfs_repair fails and says the log is dirty, it means there is pending metadata in the journal. It will suggest you mount and unmount the filesystem to replay the log.

Try to mount it manually to let the journal replay:

1. mount /dev/mapper/rl-root /sysroot

2. umount /sysroot

3. Run xfs_repair /dev/mapper/rl-root again.

Attempt 2: Force Log Zeroing (The "Nuclear" Option)

If the mount fails, or if xfs_repair refuses to run because the log is too corrupt, you must use the -L flag.

Warning: The -L flag forces the filesystem to zero out the log. This means you may lose the metadata for the most recent file operations that were occurring exactly when the server crashed. However, this is often the only way to make the disk mountable again.

Bash

xfs_repair -L /dev/mapper/rl-root

You should see output indicating that the log is being destroyed and the filesystem is being rebuilt.

---

Step 3: Verify and Reboot

Once the repair returns cleanly, verify that the filesystem is mountable.

1. Test Mount:

   Bash

   mount /dev/mapper/rl-root /sysroot
   

   If this command returns no output, it worked.

2. Reboot: You can now exit the Dracut shell. The system will detect the exit and attempt to resume the boot process.

   Bash

   exit
   

   (Alternatively, type reboot to restart the machine entirely).

---

Troubleshooting: "It still won't boot!"

If xfs_repair says the disk is clean but you still get boot errors, the issue might be in your /etc/fstab file (e.g., a secondary drive is failing, and the OS refuses to boot without it).

To check this from the Dracut shell:

1. Mount the system: mount /dev/mapper/rl-root /sysroot

2. Change root: chroot /sysroot

3. Edit fstab: vi /etc/fstab

Comment out any non-essential drives (like data drives or swap) to see if the system will boot with just the root drive.

---

Summary

The "Failed to mount /sysroot" error is intimidating, but xfs_repair is a robust tool.

1. Use blkid to find your device.

2. Use lvm vgchange -ay if using LVM.

3. Run xfs_repair /dev/device-name.

4. Use -L only if absolutely necessary.