LinuxQuestions.org - Unable to detect filesystem or/and partition not recognized

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - Unable to detect filesystem or/and partition not recognized (https://www.linuxquestions.org/questions/linux-general-1/unable-to-detect-filesystem-or-and-partition-not-recognized-4175474368/)

Unable to detect filesystem or/and partition not recognized

The partition is there but its filesystem is unknown. The filesystem must be ext3 or ext2, more likely ext3.

See attached screenshot.

Code:

mount: wrong fs type, bad option, bad superblock on /dev/sda3,

      missing codepage or helper program, or other error

      In some cases useful info is found in syslog - try

      dmesg | tail  or so



dmesg | tail

VFS: Can't find ext3 filesystem on dev sda3.

VFS: Can't find an ext2 filesystem on dev sda3.



fdisk /dev/sda3 -l



Disk /dev/sda3: 51.6 GB, 51621857280 bytes

255 heads, 63 sectors/track, 6276 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00000000



Disk /dev/sda3 doesn't contain a valid partition table

I tried TestDisk but it suggests very different partition table.
I'm not sure that the problem is in the partition table, because partitions look good and another partitions run well. The problem is only for sda3, probably it's filesystem.

What else I can try before trying to find files using PhotoRec?
My goal is to recover the filesystem, not only separate files because partition is used on production server.

The full story: My old PATA drive has 160 GB and I upgraded the system with new 1 TB SATA drive. Using dd I copied whole old drive to the new one. But the problem is not only on the new drive but also on the old. Therefore we cannot blame the copying (dd) for the situation, I think.

Quote:

fdisk /dev/sda3 -l

Will not work, you should use this command

Code:

fdisk -l /dev/sda

Check what filesystems are supported on your system with

Code:

cat /proc/filesystems

You can check data on disk for some clues

Code:

hexdump -C -n 2048 /dev/sda3

IF this problem also occured on old system, when it begins?

Code:

fdisk -l /dev/sda



Disk /dev/sda: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x8f800000



  Device Boot      Start        End      Blocks  Id  System

/dev/sda1              1        6654    53448223+  5  Extended

/dev/sda2            6655      13181    52428127+  83  Linux

/dev/sda3          13182      19457    50411970  83  Linux

/dev/sda5  *        5223        6527    10482381  83  Linux

/dev/sda6            6528        6654    1020096  82  Linux swap / Solaris

/dev/sda7              1        5222    41945620+  83  Linux



Partition table entries are not in disk order

Code:

cat /proc/filesystems

nodev        sysfs

nodev        rootfs

nodev        bdev

nodev        proc

nodev        cpuset

nodev        debugfs

nodev        securityfs

nodev        sockfs

nodev        pipefs

nodev        futexfs

nodev        tmpfs

nodev        inotifyfs

nodev        eventpollfs

nodev        devpts

        cramfs

nodev        ramfs

nodev        mqueue

nodev        usbfs

        ext3

        ext2

Code:

hexdump -C -n 20000 /dev/sda3

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00004e20

Quote:

Originally Posted by eSelix (Post 5014335)

IF this problem also occured on old system, when it begins?

I believe (I'm not sure) the old system works and the disk was in good condition before shutdown. After that I started to copy the disk with dd (for some hours) but the speed was 1.5MB/s and I stopped it. I'd started dd about 20 times with different parameters (blocksize) to detect optimal speed before starting the final clone (~68MB/s). I don't know when and why the partition damaged.

On hexdump output it seems this partition is empty. You can look deeper by changing "-n" parameter. If you played with "dd" and you had performance penalty, there is some probability that you overwrote it. Are you sure never invoked "dd" with "of=/dev/sda*" or that new connected drive has not been assigned to "/dev/sda"?

Quote:

Originally Posted by eSelix (Post 5016943)

Are you sure never invoked "dd" with "of=/dev/sda*" or that new connected drive has not been assigned to "/dev/sda"?

I was very careful. The source was /dev/hda because it is PATA drive I guess.

Code:

hexdump -C -n 8000000000 /dev/sda3

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

41dc5400  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

*

41dc5800  ff ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  |................|

41dc5810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

7ffffff0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00    |...............|

7fffffff

Is this output tells something to you? It seems bad for me.

That means that all 2GB on this partition are "zeros". The good thing is that if you did not used any tool to empty partition, like dd or shred, then most likely there were no any data on this partition from beginning.

Quote:

The source was /dev/hda because it is PATA drive

It depends on used drivers/kernel.

It seems there is no easy way to recover the partition.
I've restored much of the data from a backup. For now I stop trying to recover the partition.
Thank you for your help!