Not sure if this fits in the software category, but it doesn't fit under hardware either.

I wanted to experiment with some alternative OS's, I tried The Hurd and was unimpressed with its memory limitations. I found plan9 and was very interested. I downloaded an iso and wanted to install it to a new partition.

My partition table looked like this:
sda1 - NTFS (Windows XP) - 110 gb
sda2 - ext3 (Ubuntu Intrepid) (Unbootable) - 20 gb
sda3 - ? (GNU/Hurd) - 5 gb
sda4 - extended
sda5 - ext3 (Ubuntu Intrepid) (My main OS) - 60 gb
sda6 - swap - 1.5 gb
sda7 - ext3 (Ubuntu Intrepid) (Unbootable) - 33.5 gb
Unpartitioned - 2 mb

(Grub2 is on sda5)
I deleted my GNU/Hurd Partition and installed Plan9 from the CD into the free space, the installer created a FAT16 partition in its place. The install went perfectly. I installed the Plan9 bootloader, but did not install it to my MBR since I planned to chainload from grub2. I rebooted my pc so I could set up grub from Ubuntu, but instead of booting, grub gave me an error about reading from an unknown filesystem (even before the menu). So I messed around with the grub shell for a little while and found that I couldn't read either sda5 or sda7. So I booted from the Ubuntu LiveCD and looked at the partitions in gparted. Both sda5 and sda7 were listed as unknown. I tried to mount them and couldn't, I got an error about mount being unable to read the superblock. So I tried to use the alternate superblocks, but none of them were readable either, by either mount or fsck. I did some research and found I could recreate the superblocks. I did so on sda7 because I wanted to make sure I wouldn't do any more damage before trying it on my prized sda5. I then tried to run fsck to check for/fix any errors. There are very many (multiply-claimed inodes). I did some more research and found that this may be because my entire partition is littered with garbage and fsck is mistaking the garbage for inodes. In which case fsck would be completely destroying sda7 now. No big deal, I don't really care about sda7.
What I want is my sda5 back. Can I recover the files, or is it already too far gone? What should I do?

Edit: I was able to mount sda7 and found that fsck had taken the entire contents of the partition and placed it in /lost+found (all with names like #xxxx). The files seem unreadable.

-How exactly did you try mounting these partitions?
-Did you specify the file system type in your mount command?
-What does the output of sudo fdisk -l command say?
-Does it recognize the partition(s) and their file systems?
-Why do you keep two un-bootable Intrepid partitions?
-Why are they un-bootable?

Questions, questions, questions...
It appears I have more questions than you.
-What do you mean by "messed around"?
-Did you fornicate with it some how?
-Typed sweet nothings at the grub prompt?
-WHAT?
Because it appears you need to reinstall grub but it is unclear if you tried to. And with three Ubuntu installations, grub may want to elope with a more sane setup.
-What are you gonna do then?
-Huh?
It sounds like the partition information in the MBR has been changed and needs to be ammended. You may be able to reinstall grub and use /dev/sda2 as the root (using it's grub configuration files) even if it's un-bootable....but that depends on "why is it not bootable?".

I have one more question...
Is the swap partition recognized as swap in the sudo fdisk -l command output? If not, this would suggest there is a problem with the extended partition.
Personally, I wouldn't be scared to attempt reinstalling grub using /dev/sda5 as the root first, and if that does not work, I would try again using the un-bootable /dev/sda2 as root via command line from a Ubuntu live session by running four commands for each try as shown below:
OH!
And as you "mess around", post the outputs here, none of us actually know who you are therefore none of us can rat on you for messing around. I'm going to bed now, may even "mess around", but won't post the output since this is your thread.

I tried every way I could think of to mount the partitions including specifying the fs type and specifying alternate superblocks.

Well I have bad news. I rewrote the superblocks. So I have no way of knowing whether fdisk would have recognized the partitions before that. I assume that it wouldn't since gparted couldn't see my ext3 partitions. I assume they both do similar things. The swap partition was always accessible.
Here's the output:

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

Device Boot Start End Blocks Id System
/dev/sda1 1 14023 112639716 7 HPFS/NTFS
/dev/sda2 14024 17784 30210232+ 83 Linux
/dev/sda3 * 17785 18549 6144862+ 39 Plan 9
/dev/sda4 18550 30402 95203741+ f W95 Ext'd (LBA)
/dev/sda5 18550 27608 72766386 83 Linux
/dev/sda6 27609 27851 1951866 82 Linux swap / Solaris
/dev/sda7 27852 30401 20482843+ 83 Linux

I was keeping the unbootable partitions because they still had some files that I wanted and hadn't yet moved them over to my main install.
sda7 is unbootable because of extensive unstable/experimental upgrades.
sda3 is unbootable because of a problem with pam and selinux preventing me from logging in.

By messed around with the grub shell, I meant I tried to boot from the grub shell, but I wasn't successful because my partitions are not accessable.

I can't use grub from sda2 because, while I could boot in single user mode, grub isn't installed and I can't install it because apt complains about an extensive list of broken packages caused by me trying to make the system bootable again.

If the output you posted is the output of fdisk -l command from a live Ubuntu session, there is nothing wrong with partition information in the MBR. And because Swap appears to be alright, suggests there is nothing wrong with the extended partition and the information it contains regarding it's partitions including /dev/sda5 which is before swap.

I read the installation notes for Plan 9 (speed read), in the "Configure one or more ways to boot Plan 9" section it mentions that if you were to choose using Windows boot menu to boot plan 9, the installer would do this: Your c:\boot.ini file will be saved as boot.p9, and then edited.. I've never heard of an OS installer that would edit the Windows boot.ini, usually you have to do it manually, Windows don't take kindly to changes made behind it's back to it's boot files, but "whatever". It also had this: plan9. Set the Plan 9 partition to be the active one (i.e. the partition booted by default). This is only useful if you have installed Plan 9 on your first hard disk (for IDE systems, sdC0). You can always set another partition active later by using disk/fdisk. I'm guessing this is the option you chose because according to the output you posted, Plan 9 is set as the active partition.

By rights, it should not have altered any other partition, but it probably altered the boot loader information in the MBR, but did not completely replace grub, and now grub is trying to look at the Plan 9 boot files in a Fat partition which is why it produced that error. You should remove the boot flag from the Plan 9 partition (may not be necessary), and try reinstalling grub as I previously mentioned, if the first example using /dev/sda5 (hd0,4) does not work, try the second example using /dev/sda2 (hd0,1). Because even if you cannot log into /dev/sda2, you should still be able to use it's boot configuration files to set up grub properly and get a menu. And it's very possible you'll be able to boot /dev/sda5 if it shows up in the menu after successfully reinstalling grub in the MBR.