recovering Ubuntu after changing a phyical machine (or, struggling with--and losing to--the Linux command line)

Context:

My Lenovo w510 crashed some time ago. Probably due to all the hype (and also probably a bit influenced by my girlfriend's style preferences), I decided to buy a mac-mini server as a temporary replacement (the original platform hosting this article). The short version of that rather epic struggle is that I've given up on macs and now am sitting in front of a Lenovo w520 alongside the hard drive that I pulled from my old laptop, on which I had a dual-boot Windows 7 OS and Ubuntu 11.10.

I want to try to restore this system. Of course, while Ubuntu the file system is relatively easy to transfer across systems, my hardware has all changed with the new machine, so I am expecting a headache. Here's the story of my (mis)adventure....

To wit: I don't know much about Linux. Ubuntu is claimed be a fairly "user friendly" distribution, so a year or so ago I committed to giving it a whirl (primarily as a headless server).

Process - trial & error:

To install Ubuntu, I first need to create an installation disk. I opted for the USB method (I have no CD drive). The whole process of creating the USB 'live CD' takes only a few minutes. So far so good.

When I first tried to boot the hard disk, I get a GRUB error. Makes sense: the UUID(s) in /etc/fstab and /boot/grub/grub.cfg have probably changed. I used the Live CD to try to fix my GRUB-2 file using Boot-Repair. I try it out as directed: clicking "recommended repair" and 'apply'. Reboot. No dice.

Since I hadn't played around with the hard disk in over 6 months by this point time (and since I am about to start messing around a bit), it's time to remind myself how I structured the disk. To do this, I run # fdisk -l in the terminal. The output shows me that I have two partitions where the old Ubuntu was previously installed:

/dev/sda5    Linux
/dev/sda6    Linux swap / Solaris

[A brief aside: The Windows on the machine using /dev/sda2 and /dev/sda3. I think /dev/sda1 is reserved for my boot partition; no idea what is going on with /dev/sda4/ at this point.]

I guess (and remember, I have no clue what I am doing) that maybe if I can install a new copy of Ubuntu to the 20 gigs allocated as a swap space I can force a re-write of GRUB in the process and then be able to access the partitions directly.
So I go about trying my idea.

Moving through the LiveCD "install Ubuntu" GUI, my hunch is encouraged by the installer also seeing my existing partitions (I take over the /sda6 swap space for my new install). Installation goes well. The computer re-boots and voilà! GRUB gives me the option to boot into Windows! Unfortunately, /sda5 is still hiding from me.

To check out my disk's structure post-install, I re-run # fdisk -l:

Disk /dev/sdb: 500.1 GB, 500107860992 bytes  
 255 heads, 63 sectors/track, 60801 cylinders, total 976773166 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0915faaf

Device Boot      Start         End      Blocks   Id  System  
 /dev/sdb1            2048     2459647     1228800    7  HPFS/NTFS/exFAT
 /dev/sdb2   *     2459648   536823880   267182116+   7  HPFS/NTFS/exFAT
 /dev/sdb3       536825854   975747071   219460609    5  Extended
 /dev/sdb4       975747072   976771071      512000    7  HPFS/NTFS/exFAT<br>
 /dev/sdb5       536825856   927449087   195311616   83  Linux
 /dev/sdb6       927451136   966510591    19529728   83  Linux
 /dev/sdb7       966512640   975747071     4617216   82  Linux swap / Solaris

So the partitions are all still there, things are looking good. I should be able to get GRUB to recognize them so long as the drives are mounted when I re-run the update-grub command.

Oddly, however, # sudo mount /dev/sdb5 /mnt returns this:

can't find /dev/sda5 in /etc/fstab or /etc/mtab

Some Googling suggests that the solution for this error is to tell Ubuntu the format of /dev/sda5. In retrospect, this is probably a mistake (I should have been thinking for myself rather than blindly following tutorials). Anyway, I try # sudo mkfs.ext4 /dev/sda5 followed by # sudo mount /dev/sdb5 /mnt. Now I am confronted with the following output:

mount: you must specify the filesystem type

This is a problem. I had thought that # sudo mkfs.ext4 /dev/sda5 was the command to identify the partition format. Apparently not. I hope at this point that I can 'recover' my error simply by specifying the drive type using # sudo mount -t ext4 /dev/sdb5 /mnt. Here's the feedback:

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

Ouch! Apparently my careless mistake with mkfs has destroyed the integrity of my /dev/sda5 partition.

Outcomes and Lessons Learned?

So the outcome of all of this is me having corrupted my disk. I can't re-gain access to my data and ultimately wipe the disk and re-start afresh. C'est la vie digital!

The lesson, however, is this: If you're doing anything that might jeapordize your data, be sure you have a backup. Also, investigate any commands you don't understand. A couple minutes of research can save you a world of hurt.

random notes:

While it is claimed to be simple, I have no idea how to use the tool SuperGrub.