corrupted partition table?

[kaiseroskilo]

i used to have ubuntu 9.i decided to move to sabayon so i used the live cd to install it ,resize the ubuntu partition and use the remaining space for sabayon.while the resizing procedure i got an error(i dont have a copy of the error log file but i know it has something to do with an anaconda process).i aborted the installation and the result was an filesystem that couldnt be mounted.when i try to mount the hdd i get this:

Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

and this is what i get from fsck:

  $ sudo fsck -f /dev/sdb1
fsck from util-linux-ng 2.17.2
e2fsck 1.41.11 (14-Mar-2010)
The filesystem size (according to the superblock) is 38407424 blocks
The physical size of the device is 38407416 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

this is the partition table:

GNU Parted 2.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: Generic External (scsi)
Disk /dev/sdb: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size    Type      File system     Flags
 1      32.3kB  157GB  157GB   primary   ext4            boot
 2      244GB   250GB  6185MB  extended
 5      244GB   250GB  6185MB  logical   linux-swap(v1)

some extra info:

 $ fdisk -l /dev/sdb
Cannot open /dev/sdb

i dont really know what happened but i want to recover some of my data...i dont care about restoring the system.help would be appreciated.thanks in advance

[Irithori]

Hmm, hope you made a backup first.

Resizing a partition is a very heavy process, as it will move about any file and re-organize the filesystem logic.
That's why even with recovery software like TestDisk - CGSecurity and PhotoRec - CGSecurity the results may be zero.

In any way, before you further damage the partitions, make a image of the disk.

[rcgreen]

$ fdisk -l /dev/sdb
Cannot open /dev/sdb

Try just sudo fdisk -l without specifying the device.

[kaiseroskilo]

its the sdb the other one is the virtual box image thingy

sudo fdisk -l
[sudo] password for *: 

Disk /dev/sda: 12.9 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 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: 0x000edff7

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1495    12002304   83  Linux
/dev/sda2            1495        1567      577537    5  Extended
/dev/sda5            1495        1567      577536   82  Linux swap / Solaris

Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 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: 0x000328f0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1       19127   153629664+  83  Linux
/dev/sdb2           29650       30401     6040440    5  Extended
/dev/sdb5           29650       30401     6040408+  82  Linux swap / Solaris

(i screwed up didnt i?)

[rcgreen]

The file system size from the superblock is unreasonable.
The info from fdisk looks about right. You should check
how to run fsck with an alternate superblock.

fsck "alternate superblock" - Google Search

[kaiseroskilo]

i found a way to fix this.i read about "testdisk" which is open source and fixes partition tables.it took a while but i managed to get my data out of it.thanks for the help anyway