Emergency UNIX and Linux Support

Not sure it was an old install
Not sure also, but i have a usb disk i used to connect it to the box

here is the ouput of dd

Code:

#dd if=/dev/rdsk/c0d0p0 bs=1024k skip=30 count=512 | od -X | grep 00bab10c | head
6004000        00bab10c        00000000        0000000a         00000000
6006000        00bab10c        00000000        0000000a         00000000
6010000        00bab10c        00000000        0000000a         00000000
6012000        00bab10c        00000000        0000000a         00000000
6014000        00bab10c        00000000        0000000a         00000000
6016000        00bab10c        00000000        0000000a         00000000
6020000        00bab10c        00000000        0000000a         00000000
6022000        00bab10c        00000000        0000000a         00000000
6024000        00bab10c        00000000        0000000a         00000000
6026000        00bab10c        00000000        0000000a         00000000
512+0 records in
512+0 records out
#

Those look like ZFS uberblock magics.

But the offsets are far from where I would have expected to find them. Seems like either there was free space or another partition in front of the ZFS partition.

Okay, so finally we have something consistent. The current partition table and the windows boot loader were written by some unexpected gremlin. The 3% extended partition doesn't exist. The uberblocks are precisely where I expected them to be (@fpmurphy: this offset is not due to an fdisk partition but to the hidden slices 8 and 9 being located before slice 0) so if you are lucky and nothing else beyond a mbr overwriting happened to your disk, your zpool is safe. Your disk has a single Solaris2 partition spanning the whole space available.

You need first to reconstruct your partition table. The correct data to be placed in it should be:

Code:

191   128  0      1      1       254    63     1023    16065     156280320

Unfortunately, Solaris fdisk command is zeroing the vtoc (slice table) should a new Solaris2 partition is created. As we want to preserve the existing vtoc, the trick is to create a partition with another type like this:

Code:

echo "6 128 0 1 1 254 63 1023 16065 156280320" > /tmp/fdisk.txt
fdisk -F /tmp/fdisk.txt /dev/rdsk/c0d0p0

Then, you need to reboot on a CD/DVD and immediately leave the grub menu to the GRUB CLI (press 'c' when the boot menu appears).

From here, you can change the partition type to the correct one with this command:

Code:

parttype (hd0,0) 0xbf

Your pool should then be importable and your data recoverable. By reinstalling grub, you should even have your OS fully recovered and bootable.

Of course, as all these steps involve writing to your disk. You should first make a full copy of your source disk and run the commands I suggested on that copy, not the original. The destination disk needs not to be exactly the same model as the source one, just of equal size or larger.
To perform the copy, either use the command suggested by ilikecow if you are more confortable with Gnu/Linux than Solaris, or run the equivalent Solaris command:

Code:

dd if=/dev/dsk/c0d0p0 of=/dev/dsk/c1d0p0 bs=512k

Adjust c1d0p0 to the correct device should it be different.

@jlliagre
First of all , thanks a milion for your effort in helping me .

As far as i understand so the order of recovery steps as follows and as a precaution i'll summarize my steps ( please correct me if there is something wrong )

1-clone the disk into a new disk . with the following command

Code:

#dd if=/dev/dsk/cxdxpx of=/dev/dsk/cxdxpx bs=512k

2- work on the clone in single user shell and issue fdisk command with the exact arguments

Code:

#fdisk -R - /dev/rdsk/c0d0p0 <<%EOF%
6   128  0      1      1       254    63     1023    16065     156280320
%EOF%

3- boot in GRUB menu cli mode and change the partition type to the correct one
with following command

Code:

parttype (hd0,0) 0xbf

4-My pool should then be importable and my data should be recoverable , i can issue command like

Code:

zpool import rpool

even i can install GRUB and boot into the system

please review

That's a good summary. Just a small comment: "cxdxpx" should be "cxdyp0", p0 being the whole disk.

Correct me if I am wrong but I thought the -R option indicated that fdisk should treat the disk as read-only.

Thanks for pointing that. The command should be:

Code:

echo "6 128 0 1 1 254 63 1023 16065 156280320" >/tmp/fdisk.txt
fdisk -F /tmp/fdisk.txt /dev/rdsk/c0d0p0

I was confused by the symmetric "-W -" (write) option and assumed "-R -" existed, but it doesn't.