How to Fix “e2fsck: Cannot continue, aborting” on GNU/Linux

- abril 01, 2014

(Filesystem Recovery Guide – Real Case from CentOS 6)

Real case (2014): what actually happened

This was the error message I got from my CentOS 6.5 in previous days but I didn't pay attention, because I was trying to boot into Windows 7.
Yesterday, when I finally wanted to boot CentOS, I got the notification that /var was having issues and that I needed to fix it using fsck before mounting it.

I used fsck to clean the filesystem, but after pressing Ctrl+D, the system rebooted. During the next boot, I got stuck again with a message requesting to use fsck to clean the root filesystem, which was mounted as read-only (ro).

How was it possible to have the root filesystem mounted as read-only and at the same time be asked to run fsck? This was not expected, so I started searching for answers.

After checking different forums, I decided to use a Live CD, clean all filesystems using fsck, and boot again.
Same result.

At that point, it was clear that the problem was not fsck itself nor filesystem corruption. I stopped troubleshooting that night because it was already very late.

The next afternoon, I revisited an option I had initially discarded: checking the initrd/initramfs file.

Root cause discovered: missing initramfs

I booted using a different kernel, and everything worked perfectly.

The initrd file for
2.6.32-431.5.1.el6.x86_64 → present and working
The initrd file for
2.6.32-431.11.2.el6.x86_64 → missing

So the real question became: how do you recreate the initramfs properly?

You can look here directly but to save you time here are the steps:

Updated technical guide (2025): safe solution

Rebuilding initramfs on CentOS 6

First, create a backup of the current initramfs:

cp -p /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak

Now rebuild the initramfs for the currently running kernel:
```
dracut -f 
```
If you need to build it for a specific kernel version (replace accordingly):
```
dracut -f /boot/initramfs-2.6.32-358.el6.x86_64.img 2.6.32-358.el6.x86_64
```
One useful option you might want to add is -H (--hostonly). With this option dracut installs only what is needed for booting your system. Otherwise dracut by default adds many drivers to the initramfs making its size larger than necessary. Many other options may be exercised. Please see man dracut, man dracut.conf and the upstream Deployment Guide.

Reboot cleanly

cd /
sync
telinit 6

After rebooting, the system reported that the kdump file did not exist and created it automatically.
The boot process completed cleanly, without errors.

Disk order confusion (secondary issue)

After this, all required files were present and the system booted correctly.
How did this happen? I honestly don’t know.

The only major recent change was installing a new 1 TB hard drive, which caused the device order to change:

/dev/sda → new disk (should have been /dev/sdc)
/dev/sdb → OS disk (should have remained /dev/sda)
/dev/sdc → data disk (should have been /dev/sdb)

In theory, disk order should not matter if you rely on:

UUID
LABEL
Volume ID

I was using labels, and lsblk -f confirmed everything correctly.

Out of personal preference, after talking with a friend, I changed how the SATA cables were connected on the motherboard.
The drives appeared again in the order I wanted.

Update: the real underlying problem

Important: None of the above fully fixed the issue.
It only allowed the system to boot and be usable again.

The real problem was an incorrect option in /etc/fstab for Windows partitions.

The actual mistake

I was using:

ntfs

Instead of:

ntfs-3g

Key takeaways

Not all fsck loops are filesystem corruption
Missing or broken initramfs can cause misleading fsck errors
Always verify /etc/fstab, especially after disk changes
Mixing Linux and Windows partitions requires correct filesystem drivers

Buscar este blog

Espacio Mixto