Fedora – EXT4-fs (sdc): VFS: Can’t find ext4 filesystem

fedorafilesystemshard-diskmount

In short, this is where I found the best answers to my problem with my disks: https://help.ubuntu.com/community/DataRecovery

During Fedora 15 installation, I added all my 3 drives to be mounted on boot. However, after the installation ended I could not mount them any more.

During the reboot, I was presented with this message?

**Give root password for maintenance
(or type Control-D for normal startup):**

"Control-D" did not work and I ended turning off manually and reinstalling Fedora 14, in the hope it was a bug, but, as I knew latter, it was not.

So I tried to added the disks manually in fstab:

$ nano /etc/fstab
/dev/sdb1                /media/Unus                     ext4     defaults  0 0
/dev/sdc1                /media/Duo                     ext4     defaults       0 0

But they do not mount:

$ mount media/Duo
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

This is what I get from dmesg:

$ dmesg | tail
[  897.592207] EXT4-fs (sdc): VFS: Can't find ext4 filesystem

However, the disks are there:

$ testDisk

Disk /dev/sdb - 1000 GB / 931 GiB - ATA ST31000528AS
Disk /dev/sdc - 2000 GB / 1863 GiB - ATA ST2000DL003-9VT1

Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63
    Partition                  Start        End    Size in sectors
>   P ext4                     0   0  1 121601  80 63 1953525168 [Unus]

Disk /dev/sdc - 2000 GB / 1863 GiB - CHS 243201 255 63
    Partition                  Start        End    Size in sectors
>   P Unknown                  0   0  1 243201  80 63 3907029168

Note that just before installing Fedora 15, both disks were formatted with ext4 and were working normally.

Is there a way to rebuild the filesystem without losing the data recorded on the disks?

I wish to know what I should do, as both disks have indispensable data in them.

Thanks.

UPDATE:

Following: http://linuxexpresso.wordpress.com/2010/03/31/repair-a-broken-ext4-superblock-in-ubuntu/

As root I ran:

$ fsck.ext4 -vy /dev/sdb

And this recovered one of my disks. So I could mount it:

$ mkdir /media/Unus && mount /dev/sdb

However, I was not so lucky with the other:

$ fsck.ext4 -vy /dev/sdb
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdc
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

As someone suggested, I ran:

$ file -s /dev/sdb1 /dev/sdc1
/dev/sdb1: ACB archive data
/dev/sdc1: LVM2 (Linux Logical Volume Manager) , UUID: XlSIOVm3e8Ozqv4EO0TgTCiKAOdW4V6

Now I am figuring out how to fix disk /dev/sbc – 2000 GB / 1863 GiB – ATA ST2000DL003-9VT1 (which was ext4, by the way).

# e2fsck -n /dev/sdc1

e2fsck 1.41.12 (17-May-2010)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdc1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Some print screens of the disks: http://imgur.com/a/hY6ze

LAST UPDATE

While I am waiting for the new disk to arrive, I was trying some of your suggestions.

In order to try to activate a logical volume, I got this:

# lvchange -ay vg_atipico/**lv_duo**
  One or more specified logical volume(s) not found.

Did I write the command right or should I write instead:

"lvchange -ay vg_atipico/sdc1" ?

Best Answer

First, don't do anything destructive until you understand exactly what's going on. For example, don't run e2fsck without -n on a device unless you're absolutely sure that the device contains an ext2/ext3/ext4 filesystem and that you're in a position to recover it.

Before risking anything destructive, I recommend that you make a copy of the raw disks. Get a disk that's at least as large and copy the whole thing:

cat </dev/sdb >/dev/sdd

(where the disk to save is /dev/sdb and you want to overwrite /dev/sdd — be very careful not to get a single letter wrong!).

/dev/sdb seems to be in an inconsistent state. Apparently it has a partition table that indicates that there is a partition /dev/sdb1, and at the same time it has a filesystem on the whole disk rather than on the partition. If there is indeed a filesystem on the whole disk, there shouldn't be a partition table. Given that you've already done something potentially destructive, I recommend you try copying all the files off the disk. Mount it as read-only:

mkdir /media/b
mount -r -t ext4 /dev/sdb /b
cp -a /media/b /some/place/you/have/enough/space

/dev/sdc1 contains an LVM physical volume. You need to assemble this volume. In fact, the system may have done that already; the data is on the logical volume, not directly on the partition. Run lvs to see what logical volumes are available.

mkdir /media/c
lvs   # You'll probably see a line with "  volumegroupname    logicalvolumename"
mount -r -t ext4 /dev/mapper/volumegroupname-logicalvolumename /media/c

If lvs doesn't show anything, you'll need to activate the volumes first. Run vgs to see a list of available volume groups, vgchange -ay volumegroupname to activate a volume group, lvchange -ay volumegroupname/logicalvolumename to activate a logical volume. If you need help, post the output of pvs, vgs and lvs.

You can try to recover the filesystem structure even if e2fsck doesn't manage. But this requires deep knowledge of the filesystem. Even a professional may or may not get far, depending on precisely which bits were overwritten. TestDisk is a filesystem recovery tool; try unleashing it on your disk.

If you don't manage to repair the filesystem, go fishing for individual files. This may be easy or difficult depending on what kinds of files you're after and how the disk is laid out. A favorable case is large video files that were all written in one go (so each file has a recognizable header and is likely to be unfragmented). An unfavorable case is a tree of source code where you'll have a lot of versions of each file (all but one deleted) and even associating file data with names is part of the difficulty.

There are tools that go looking for recognizable files on a damaged filesystem (or erased files), mostly images and videos and sounds. The TestDisk website has a list of data recovery distributions; CAINE, in particular, is a live distribution specialized in forensics.

Related Question