I just encountered a Grub Error 13 and a Grub Error 17 all for seemingly no reason. I fixed the problem, but thought I could save others undue headache.
The Setup
I have Ubuntu Linux installed on one hard drive which fdisk calls /dev/hda and Windows XP installed on a second hard drive called /dev/hdb. To Grub, the mapping is as follows:
/dev/hda1=(hd0, 0)/dev/hdb1=(hd1, 0)
This works because my BIOS agrees on this mapping.
The Mistake
After shutting down my computer, I unplugged only my Linux drive, which both my BIOS and Grub agreed was the main/first/primary drive, hoping I would somehow still be able to boot into Windows even though Grub is on my Linux drive. Alas, that didn’t work and I got some kind of “Grub configuration error” screen without seeing my Grub boot menu. I figured “oh well, I’ll just plug my Linux drive back in and boot into Windows”.
I shut down my computer, plugged my Linux drive back in, and powered on the computer. The Grub boot menu loaded again, as expected. When I tried to boot into Windows, however, it gave me a Grub Error 13. This was weird, since I hadn’t done anything to the Grub configuration. Exiting back to the Grub boot menu, I tried to load Linux. No luck, but this time it gave me a Grub Error 17. I tried following my own tutorial about error 17, but fdisk reported that /dev/hda1 was a Linux partition, as it should. What was going on?
The Explanation
Reading on the Ubuntu Forums, mbwardle wrote the following:
The error usually happens because Linux and your BIOS detect your hard disks in different orders. GRUB tries to translate between the two using the device.map file in /boot/grub/device.map, which is automatically generated. Chances are, it guessed wrong.
In my case, I have three SATA hard disks.
My BIOS sees them as:
HDD1 – 80 GB – Windows
HDD2 – 80 GB – Linux
HDD3 – 250 GB – MediaLinux sees them as:
/dev/sda – 80 GB – Windows
/dev/sdb – 250 GB – Media
/dev/sdc – 80 GB – Linux
— mbwardle
Aha, your BIOS and Grub are not necessarily talking about the same thing! This was what happened in my case. When I unplugged the Linux drive (which Grub and my BIOS thought of as the first drive) and left only the Windows drive (which Grub and my BIOS thought of as the second drive), I was left with only the second drive, but my BIOS started thinking of that as the first drive since that was the only drive plugged in. Then when I plugged the Linux drive back in, it was thought of as the second drive. Just because my BIOS changed the order, though, doesn’t mean Grub did: it still thought of Linux as #1 and Windows as #2.
The Solution
I shut down my computer, unplugged the Windows drive (the one Grub thinks of as #2), and left the Linux drive (the one Grub thinks of as #1) plugged in. I started my computer, thus making my BIOS think of the Linux drive as #1 again. I was able to boot Linux just fine from the Grub boot screen, though of course Windows was inaccessible because the drive was unplugged.
I shut down my computer again, plugged the Windows drive back in, and kept the Linux drive plugged in too. I started my computer, and then the BIOS saw the Windows drive and began thinking of it as #2, just like Grub does. Now I can boot both Windows and Linux because, once again, Grub and my BIOS agree about what order the drives are in.
This is why you always use UUIDs for your drive block files. The BIOS and udev assignments for the drives (First and second versus /dev/sda and /dev/sdb) may change at any time, though Linux will try to keep it consistent. But… there’s /dev/disk-by-uuid. Which does things by filesystem ID numbers. Thus: No matter how much the BIOS switches it up, GRUB and Linux will never lose track of what it should be using.
In short: When working with menu.lst and your fstab: ALWAYS go by /dev/by/UUID where you can.
GRUB, however, doesn’t go by UUIDs. When it does it like that its usually due to a combination of a SATA drive and an IDE drive on the system. GRUB always confuses them. At any rate, you can try the following:
1. You can simply load up your system on a LiveCD… go and swap drive descriptors ((hdx,y)) in your menu.lst. OR
2. You boot a LiveCD… and reinstall GRUB. It is actually pretty easy.
But if its a problem of finding the root of the drive as an argument to pass to the kernel (Failures in this regard end in a kernel panic when Linux cannot actually locate its initramfs on the provided device block file.), UUIDs are the best because Linux simply CANNOT mistake them for another device.
So far, Lilo hasn’t tried outsmarting my computers — it does what it’s told. I don’t like Grub for the very reason that it tries to be too smart, even if you tell it what needs to be done. Grub was recently banished from my newest computer (Debian Lenny on an amd64 system from zareason.com) because it failed to do as I told it when I added a 2nd SATA drive. Lilo doesn’t argue with me.