Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Something strange (don't ask) happened on my external hard-drive, resulting in (important) data being unreachable... I am failing to mount it. That data was sitting on a vfat filesystem.

I can get much of it with one tool, foremost. It sorts it into directories by file type, but I need the data intact in its original directory structure. Also, this tool gives the resulting files some random names, and is limited to a set number of file types.

It appears to me that the partition table is damaged (not sure), and I don't know how to fix it. Here's the output of gpart for the whole drive:

# gpart -vd /dev/sdb

dev(/dev/sdb) mss(512) chs(121601/255/63)(LBA) #s(1953520065) size(953867mb)
Primary partition(1)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Primary partition(3)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 947827mb #s(1941150015) s(12370050-1953520064)
   chs:  (770/0/1)-(1023/254/63)d (770/0/1)-(121600/254/63)r
   hex:  00 00 C1 02 83 FE FF FF 82 C0 BC 00 3F 99 B3 73

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The one parition I'm interested in is one that's claimed to be Linux ext2 filesystem. That can't be accurate from my knowledge (it was vfat, but it could also have been NTFS, who knows). It also, that can't be accurate, according to another output of gpart (should I trust it?), this time specifying just that partition:

# gpart -vd /dev/sdb3

dev(/dev/sdb3) mss(512) chs(120831/255/63)(LBA) #s(1941150015) size(947827mb)

* Warning: strange partition table magic 0x606B.
Primary partition(1)
   type: 031(0x1F)(UNKNOWN)
   size: 522639mb #s(1070366139) s(4182104394-5252470532)
   chs:  (961/156/44)-(97/173/28)d (260323/244/28)-(59601/209/5)r
   hex:  F7 9C EC C1 1F AD 1C 61 4A D9 45 F9 BB 7D CC 3F

Primary partition(2)
   type: 249(0xF9)(UNKNOWN)
   size: 47812mb #s(97919955) s(4081875516-4179795470)
   chs:  (993/11/62)-(249/64/22)d (254084/254/55)-(260180/59/54)r
   hex:  D4 0B FE E1 F9 40 16 F9 3C 7A 4C F3 D3 23 D6 05

Primary partition(3)
   type: 211(0xD3)(UNKNOWN)
   size: 711401mb #s(1456950127) s(4249722057-5706672183)
   chs:  (671/191/48)-(644/231/52)d (264532/245/43)-(87874/144/6)r
   hex:  63 BF B0 9F D3 E7 B4 84 C9 9C 4D FD 6F 4B D7 56

Primary partition(4)
   type: 089(0x59)(UNKNOWN)
   size: 715318mb #s(1464971513) s(1293543745-2758515257)
   chs:  (1003/227/11)-(789/19/55)d (80519/95/26)-(171709/161/30)r
   hex:  43 E3 CB EB 59 13 F7 15 41 E9 19 4D F9 B0 51 57
share|improve this question
    
I am running out of ideas recovering this data, so if anyone cares about rep, I got a Bounty... –  Tshepang Jun 13 '11 at 9:48
1  
Recovering a damaged filesystem structure is hard. I won't say it's impossible, but it's a lot more difficult than recovering files with known signatures (e.g. text files, images, …) as suggested in your previous thread. –  Gilles Jun 13 '11 at 21:51

2 Answers 2

Do you think its a partition boundry issue, or do you know the disk has hardware errors?

Some things to try:

  • Copy (dd) the partition contents to somewhere and then change the partition type back to Vfat/NTFS
  • Try different FS mount options, etc.
  • Restore from a copy of the original partition layout (maybe from an old anaconda install log, etc.)
share|improve this answer
    
I think the hard drive is in good condition because I was able to perform a dd of the entire 900GB+ partition to another hard drive. I also tried multiple -t mount options. –  Tshepang Jul 13 '11 at 14:09

Use dd or ddrescue (or dd_rescue) to image the failing drive if you have sufficient space on another one for it. If the original drive has a hardware error, then it's good to have a master copy. You might also be able to mount (a copy of) the master image as a block device (loopback with 'mount -o'?).

share|improve this answer
    
You probably meant this kinda command: sudo mount /dev/sdb3 temp -t vfat -o loop=/dev/loop0. It gives me the same errors as if I had mounted it normally. See the full story here. –  Tshepang Jun 13 '11 at 13:55
    
I tried dd, drescue and dd_rescue already, and it's all confusing. They report no errors and for the tool that does the actual copying (I don't remember which), the results are the same as the original (i.e. unmountable filesystem). Well, unless I don't know how to use them. –  Tshepang Jun 13 '11 at 13:58
1  
@Tshepang: dd_rescue and friends are for pulling data off a dying hard drive. They won't help you here, since you have a damaged filesystem structure but are able to read each byte of it without trouble. –  Gilles Jun 13 '11 at 21:50
1  
@Gilles: That's correct. @Tshepang: since you didn't mention the particulars of how this happened, I assumed that a hardware error could be involved. Even if not, you should retain an image of it to roll back to if an attempted solution does not work out. –  Not Sure Jun 20 '11 at 21:25
    
@Tshepang (first comment): I was hoping there is a way to expose the entire drive image as a single device, then do some magic, then attempt to mount a single partition from it. I'm sorry I couldn't be of any real help. Good luck! –  Not Sure Jun 20 '11 at 21:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.