Fixed by following this from http://ubuntuforums.org/archive/index.php/t-620860.html
The "why" is fairly easy, the fix is a bit lengthy. The short answer is that the initrd image was not updated or was updated with an incorrect disk setting. This can turn into a very long and detailed set of steps. So I will outline what is needed, and then have you boot from the install cdrom to fix it. If some of the steps in the outline indicate that a file setting is wrong, I will leave it up to you on how to edit the file to fix it :-). So first an explanation on the steps, then figure out how to get you access to disk to fix it.
The initrd image is located in '/boot' and looks like the line below, the numbers after the key words "initrd.img-xxxxxxxx" will be dependent on what kernel you have installed. There can be more than one of these initrd.img files.
Example - initrd.img file
/boot/initrd.img-2.6.22-14-generic
Quick Summary
In your case, since grub is loading, and it's loading the kernel, it means that your Grub install is ok. You did not mention it, but I assume that since Grub is the boot loader, that you also use it to boot to Windows. From the error message that you provided, it appears that Windows is on the first partition, however Ubuntu is on either the second or third partition. Since you have booted into Windows using Grub, it's also confirmation that Grub is working properly and the issue is likely the initrd.img.
A Quick Grub Review
Grub creates it's own internal mapping of disk drives. The format is like this:
hd( 0, 0 )
The first parameter is the disk drive.
The second parameter is the disk partition.
All numbering starts at zero [0]. So the first disk drive is [0], the second one is [1] and so forth. The same applies to partitions, the first partition is [0], the second partition is [1].
In your error message, the last line indicates that the kernel is looking on disk 1, partition 1 for the Ubuntu installation. "unknown-block(0,0)"
[6.543860] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
How To Fix It
There are two items that need to be checked: 1) the disk that grub is going to boot from, and 2) the partition that it is to use to load Ubuntu. In your case the first item is correct because windows boots, it's the second one that is wrong, and it's can be wrong in one or two places.
Verify that the Grub device mapping is correct. This requires access to the partition where '/boot' exists. The file is called /boot/grub/device.map, it's a plain text file that will have one or more lines telling grub what disks is suppose to know about.
/boot/grub/device.map
For SATA or SCSI it will look like this:
(hd0) /dev/sda
For IDE
(hd0) /dev/hda
There are two locations for the partition that is to be used, one is in the Grub menu, and the other one is in the initrd.img file.
Here is an example of the Grub Menu file: /boot/grub/menu.lst
You are interested in the lines that look like this:
title Ubuntu 7.10, kernel 2.6.22-14-generic
root (hd0,1)
kernel /vmlinuz-2.6.22-14-generic root=/dev/md1 ro
initrd /initrd.img-2.6.22-14-generic
title Ubuntu 7.10, kernel 2.6.22-14-generic (recovery mode)
root (hd0,1)
kernel /vmlinuz-2.6.22-14-generic root=/dev/md1 ro single
initrd /initrd.img-2.6.22-14-generic
Your Windows entry will be located at the bottom of the file and will look like this:
# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/hda1
title Windows NT/2000/XP
root (hd0,0)
savedefault
makeactive
chainloader +1
The above example is from a system that is using RAID1, so the 'root' is a bit different from yours. Make sure your 'root' points to the correct partition for your Ubuntu installation.
If your Ubuntu installation is on partition 2, then the root will be '(hd0,1)', if your Ubuntu installation is on partition 3, then the root will be '(hd0,2). It's repeated here:
If root is on the second partition, then 'root hd(0,1)'
If root is on the third partition, then 'root hd(0,2)'
The second location for the partition is in the initrd.img file. It's just safer to rebuild it then to try to mess with it.
update-initramfs -c -k 2.6.22-14-generic
update-initramfs: Generating /boot/initrd.img-2.6.22-14-generic
It's likely that you are doing this from a cdrom boot, so make sure you specify the kernel name. Do not try something like update-initramfs -c -k `uname -r`, it will just fail and mess up your image.
---
Okay, so now how to access the disk? Fastest way is to boot with the install cdrom and let it come up in the Ubuntu GUI.
Note: Most of the following section was from here, because was I too lazy to type it all in in: https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows
---
Select Applications>Accessories>Terminal.
Become root
sudo -i
Now that you have root access, you need to mount the partition(s) containing your bootloader files.
You will need access to both your /sbin/ and /boot/ directories. If you have a /boot/ listing in your fstab, you will need to mount two partitions. In your case this is unlikely because you said you had three partitions, so everything is located on either /dev/hda2 or /dev/hda3. I am assuming that /dev/hda2 is your Ubuntu location, if it is not, just replace the '2' with it's correct location.
Create a mount point
mkdir /mnt/work
If you need to mount /boot/, too, run the following command. Again I think all of your data is located on a one partition based on the information you provided, so this step is not needed ... however just to keep Mr Murphy away...
mkdir /mnt/work/boot
Now it's time to actually load your filesystem data. Review your fstab and identify the location(s) of / and /boot/; these will likely look something like /dev/hda2 and /dev/hda3, though the letter 'a' and the numbers 2 and 3 may differ.
Enter the following commands to load your filesystem and some information GRUB may need.
mount /dev/hda2 /mnt/work
mount -o bind /dev /mnt/work/dev
mount -o bind /proc /mnt/work/proc
cp /proc/mounts /mnt/work/etc/mtab
Now, you have to enter your working environment. The following command will take care of that.
chroot /mnt/work/ /bin/bash
If all of the assumptions I made are correct about your system, and the grub menu.lst file has the correct root (hd0,1) entry, all you need to do is run the update command.
update-initramfs -c -k 2.6.22-14-generic
Now exit the chroot environment and reboot
exit << exit chroot
reboot
Hopefully this will fix your problem, if not, then post your device.map and menu.lst files and we can figure out what is going on.
The initrd image is located in '/boot' and looks like the line below, the numbers after the key words "initrd.img-xxxxxxxx" will be dependent on what kernel you have installed. There can be more than one of these initrd.img files.
Example - initrd.img file
/boot/initrd.img-2.6.22-14-generic
Quick Summary
In your case, since grub is loading, and it's loading the kernel, it means that your Grub install is ok. You did not mention it, but I assume that since Grub is the boot loader, that you also use it to boot to Windows. From the error message that you provided, it appears that Windows is on the first partition, however Ubuntu is on either the second or third partition. Since you have booted into Windows using Grub, it's also confirmation that Grub is working properly and the issue is likely the initrd.img.
A Quick Grub Review
Grub creates it's own internal mapping of disk drives. The format is like this:
hd( 0, 0 )
The first parameter is the disk drive.
The second parameter is the disk partition.
All numbering starts at zero [0]. So the first disk drive is [0], the second one is [1] and so forth. The same applies to partitions, the first partition is [0], the second partition is [1].
In your error message, the last line indicates that the kernel is looking on disk 1, partition 1 for the Ubuntu installation. "unknown-block(0,0)"
[6.543860] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
How To Fix It
There are two items that need to be checked: 1) the disk that grub is going to boot from, and 2) the partition that it is to use to load Ubuntu. In your case the first item is correct because windows boots, it's the second one that is wrong, and it's can be wrong in one or two places.
Verify that the Grub device mapping is correct. This requires access to the partition where '/boot' exists. The file is called /boot/grub/device.map, it's a plain text file that will have one or more lines telling grub what disks is suppose to know about.
/boot/grub/device.map
For SATA or SCSI it will look like this:
(hd0) /dev/sda
For IDE
(hd0) /dev/hda
There are two locations for the partition that is to be used, one is in the Grub menu, and the other one is in the initrd.img file.
Here is an example of the Grub Menu file: /boot/grub/menu.lst
You are interested in the lines that look like this:
title Ubuntu 7.10, kernel 2.6.22-14-generic
root (hd0,1)
kernel /vmlinuz-2.6.22-14-generic root=/dev/md1 ro
initrd /initrd.img-2.6.22-14-generic
title Ubuntu 7.10, kernel 2.6.22-14-generic (recovery mode)
root (hd0,1)
kernel /vmlinuz-2.6.22-14-generic root=/dev/md1 ro single
initrd /initrd.img-2.6.22-14-generic
Your Windows entry will be located at the bottom of the file and will look like this:
# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/hda1
title Windows NT/2000/XP
root (hd0,0)
savedefault
makeactive
chainloader +1
The above example is from a system that is using RAID1, so the 'root' is a bit different from yours. Make sure your 'root' points to the correct partition for your Ubuntu installation.
If your Ubuntu installation is on partition 2, then the root will be '(hd0,1)', if your Ubuntu installation is on partition 3, then the root will be '(hd0,2). It's repeated here:
If root is on the second partition, then 'root hd(0,1)'
If root is on the third partition, then 'root hd(0,2)'
The second location for the partition is in the initrd.img file. It's just safer to rebuild it then to try to mess with it.
update-initramfs -c -k 2.6.22-14-generic
update-initramfs: Generating /boot/initrd.img-2.6.22-14-generic
It's likely that you are doing this from a cdrom boot, so make sure you specify the kernel name. Do not try something like update-initramfs -c -k `uname -r`, it will just fail and mess up your image.
---
Okay, so now how to access the disk? Fastest way is to boot with the install cdrom and let it come up in the Ubuntu GUI.
Note: Most of the following section was from here, because was I too lazy to type it all in in: https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows
---
Select Applications>Accessories>Terminal.
Become root
sudo -i
Now that you have root access, you need to mount the partition(s) containing your bootloader files.
You will need access to both your /sbin/ and /boot/ directories. If you have a /boot/ listing in your fstab, you will need to mount two partitions. In your case this is unlikely because you said you had three partitions, so everything is located on either /dev/hda2 or /dev/hda3. I am assuming that /dev/hda2 is your Ubuntu location, if it is not, just replace the '2' with it's correct location.
Create a mount point
mkdir /mnt/work
If you need to mount /boot/, too, run the following command. Again I think all of your data is located on a one partition based on the information you provided, so this step is not needed ... however just to keep Mr Murphy away...
mkdir /mnt/work/boot
Now it's time to actually load your filesystem data. Review your fstab and identify the location(s) of / and /boot/; these will likely look something like /dev/hda2 and /dev/hda3, though the letter 'a' and the numbers 2 and 3 may differ.
Enter the following commands to load your filesystem and some information GRUB may need.
mount /dev/hda2 /mnt/work
mount -o bind /dev /mnt/work/dev
mount -o bind /proc /mnt/work/proc
cp /proc/mounts /mnt/work/etc/mtab
Now, you have to enter your working environment. The following command will take care of that.
chroot /mnt/work/ /bin/bash
If all of the assumptions I made are correct about your system, and the grub menu.lst file has the correct root (hd0,1) entry, all you need to do is run the update command.
update-initramfs -c -k 2.6.22-14-generic
Now exit the chroot environment and reboot
exit << exit chroot
reboot
Hopefully this will fix your problem, if not, then post your device.map and menu.lst files and we can figure out what is going on.
