Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 17
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2007
    Posts
    14

    Question 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.
    Attached Images Attached Images

  2. #2
    Linux User
    Join Date
    Dec 2011
    Location
    Turtle Island West
    Posts
    362
    sda3 will NEVER have a valid partition table. /dev/sda might however. What is the output of

    fdisk -l /dev/sda

    ?

  3. #3
    Linux User
    Join Date
    Dec 2011
    Location
    Turtle Island West
    Posts
    362
    As an addendum, doing a bitwise copy (dd) of one whole disk to another will rarely work like you think, unless they are identical disks. The raw data gets copied, but the disks have different structures, therefore the pointers in the MBR and partition table that worked on the original disk will not be pointing correctly on the new disk, because they are relative to the individual disk, not the data.

    Also, most drives these days handle their own internal IO to a large degree and keep the grisly details from the OS, so what they *appear* to be doing may or may not have much to do with what they are *actually* doing inside.

    Keep in mind, however, I haven't hand-rolled an MBR or partition table in 20 years, so I'm just gesturing vaguely in that direction.

    Have you tried "e2fsck -fv /dev/sda3" to see what it comes up with? Maybe you have bad blocks or something.

  4. #4
    Just Joined!
    Join Date
    May 2013
    Posts
    37
    It seems to me that you have copied by dd your PATA disk as a block device to the new hard disk. In that case you would need to mount it as a loop device to get access to it, that is, to see its contents. You could try something like:
    Code:
    mount -o loop=/dev/loop0 <the-160-gig-blob>  /mnt
    and see if it works. You may have to play around with the name of the blob. If the mount is successful then you would navigate to the directory /mnt where all the contents of the original disk should appear.

  5. #5
    Linux User
    Join Date
    Dec 2011
    Location
    Turtle Island West
    Posts
    362
    Not sure OP is even listening, but the way I would try to solve the problem is:

    1. Run fsck on /dev/sda3. See what happens there.

    But I have a guess that OP maybe got the dd if/of backwards. That would explain things, wouldn't it? Copy a 1TB drive to a 50GB partition instead of the other way around?

    *** WARNING ***

    'dd' can be a VERY dangerous command for n00bs. 'dd' is NOT a toy. It is possible to destroy things faster with 'dd' than with 'rm'.

  6. #6
    Just Joined!
    Join Date
    Sep 2007
    Posts
    14
    Thank you for your replies!

    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:
    e2fsck -fv /dev/sda3
    e2fsck 1.40-WIP (14-Nov-2006)
    Couldn't find ext2 superblock, trying backup blocks...
    e2fsck: Bad magic number in super-block while trying to open /dev/sda3
    
    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>
    Quote Originally Posted by Miven View Post
    As an addendum, doing a bitwise copy (dd) of one whole disk to another will rarely work like you think, unless they are identical disks.
    The disks geometries are very similar. They both are Barracuda. I'll post what fdisk -l prints for the old disk on Saturday.
    Оf course I don't know what the disks internally do.

    Quote Originally Posted by avek View Post
    You could try something like:
    Code:
    mount -o loop=/dev/loop0 <the-160-gig-blob>  /mnt
    Can you give more information what I must put instead <the-160-gig-blob>? What is this device: /dev/loop0

    Quote Originally Posted by Miven View Post
    Not sure OP is even listening
    What is OP?

  7. #7
    Just Joined!
    Join Date
    Apr 2013
    Posts
    69
    Quote Originally Posted by No_root_No_cry View Post
    Can you give more information what I must put instead <the-160-gig-blob>?
    When you used the dd command, you had to put an output file (specified by dd of=file_where_to_output_datas) otherwise the data has been wrote to the standard output. Now, you have to replace <the-160-gig-blob> by the file name that you entered as a parameter to the of of the dd command.

    Quote Originally Posted by No_root_No_cry View Post
    What is this device: /dev/loop0
    When you use dd, the output file is a block file that you have to write somewhere. You have to chose to write that file on the source disk (your case) or on the destination disk. In both cases, you have to create a special loop device (see losetup) that allows you to write the output file (of from dd) on the disk without being re-read while creating the dd output file (redundancy). Same thing apply if you write the of file of dd on the destination disk (that will become the source disk for dd) when reading the file (dd if=filename).

    For more information, you can check the man pages of dd, losetup and mount.

  8. #8
    Just Joined!
    Join Date
    Apr 2013
    Posts
    69
    Not sure, but I think that OP stands for Old Pata ...

  9. #9
    Just Joined!
    Join Date
    May 2013
    Posts
    37
    OP = original poster = the person who posted the original message

  10. #10
    Just Joined!
    Join Date
    May 2013
    Posts
    37
    No_root_No_cry said originally:
    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.
    I could be on the wrong track with this problem, but here are my observations anyway.

    On re-reading this I am unclear as to whether there was a problem with the PATA disk in the first place because of the words: "the problem is not only on the new drive but also on the old." If there was a problem reading the data on the old disk then moving the partition as a whole to a new disk could help in recovering the data because it leaves the original disk alone and allows you to work on the copied image to try and recover data so that you don't do more damage to the original partition. In such cases you would use dd to copy the partition as a block device. And you would have to mount that block device as a loop device as mentioned in my earlier email and followed up with more information by chris_inx.

    However, on inspecting the output of the fdisk -l command, it looks to me like there is only about 200 gigabytes being registered on a 1000 gigabyte disk. Normally an installation would use the whole disk which fdisk would show so it looks like lots of the disk has not been made available.

    The other oddity is that /dev/sda3 looks to be about 50 gigabytes so it could not possibly contain a file of 120 gigabytes. So I can't see how the whole contents of the original 120 gig PATA disk could be contained in /dev/sda3 on the new disk. So it's unclear to me at this point.

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •