Linux installation won't boot due to GRUB "no such device" error

I think I've exhausted all I know to do, so I'm sending up the flares. I'll try to cover it all (albeit, in pieces), so please be patient.

I decided to install Linux Mint 11 where I previously had Ubuntu 10.10. Before this install, I had a partition with Windows XP, which--at some time in the distant past--I used to dual boot into. I removed the partition in this install.

After installation, the system fails to boot. After the check for a CD/DVD, it prints:

error: no such device: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
GRUB rescue>

There were no problems booting Ubuntu. I seem to recall a similar issue last time I did an install (instead of an upgrade) to Ubuntu. It's been a while, but I thought I fixed it using FIXMBR and/or FIXBOOT from the XP CD. Those did not work this time.

The GRUB rescue> prompt seems to be broken. Even help doesn't work. I am able to ls, which yields:

GRUB rescue> ls
(hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos5) (hd2,msdos3) (hd2,msdos2) (hd2,msdos1)

Further, I don't know what this device is. I can't find a matching UUID under /dev/disk/by-uuid. For that matter, there are no UUIDs for my booting hard drive (sda, below). My setup is a Frankenbox. I know not to rely on device enumeration in such a mix, but they're given below for easy discussion.

• Ch 0 Master: 250GB PATA (sda)
  • sda1
• Ch 0 Slave: none
• Ch 1 Master: 80GB SATA (sdb)
  • sdb1: /
  • sdb2: /home
  • sdb3: swap
• Ch 1 Slave: DVD SATA
• SATA expansion card: 250GB SATA (sdc)
  • sdc1

I thought I'd struck gold when I discovered some lingering (and confounding) RAID metadata on sda. The drive hadn't shown up in the Linux install before, but did after using dmraid -r -E /dev/sda. However, the boot failure persisted.

Until just now, I could use the Mint install CD to "Boot from Local Drive", which would indeed take me to my installation on sdb1. After using the CD to boot to the drive, and running the below, I've worsened the problem to giving a GRUB> prompt instead of booting to the drive.

# GRUB-install --no-floppy /dev/sdb1
# update-GRUB
GRUB> find /boot/GRUB/stage1
GRUB> root (hd1,0) # result of above
GRUB> setup (hd0)

There's definitely a mismatch, because sdb, which has 3 partitions, seems to be (hd2) at the GRUB rescue> prompt, but (hd1) when actually booted. However, if I've used UUIDs (and I think I have), this shouldn't be a problem. Using the live CD, I see sdb1:/boot/GRUB/menu.list to contain

# kopt=root=UUID=[UUID of sdb1]
...
# groot=[UUID of sdb1]

The root problem, as I understand it, is that GRUB is, for some reason I don't understand, trying to boot a device that doesn't exist. I don't know how to determine what it's looking for by the UUID given. I don't see any UUIDs for anything on sda.

And now, I can't even boot to the drive using the CD.

Update:

I thought putting the /boot partition on the same drive as the MBR might help, so I added sda2, set the boot flag, and reinstalled (which is probably overkill).

I again get the grub rescue> prompt, but now, when I ls, I get

grub rescue> ls
(hd0) (hd0,msdos1) (hd1) (hd1,msdos2) (hd1,msdos1) (hd2) (hd2,msdos3) (hd2,msdos2) (hd2,msdos1)

So, sda is no more (hd0) at this prompt than sdb is (hd1). I don't know why it's so misaligned, nor why it matters. I may try again, putting /boot on sdc/(hd0).

Solution 1:

I got the same error due to an ill marked UUID in the bootloader and This guy had the answer for me along with these available commands in grub recover mode.

Essentially first, you need to identify the drive and partition that has the grub menu files typically located in /boot/grub

ls [to identify your drive and partition options]
ls (hdx,p)/ [to identify which partition has the /boot folder]

Then, you can load the boot menu manually from the drive and partition you found above.

set prefix="(hdx,p)/boot/grub"
set root="(hdx,p)"
insmod normal
normal

In my case, I modified the UUID of our boot drive manually and purposefully, updated the grub menu and fstab, but forgot to load a new bootloader to update the UUID and/or drive in the bootloader. Then, the drives were not in the order expected in grub and the above took care of it all; it got the menu back so I could get back in and update the bootloader with the new UUID information

Solution 2:

The solution was just to put the GRUB loader (MBR?) on the correct drive. In this case, what loaded in Linux as /dev/sdc and (hd2) loaded in GRUB as (hd0).