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

penduleum · 05-26-2012, 10:11 AM

I have the folling issue...

I have a nas device (synology).
One of the disks has resently given me a bad blok.

Before i send it to rma, i need to try and recover as mutch as
possible.

The disk is at the moment out of the nas, and via esata connected
to my laptop.
Started a bootable cd, and i have tried to mount it via:

Code:

mount /dev/sdb3 /media/usb/

It gave me the following error:

Code:

mount: you must specify the filesystem type
root@ubuntu:/home/ubuntu# mount -t ext4 /dev/sdb3 /media/usb/
mount: wrong fs type, bad option, bad superblock on /dev/sdb3,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

after reading a bit this topic (similar issue), i did a fdisk -l /dev/sdb3, the output is:

Code:

Disk /dev/sdb3: 995.4 GB, 995370435072 bytes
255 heads, 63 sectors/track, 121013 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/sdb3 doesn't contain a valid partition table

I can see the disk in disk utils. It is partitioned in 3 separated disks. The data is on the last partition sdb3.

How can i find out what kind of file system it is (most likely some sort of raid0) so i can mount it and retrieve the file?

If i do:

Code:

mount -t ext4 -o /dev/sdb3 /media/usb

i get:

Code:

mount: you must specify the file system type

is it better to try and find out what kind of file system it has, and rebuild the partition table, or do you advise other steps to follow?

Ser Olmy · 05-26-2012, 11:18 AM

There's not supposed to be a partition table on /dev/sdb3. /dev/sdb, on the other hand, should contain one.

fdisk -l /dev/sdb will show you the partition ID, which may provide a clue to the identity of the file system.

penduleum · 05-26-2012, 12:00 PM

lol. your right.
i totally forgot that, and saw the sdb3 as the main partition..

here is the outcome of fdisk -l:

Quote:

root@ubuntu:/home/ubuntu# fdisk -l /dev/sdb

Disk /dev/sdb: 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: 0x7e3b7243

Device Boot Start End Blocks Id System
/dev/sdb1 1 311 2490240 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2 311 572 2097152 fd Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sdb3 588 121601 972041440+ fd Linux raid autodetect
root@ubuntu:/home/ubuntu# mount-t fd /dev/sdb3 /media/usb/
mount-t: command not found
root@ubuntu:/home/ubuntu# mount -t fd /dev/sdb3 /media/usb/
mount: unknown filesystem type 'fd'
root@ubuntu:/home/ubuntu#

if i do mount -t fd, i got this:

Quote:

root@ubuntu:/home/ubuntu# mount -t fd /dev/sdb3 /media/usb/
mount: unknown filesystem type 'fd'
root@ubuntu:/home/ubuntu#

i will search the net and hopefully get some answers, in the meantime, i appreciate any input.

michaelk · 05-26-2012, 12:25 PM

The partition ID has no real relationship with its file system type. Do you have any idea what type of RAID (0,1,2,3,4,5,6,10) is configured on your NAS?

I am not familiar with this device but you should be able to access its web configuration pages to determine RAID type.

penduleum · 05-26-2012, 12:47 PM

Quote:

Originally Posted by michaelk

The partition ID has no real relationship with its file system type. Do you have any idea what type of RAID (0,1,2,3,4,5,6,10) is configured on your NAS?

I am not familiar with this device but you should be able to access its web configuration pages to determine RAID type.

if i ame not mistaken, it was mounted just as jbdo.
I cannot rebuild this in to the dsm of the Synology, as it would not recognize this disk, as it has a bad-sector, and the Synology is just very sensitive to this.

the combinations of fdisk shows me this:
sfdisk -d /dev/sdb | sfdisk --force /dev/sdb

Code:

root@ubuntu:/home/ubuntu# sfdisk -d /dev/sdb | sfdisk --force /dev/sdb
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 121601 cylinders, 255 heads, 63 sectors/track
Old situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+    310-    311-   2490240   fd  Linux raid autodetect
/dev/sdb2        310+    571-    262-   2097152   fd  Linux raid autodetect
/dev/sdb3        587+ 121600  121014- 972041440+  fd  Linux raid autodetect
/dev/sdb4          0       -       0          0    0  Empty
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1           256   4980735    4980480  fd  Linux raid autodetect
/dev/sdb2       4980736   9175039    4194304  fd  Linux raid autodetect
/dev/sdb3       9437184 1953520064 1944082881  fd  Linux raid autodetect
/dev/sdb4             0         -          0   0  Empty
Warning: partition 1 does not end at a cylinder boundary
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
root@ubuntu:/home/ubuntu#

catkin · 05-26-2012, 12:49 PM

Before doing any further damage while attempting recovery, it is prudent to image the damaged partition to somewhere else and work on the copy. Some use plain dd to do that; others use ddrescue.

photorec has been recommended on LQ for recovering files from damaged file systems. Posts tagged with photorec are listed here.

foremost has also been recommended but less often.

In case it's a Windows file system, getdataback has been mentioned.

Ser Olmy · 05-26-2012, 01:02 PM

Since the drive was part of a JBOD (Just a Bunch of Disks) set, it may not contain a valid file system at all.

If this was the second drive of a 2-drive setup, the file system bascally starts on drive 0 and proceeds past the end of drive 0 onto drive 1. Even if you could rescue a copy of the superblock, all references would be relative to the start of the RAID device. PhotoRec would be your best bet to recover any data from this disk.

I would agree with catkin that ddrescue is a stellar idea: Back up the entire drive to a (compressed) file, and dd everything back to the replacement drive when it arrives. You may then actually be able to salvage the JBOD RAID array.

penduleum · 05-28-2012, 08:18 AM

thank both of you, catkin and Ser Olmy. Yes, it is a jbdo disk in a ary with 4 1 tb disk.
I have some experience with photorec, so i will try that one. ddrescue? Never heard of it. dd i heard off and played a bit arround.

It is just this disk that has a issue. the rest is just working fine (and already replaced the bad boy).
In any case, i just will try a bunche of tools and juse this disk as a tryout. Just to see what i am able to do with the tools. If i can recover somethin it will be nice, but not a mandatory.

Ho well, it will be a nice project for the 2 upcominhg weekends

the rest of the time working...

thank you for your input.