Is Grub offering any clues on what to boot?
When you installed, did you swap around any HDs? If they are listed by the BIOS in a different order, Grub will get confused.
There is a "find" command which you can use to get started:
find /boot/grub/menu.lst
or
find /boot/grub/device.map
If you're lucky you'll get a response like:
(hd1,0) /boot/grub/device.map
That would indicate that a file named device.map was found on the first partition of HD#2; when Grub was originally installed it might have thought that the HD was #1 rather than #2 so it might be looking for files on (hd0,0) and then giving up.
This is fairly easy to fix up if you boot from a LiveCD - since it's Ubuntu, just boot from your installer disc, but tell it to run the live system rather than asking it to install.
Then things go like this:
1. Enter the "interactive" sudo mode: sudo -i (this essentially makes you root user until you 'exit')
2. Identify your HD with the installation - Ubuntu usually automounts it so:
mount (displays all current mounts)
3. Check out the boot/grub directory of your installation to see what's there - so it would be something like:
ls -l /mnt/hda1/boot/grub/*
You should see the various Grub bootloader files: stage1 stage2 whatever_stage1_5, plus the config files "device.map" and "menu.lst"
Check "menu.lst" with a text editor and confirm that it has valid entries for your kernel and initrd image (actually it's initramfs, but lately everyone has been referring to initramfs as initrd and denying the continued existence of the original initrd)
4. Keep in mind that the Live CD may call the HD something like "sdb" or "hda" - whatever. Our aim here would be to get further along in the boot process; possibly failing when it comes to reading 'fstab', but hopefully 'busybox' will pop up and allow you to fix the remaining problems.
Anyway, you must ensure that the 'device.map' file on your installed system has the correct device mapping - whatever that may be - when the system starts. For example, let's say that under the LiveCD your HD is called "hda" but when you boot the system without a CD it's essentially named "hdb". The 'device.map' file on the INSTALLED system should then have an entry like this:
(hd0) /dev/hdb (or 'sdb' if the device is sd...)
So check device.map
5. Now you have to unmount that partition so that Grub can do its job without bringing on the end of the world.
6. Now you have to create another map file for the CURRENT setup - let's call it 'disk.map' so you don't get it confused with 'device.map'. It really only needs an entry for the HD you want to install to; it's only needed to initially trick grub into installing in the right place:
echo "(hd0) /dev/hda" > disk.map
7. Now to (re) install grub [assuming you originally installed it to MBR]:
grub --batch --device-map=disk.map <<EOF
root (hd0)
setup (hd0) (hd0,0)
quit
EOF
The 'setup' part is telling GRUB to install stage1 to MBR (hd0), and to look for other files on the first partition on hd0 (that is, hd0 as defined in disk.map, which in this example is currently hda). Since grub on Linux defaults to searching in /boot/grub, it will look for a copy of ALL bootloader stages in (hd0) /boot/grub/. You should get a message that grub installed correctly.
What to expect next? Well, now when you restart, GRUB will read "device.map" and see that "hd0" (which is where GRUB knows it was installed) is really now known as 0x81 (long story - but normally 0x80 becomes 'hda' and 0x81 becomes 'hdb' and the original grub install may have confused them) and hopefully it will find the menu.lst, your kernel and the initrd files and begin to boot. Now the system *might* get stuck on reading /etc/fstab because entries have names like '/dev/hda' when they need to be changed to '/dev/hdb' (or sdb - however the installed kernel calls it).
Have fun.
