Wednesday, October 13, 2010

GRUB2 and chroots, dammit!

Worst outcome from an install so far. Upon automatic reboot, when all is reported success:

error: the symbol `grub_xputs` not found
grub rescue:>

Terror struck my heart, and hopelessness, and googling. I found that not only was I not alone, but it is a result from a long-standing bug, which bothered me greatly as I was installing:, specifically: "Grub doesn't identify SATA drives in the same order as the BIOS." Not only was this extremely confusing to me as I was trying to decide what to do during the install, even though I thought I had prepared very well, but also, "I had to boot from the live image and chroot" as the bug commenter did.

On the other hand,that worked well. See the process here: Guess what the post is called? Fix Symbol 'grub_puts' Not Found When Migrating From Ubuntu Karmic To Lucid.Imagine that. BUG IS STILL THERE. And it bit me, and that hurt. A side issue is that my /home isn't found, but I think I know the fix for that, and I'm sure it is partially my ignorance and inexperience at fault.

There were other possible solutions suggested, which I didn't try. For starters, I could only have one computer plugged into the Internet at a time, which meant I was looking for solutions in one screen, and typing them in on the other. The less to type, the fewer chances of typing errors making the problem even worse. But here they are, if you are in terror as I was, and my solution didn't work, or has disappeared: and


Comment I got by email from Holger Herzog:

Hi Valorie,

I read your blog entry - thanks much for that! - and I ran into further troubles caused by something that was not mentioned on _any_ of the web sites regarding this grub problem:

I have boot fs and root fs on different partitions!

Then I had to mount the _root_ fs partition as described in the tutorials and _additionally_, I had to mount the boot fs under "boot" under the mounted root fs:
mount /sdROOT /mnt/temp
mount -B /dev /mnt/temp/dev
mount -B /dev/pts /mnt/temp/dev/pts
mount -B /proc /mnt/temp/proc
mount -B /sys /mnt/temp/sys

AND, additionally:
mount /sdBOOT /mnt/temp/boot

Otherwise I got an empty "grub>" prompt with no kernels found by grub.


Problem presented in #kubuntu tonight with the same problem (and maybe the same bug cause) where grub was installed onto the USB key instead of on the hard drive. And even after Grub2 was installed on the HD,
sudo apt-get install grub2
still was non-booting. The magic command which finally fixed grub
sudo grub-setup /dev/sda


  1. I've been running Linux since 1995, adminning Unix professionally since a few years later, and have used Ubuntu since before the releases went in alphabetical order. And I ran in to the same problem. So don't worry much about inexperience being to blame for this specific thing. :)

  2. there is another way for solving this using supergrub 2 which is a 1.44 MB download from supergrubdisk website. Burn it to a CD or USB and boot the media supergrub 2 can search and locate the misplaced grub and boot from that so that you are booted to a functioning linux system so that you can fix grub from there.
    I posted my experience using this in my blog you can find more details there.

  3. See my blog post for a full explanation of what's going on here. The bug comment you found is actually a very unhelpful one, from a commenter who has a bee in his bonnet about one particular thing; I've tried to persuade him that he has the wrong end of the stick, but with no luck. Bug 630529 is closer to the mark, at least if I'm right in guessing that you were installing from a USB stick.

    You didn't say what version of Ubuntu you were installing. Perhaps you could contact me by e-mail (cjwatson at so that I can make sure I have all the facts straight?

  4. Also, simply running 'sudo grub-setup /dev/sda' will store up problems for later. The correct fix is 'sudo dpkg-reconfigure grub-pc', and tell it to install to /dev/sda when you get to the relevant dialog.

  5. I was the one who filed the referenced bug report, and as stated in the bug status it has in fact been fixed. You are experiencing something different (with similar symptoms).

    That error means that grub wasn't actually installed to the drive you're booting from (more technically, the embedded core.img doesn't match the modules in /boot/grub). This can be caused by many different circumstances. If you could run boot info script as explained here:
    and post the RESULTS.txt along with the output of "debconf-show grub-pc" I can probably tell you what is happening in your case. It's important that you do find the root cause, as running grub-install is only a temporary fix, and without fixing the root cause you will likely get this problem again the next time you do a major upgrade.

    As for the comment @

    That user, to put it bluntly, has no idea what he is talking about. What he says is the problem is in no way related to bug and shows a fundamental misunderstanding of how bootloaders work.

    I tried to explain this but eventually gave up as arguing in bug reports is not appropriate or productive. Please don't help spread this misinformation.

  6. Unfortunately I can't confirm either way, at this late date.

  7. I'm glad to say that KDE has been putting some work into this. See for more details. :-)