Weird partition table

Question

I was given a hard disk to repair/extract data from. This hard drive was once the hard drive of a computer that had windows and linux installed (using grub to change between two). Booting from the hard drive is not possible anymore. When connected to linux, 4 partitions are found (/dev/sdb[1256]), but only /dev/sdb1 can be read. /dev/sdb1 is the grub-partition, while /dev/sdb5 was identified as swap-partition by blkid (it might have been another program, i'll check that). Mounting the partitions 2 and 6 gives errors, var/log/syslog says something about a bad superblock.
Still, the most irritating result gives fdisk -l, which prints the partition table AFAIK.

Device    Start    End        Type
/dev/sdb1     2048  19531775  83 linux
/dev/sdb2 19533822 625141759   5 extended
/dev/sdb5 19533824  36304895  82 linux swap 
/dev/sdb6 36306944 625141759  83 linux

(1 sector equals 512 byte, some of the output was removed by me. I will add it if needed)

If I understand correctly, something is wrong with the partition table. Somehow partition 2 is at the same location as partitions 5 and 6, which might explain the mounting-errors. (I will ask which OS really was used on this hard drive).

Now, there are important files on this hard drive. How do I get these files from the hard drive or (better) alter the hard drive so linux can mount all partitions. My first thought was to make a backup with dd and then let a fsck run on /dev/sdb (You might see I am no expert at this), although I have my doubts.

UPDATE: As grawity pointed out, the partition table is intact and there are 3 partitions, from which one is a swap-partition. /dev/sdb1 can be mounted and is the grub-partition (judging from the files on the partition). /dev/sdb5 is most likely the swap-patition (since it's labeled as such and its size is in the right magnitude). I will try doing a fsck on /dev/sdb6 and try some recovery tools.
Also, the person who gave me the hard drive is now thinking if he gave me the right one. I will look for the files anyway.

Answer 1

If I undmerstand correctly, something is wrong with the partition table. Somehow partition 2 is at the same location as partitions 5 and 6, which might explain the mounting-errors.

This is normal. The MS-DOS-era MBR partition table can only hold 4 partitions, so it's customary to make the last one an "extended" partition, in which additional "logical" partitions are nested.

(Linux always numbers the logical partitions starting with 5+, and while the names in fdisk -l are actually made up, they also follow the same numbering.)

(While on the topic, don't forget that there are other partition tables such as GPT. fdisk 2.23 understands GPT, but older versions do not.)

Also note that the partition types don't always correspond to the actual data inside. It's not impossible that the owner might have decided to use sdb5 for data and sdb6 for swap, but forgotten to update the MBR partition types (which Linux ignores, anyway).

How do I get these files from the hard drive or (better) alter the hard drive so linux can mount all partitions

Try photorec.

My first thought was to make a backup with dd and then let a fsck run on /dev/sdb

Making a backup is a good idea. Trying to run fsck on something that's not a FS won't do anything useful. /dev/sdb1 or /dev/sdb6 would be better targets for that, since they contain filesystems.

Answer 2

The partition table you displayed belongs to a pure Linux system: there is no trace of Windows on it. So, given that you stated:

This hard drive was once the hard drive of a computer that had windows and linux installed ...

perhaps the guy who gave it to you was right when he said...

Also, the person who gave me the hard drive is now thinking if he gave me the right one.

User files are in /home/, which is likely to be partition /dev/sdb6. There is no need to use something as complex as photorec, and, possibly, you can restore the partition to its full, working state, in an alternative way. Can you please state exactly what error message you obtain when you try to mount partition /dev/sdb6? If it is only a matter of a bad superblock, this can easily be cured:

1. Check the file system with (you may have to redo this with ext2 or ext3, it is not clear from the above which filesystem was being used),

    sudo fsck.ext4 -v /dev/sdb6
   

2. If the superblock is indeed corrupt, then you will get an output like

   fsck /dev/sdb6
   fsck 1.41.4 (27-Jan-2009)
   e2fsck 1.41.4 (27-Jan-2009)
   fsck.ext4: Group descriptors look bad... trying backup blocks...
   fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb6
   
   The superblock could not be read or does not describe a correct ext4
   filesystem.  If the device is valid and it really contains an ext4
   filesystem (and not swap or ufs or something else), then the superblock
   is corrupt, and you might try running e2fsck with an alternate superblock:
   e2fsck -b 8193 /device
   

3. Let us find where the backup superblocks are,

   sudo mke2fs -n /dev/sdb6
   

   At the bootom of a long output, you will find something like:

   Superblock backups stored on blocks:
   32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
   

4. And now, lastly, fix it by replacing the defective superblock with one (anyone) of the backup ones:

   sudo e2fsck -b block_number /dev/sb6
   

Reboot, and you should be good to go. If not, try a different superblock. Like I said, if this the reason why you could not mount partition /dev/sdb6, all of this is a heck of a lot easier than using photorec, plus you will restore the disk and its partitions to their pristine state.