LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (http://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   wiped first sector of extd partition (http://www.linuxquestions.org/questions/linux-hardware-18/wiped-first-sector-of-extd-partition-572739/)

verbose 07-27-2007 10:00 AM

wiped first sector of extd partition
 
Is it possible to recover data and/or restore partition structure of the underlying logical partitions of an extended partition? I unintentionally wiped the first boot sector of /dev/sdb1 instead of the entire disk. I was under the impression I'd wiped the MBR so I eventually overwrote it as well. Fortunately, I'd copied the partition structure from testdisk prior to this, so I still have the partition table information. However, when I try to mount any of the partitions, mount fails to recognize that the filesystem is ext3.


Thanks

Wells 07-27-2007 10:40 AM

I am not sure on this, but you MAY be able to do an fsck on the filesystem by telling fsck.ext3 to look for different superblocks to recover from.

verbose 07-27-2007 10:43 AM

Unfortunately, I've already tried this and none of the blocks were links to valid superblocks.

unSpawn 07-27-2007 11:36 AM

I think that before you make any alterations you should preserve what's there and make a 'dd' copy. Then check out http://www.cgsecurity.org/wiki/Category:Data_Recovery -> http://www.cgsecurity.org/wiki/Advan...kup_SuperBlock . If you run any other tools, what does Gpart say?

verbose 07-27-2007 11:52 AM

I mirrored the drive, but only after I wiped the MBR. However, as I've said, I copied the partition structure into a forum post and recreated it. gpart AND testdisk (testdisk was even able to view all files) worked before I wiped the MBR. But I find it incomprehensible why both of these tools fail to work anymore after the partition structure was recreated.


Edit: Advanced>Superblock doesn't find any backup ext2.ext3 backup superblocks. I've tried it many times before on both drives.

pixellany 07-27-2007 12:11 PM

This is definitely possible to recover...

An extended partition entry sets the total size of all the underlying logicals, and points to the FIRST logical partition. In the boot sector of that partition, there are 2 entries: 1 for the logical, and another extended which points to the next logical.
All you have to know is where that first logical is.

For the structure of a partition table, go here: http://www.ata-atapi.com/hiwtab.htm

Meanwhile, I'm going to try and generate an example for you....

verbose 07-27-2007 12:29 PM

That's very encouraging news. I have been attempting to recover for just over seven days now. I've put untold hours into recovering my data, so I'd rather not take the drive in for professional data recovery.

I'd think it would be a simple matter of recreating the partition table, but obviously this is not the case.


Thanks for everyones' help so far.


Edit: Example 3 on the page you referred me to is exactly what I'm looking for.

Quote:

Here is a partition record from an extended partition (the first sector of an extended partition). Note that it contains no program code. It contains only the partition table and the signature data.

http://www.ata-atapi.com/hiwtab.htm
As you say, it seems like there'd be an easy remedy for accidentally deleting the first sector of the single extd partition.

verbose 07-27-2007 01:09 PM

Here is something interesting...

Apparently, the BIOS is having trouble assigning the correct names to the three hard drives connected right now. I tried to boot Ubuntu, which is installed on a 250GB hdd, but when I booted using the original 80GB hdd, it booted into Ubuntu. There is no way I installed Ubuntu onto THIS drive since I checked fdisk output beforehand and I determined it was the correct drive with the least number of partitions (Ubuntu) and 250GB in size. 'fdisk -l' still shows the original partition table on the 80GB and 250GB mirrored drives, so something is bungled up in the BIOS, it seems.

Also, when I tried to boot the other two drives, I received 'GRUB error 17' (unable to mount partition), which makes sense. One of the GRUB menus only allowed me to boot kernel 2.6.20-15, which is the kernel Ubuntu uses and the other one didn't even display GRUB. I'm not sure why I'm getting GRUB errors since I wiped the MBR. Maybe it didn't affect the bootloader...



edit: I'm starting to worry that I may have accidentally installed Ubuntu on both the backup and original drive since the GRUB menu is the same as Ubuntu's. However, this wouldn't have been possible unless 'fdisk -l' was displaying incorrect information and the partition table is exactly the same as it ever was on the two salvage drives... completely different from Ubuntu's default partition table. Also, Ubuntu should boot without error if the installation did in fact repartition the drive.

pixellany 07-27-2007 01:19 PM

Here is an example from one of my systems:
Code:

Device Boot      Start        End      Blocks  Id  System
/dev/hda1  *  1        2591    20809992    7  HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/hda2        2592    9729    57335985    5  Extended
/dev/hda5        2592    3866    10241406  83  Linux

This is part of the ouptut of fdisk -l. It tells us that the extended partition does not fall on a cylinder boundary. I could maybe have set fdisk to work by sector, but I'm going straight to the raw data

Code:

root@mherring-xp:/home/mherring# dd if=/dev/hda bs=512 count=1|hexdump -C

 80 01
000001c0  01 00 07 ef ff ff 3f 00  00 00 10 12 7b 02 00 fe 
000001d0  ff ff 05 fe ff ff 5f 23  7b 02 62 c1 d5 06 00 00
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa

This gives us the partition table in the mbr. I've highlighted the partition type and the start and size fields. This tells us that the extended partition starts at sector 027B235F hex = 41624415. Now we'll go grab that sector:

Code:

root@mherring-xp:/home/mherring# dd if=/dev/hda bs=512 skip=41624415 count=1|hexdump -C

000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 fe 
000001c0  ff ff 83 fe ff ff 3f 00  00 00 fc 8a 38 01 00 fe 
000001d0  ff ff 05 fe ff ff a3 9f  b6 06 bf 21 1f 00 00 00 
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa

Success!!! We are now at the partition table in the boot sector of the first logical partition. The first entry tells us that the actual partition begins at an offset of 3F hex (63) from here. The second entry is another extended partition which points to the next logical.


So....All you have to do is determine where your second logical partition is, and then recreate the correct entry for the first logical.

I'll save further details until you either catch up or tell me that you have already gotten ahead of me.....

verbose 07-27-2007 01:42 PM

It will probably take me some time to figure all of this out and I'll probably need a more experienced individual's help.

Right now, however, I'm a bit concerned about the situation I've laid out in post #8. I'm confused why the Ubuntu GRUB bootloader has taken the place of my formerly non-existent(?) bootloader on my other two hard drives. As I've said, the partition table via 'fdisk -l' still looks exactly the same, so it's not as if the Ubuntu install has overwritten the partition table with a new one.


edit: Alright, I'm getting there... somewhat slowly.

dd if=/dev/sda bs=512 count=1|hexdump -C
Code:

000001c0  01 00 83 fe ff ff 3f 00  00 00 4c 97 c0 1c 00 fe  |......?...L.....|
000001d0  ff ff 05 fe ff ff 8b 97  c0 1c f6 ad 5b 00 00 00  |............[...|

1cc0978b hex CORRECT? After using a hex to decimal converter, I get sector 482383755.

dd if=/dev/sda bs=512 skip=482383755 count=1|hexdump -C
Code:

000001c0  ff ff 82 fe ff ff 3f 00  00 00 b7 ad 5b 00 00 00  |......?.....[...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

I'm assuming that 000001d0 is empty since I only have ONE ext partition.


Gparted has the same first sector for the extd partition. :) :(

edit: How do I know that this is the correct partition table since my bootloader now seems to be the Ubuntu one. Isn't the bootloader stored in the MBR?

pixellany 07-27-2007 01:51 PM

I am now confused....
In your first post, you said that you thought you wiped the MBR, but it was really a boot sector. Later, you make references to "wiping the MBR".

Can you boot into anything? If not, can you boot up with a live CD? If you can boot with any Linux, we can see what is going on.....

First, do fdisk -l and post the results

verbose 07-27-2007 02:07 PM

Your confusion is completely understandable. It's a very confusing state of affairs and it's getting awfully difficult to describe the flow of events.

Quote:

In your first post, you said that you thought you wiped the MBR, but it was really a boot sector. Later, you make references to "wiping the MBR".
Yes. I've been under the impression I'd wiped the MBR until last night. People had said to me on a few occasions that the MBR has nothing to do with any partition, but it never quite clicked until last night. What is going on now is somehow Ubuntu installed its bootloader on all three drives, which is rather peculiar. However, the partition tables are still intact on the Debian (my distro) drives.

fdisk -l:
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 8843 71031366 f W95 Ext'd (LBA)
/dev/sda2 * 8844 9726 7092697+ 83 Linux
/dev/sda5 1 3039 24410704+ 83 Linux
/dev/sda6 3040 6686 29294496 83 Linux
/dev/sda7 6687 8510 14651248+ 83 Linux
/dev/sda8 8511 8692 1461883+ 83 Linux
/dev/sda9 8693 8753 489951 83 Linux
/dev/sda10 8754 8765 96358+ 83 Linux
/dev/sda11 8766 8843 626503+ 82 Linux swap / Solaris

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 30027 241191846 83 Linux
/dev/sdb2 30028 30401 3004155 5 Extended
/dev/sdb5 30028 30401 3004123+ 82 Linux swap / Solaris

Disk /dev/sdc: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 8843 71031366 f W95 Ext'd (LBA)
/dev/sdc2 * 8844 9726 7092697+ 83 Linux
/dev/sdc5 1 3039 24410704+ 83 Linux
/dev/sdc6 3040 6686 29294496 83 Linux
/dev/sdc7 6687 8510 14651248+ 83 Linux
/dev/sdc8 8511 8692 1461883+ 83 Linux
/dev/sdc9 8693 8753 489951 83 Linux
/dev/sdc10 8754 8765 96358+ 83 Linux
/dev/sdc11 8766 8843 626503+ 82 Linux swap / Solaris



SDA is the mirrored drive with ddrescue. SDB is the Ubuntu install drive. SDC is the original 80GB hdd. I'm in Ubuntu right now.

pixellany 07-27-2007 02:55 PM

A few posts back, you gave some partition table info for sda, but the data matches what fdisk is telling you for sdb.......So, please confirm:
You are running from sdb and all is well on that drive?
Which partitions can you NOT mount?

From the fdisk output, sda (and c) have a very strange setup, but should still work. None of these disks shows evidence of the boot sector having been wiped out.

Quote:

dd if=/dev/sda bs=512 skip=482383755 count=1|hexdump -C

000001c0 ff ff 82 fe ff ff 3f 00 00 00 b7 ad 5b 00 00 00
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I'm assuming that 000001d0 is empty since I only have ONE ext partition.
No--because you only have one logical partition. Each time you add a logical, it adds an extended to point to it.
Note also that the partition table entries don't line up with the hexdump output. That one partition table above actually starts 2 bytes back at offset 000001be. If there were another, it would be at 000001ce

verbose 07-27-2007 03:12 PM

Well, I _did_ switch the sata cables around once to check what was going on in the BIOS but that was before I replied to your post about the partition table. However, when I switched the cables around between two drives, Ubuntu booted from one of the 250GB hdd's (where it should be) instead of the 80GB hard drive (the original drive) as it had prior to my doing this.

Is it possible that fdisk output was incorrect, just as seems to be the case in the BIOS? I wouldn't imagine so...

Quote:

From the fdisk output, sda (and c) have a very strange setup, but should still work.
That's probably due to the fact I partitioned them manually using the debian-installer.

Quote:

You are running from sdb and all is well on that drive?
That's correct.

I don't know how the Ubuntu bootloader was installed on all of the drives but all the partition tools I've run still show the identical partition structure that I recreated.


edit: I'm still curious what this means in testdisk... No EXT2, JFS, Reiser, cramfs or XFS marker. I've never been able to figure it out.

pixellany 07-27-2007 03:35 PM

Quote:

Originally Posted by verbose
edit: I'm still curious what this means in testdisk... No EXT2, JFS, Reiser, cramfs or XFS marker. I've never been able to figure it out.

Can't help with that one...

What is the current state? With reference to the fdisk output you posted, what now works, and what does not?


All times are GMT -5. The time now is 04:51 PM.