My (recovered) partition table says that partitions start 31

[lucastx]

TL;DR: The partition table that I recovered with TestDisk say that my three ext4 partitions begin exactly 316 bytes before they really begin. I don't know how to make a partition table that says exactly where it starts. (see fdisk output after the jump)

Hello,

I have a Seagate Barracuda ST31000333AS HD (1TB of storage), and I recently bought an external case for it. It was already formatted with 3 ext4 partitions.

The last thing I remember is deleting a HFS partition (it has something to do with my love's Macbook), and then... the partition table was gone.

I tried some tools to recover the partition table, and I finally thought that TestDisk got it right... well, it almost did.

The sizes and positions of the recovered partitions seemed just right, but I couldn't mount it. And the type of the partitions in this new table was ext3, not ext4.

After a lot of hexdump's and dd's, I learned a few things about partition tables and (sort of) discovered the problem:

Code:

lucas@blackie:~$ sudo dd if=/dev/sdc1 of=/tmp/with_offset ibs=1 skip=316 count=1048576     /dev/null
lucas@blackie:~$ file /tmp/with_offset
/tmp/with_offset: Linux rev 1.0 ext4 filesystem data, UUID=d94f8233-7b02-4d9e-a20a-18831225c990, volume name "todomundo" (extents) (large files) (huge files)

What I'm doing here is copying the the first megabyte of the partition with an offset of 316 bytes. The result is recognized as the original partition. This happens with all the three ext4 partitions that are in the disk.

But partition tables deal with cylinders and sectors, not bytes. I can't put the right address in the table with any of these two units.

I didn't mess with disk geometry at any point of this story. Anyway, I don't know if TestDisk changes the geometry without warnings, so the geometry may be wrong. The geometry of the disk right now is:

255 heads, 63 sectors/track, 121601 cylinders
Sector size (logical/physical): 512 bytes / 512 bytes

I downloaded the HD manual, and it says that the default geometry is:

Heads: 6
Discs: 3
Bytes per sector: 512
Default sectors per track: 63
Default read/write heads: 16
Default cylinders 16,383

But when I try to feed TestDisk with this information, it says that my HD has 8455MiB, which is not true.

I have an intermittent connection with the Internet (I have no Internet at home, and I usually have to take a bus or walk ~30min to access it), but I did my homework: applied my google fu, flirted with hexdump and dd, RTFM... I have no idea what to do.

fdisk -l -u: (Brazilian Portuguese, I'm sorry)

Code:

Disco /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total de 1953525168 setores
Unidades = setores de 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificador do disco: 0x000e09b9

Code:

Dispositivo Boot Início Fim Blocos Id Sistema
/dev/sdc1              63  1232731709   616365823+  83  Linux
/dev/sdc2   *  1234675575  1646325134   205824780   83  Linux
/dev/sdc3      1646325135  1953520064   153597465   83  Linux

[lucastx]

bump...

Is there an admin who could change the post's title? It should be "My (recovered) partition table says that partitions start 316 bytes before they should!"

Thanks

[fzabkar]

Can we see a hex dump of sectors 0 and 63?

BTW, the CHS values reported by the drive are for compatibility purposes only. The drive also reports its total capacity in LBAs. I don't know about Linux, but TestDisk and pre-Vista versions of Windows will assume that a drive has 255 logical sectors, and 63 logical heads per track. The total number of logical cylinders is then computed as follows:

logical cylinders = LBAs / 255 / 63

In any case, the partition table records the size of each partition in LBAs.

As for the 316 byte offset, it sounds like you may have created an image file with a 316 byte header, and then used dd to write it back to your drive.

[lucastx]

hexdump of sectors 0 and 63: http://pastebin.com/80d8GsEs

I'll show you how I came to the conclusion that the beginning of the partition is shifted 316 bytes:

Firstly, I checked /usr/share/file/magic, to discover how the system recognizes a Linux (ext2, ext3, ext4) partition:

Code:

0x438   leshort         0xEF53          Linux

This means that there must be "53 EF" (reversed because of the endian stuff) written at position 0x438 of the partition device/file.

Since my partition begins at sector 63, "53 EF" should be at HEX(63 * 512) + 0x438 = 0x8238...

Code:

00008220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
[b]00008230  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/b]
00008240  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Well, it's not.

But let's see the byte number 0x8238 + HEX(316) = 0x8374:

Code:

00008370  22 00 18 00 [b]53 ef [/b]01 00  01 00 00 00 ee c3 46 4c  |"...S.........FL|

There it is! I discovered the exact position searching for "53 ef". Then I tried that dd with an offset to check if I was really right.

You see, if I had simply overwritten the first bunch of bytes with dd, the magic bytes that characterize Linux partitions would be still in the right place (or would not be there at all, if the bunch of bytes were bigger than 0x438).

---

I ran this hexdump in a desktop computer, with the hard disk connected via SATA with the motherboard (not with an external case). I thought that the external case might "give" the OS the wrong disk geometry, so I tried this way, because it was the way that the original partition table was created.

Unfortunately, it doesn't solve the problem; the 316-byte offset is still there. I tried TestDisk again and the same -- wrong -- results appeared.

I don't have any idea how things got screwed up like this. It seems like magic. It's very very upsetting to stare at data in hexdump, to *really know* that the data is there, sitting, but to be unable to access it. It also raises some philosophical questions ("is the data really there if no computer can read it?"), but this is stuff for another thread

[fzabkar]

The partition table in sector 0 is as follows:

Code:

0x1be  00 01 01 00 83 3b 3f e6 3f 00 00 00 71 6d 70 74

This is indicating a Linux partition (type 0x83), of size 0x74706d71 LBAs (= 1 000 204 853 760 bytes), beginning at LBA 63 (0x0000003f). The starting and ending CHS values are 0/1/1 and 230/60/63 (<-- these numbers look strange to me)

See the PTGUIDE.TXT file in the following archive for information on how to interpret the partition table data:
http://mirror.href.com/thestarman/asm/mbr/Mbrdemo.zip

I have no experience with Linux file system structures, but I would think that sector 63 should contain boot code plus a parameter block. Instead yours contains zeroes.

FWIW, I found this thread:
http://forum.soft32.com/linux2/identify ... 11075.html

It confirms what you are saying about offset 0x438. Have you tried creating an ext3 partition on another drive to compare the file system structure?

[lucastx]

Yes, I tried. It was while trying to create another ext3 partition and compare both that I discovered that apparently all my partitions are "shifted" 316 bytes.

If I had another 1TB hard disk, I could dd the partitions from one disk to another, such that the 316th byte from the old partition would be the 1st byte of the new one, the 317th of the old one would be the 2nd of the new one etc.

But I don't have one...

[fzabkar]

I have seen a hardware fault in a minicomputer disc drive where a single bit was dropped, causing all the bits in a particular sector to be shifted. However, I can't think of any mechanism whereby a whole block of sectors would have been shifted in that way, unless it was during a cloning process. Furthermore, the absence of any data in the boot sector is odd, too.

I can't see how you could safely recover your data without an additional drive. Assuming that only the beginning of the file system has been shifted, have you attempted to determine the sector at which it comes good, assuming this is possible? If only the first 10MB are shifted, say, then you could dd these data to an image file, remove the offset, and dd it back again.

[poehere]

Advise to you work from a clone. If you screw up the clone you can always try again. If you screw up your drive you can not try again. I really would not try anything more on this one until you had a clone of your drive to work from. Then you can do what ever you want to try and fix this problem.

[lucastx]

@fzabkar

I never cloned the HD. What apparently screwed up everything was when I tried to delete a partition (the whole partition table disappeared).

Then I tried running TestDisk, and it "recovered" this 316-byte-shifted monster.

I also doesn't see how I could do this without another HD. I even think I know the exact command that would work if I had another drive:

Code:

dd if=/dev/sda1 of=/dev/sdb1 ibs=1 offset=316

(/dev/sda1 being my HD's first partition, /dev/sdb1 being the auxiliary HD's first partition).

I could do this trick with an image file, if only I had another place to store the image file. My three partitions in this HD are too big for my notebook's storage.

I think I'll have to wait until I find someone with a big enough drive.

@poehere

That's what I'm going to do. Thanks!