We had a little power outage last night so when I came down this morning, the computer was, naturally, off. Turn it on, wait for boot process to complete only to see the wonderful words:
Attempting to enter rescue mode
error: the symbol ‘grub_xputs’ not found
grub rescue>
Lovely way to start the weekend.
Luckily, I have alternate means of computing. After some googling, my solution is simple, but mysterious. First, I’ll note that this is the latest version of grub- v.198-20100 on Debian/squeeze. I recall the upgrade occurring recently.
Anyway, my solution was to enter into the BIOS and fix the boot device. I have 3 hard drives, a 60GB Maxtor, a 160GB WD, and an 320GB WD SATA drive. For some reason, the SATA drive was specified as the boot device. In fact, I think all of my hard drive devices were shuffled around. The boot device is supposed to be the 60GB Maxtor drive.
After that change, everything booted up just fine. Meaning the original ‘grub-xputs’ thing meant that a boot image could not be found. Interestingly, this problem did not happen with my EEE after the update. Perhaps because it doesn’t have multiple hard drives.
Anyway, it’s up and running again. So I’ve got that going for me.
For now.
UPDATE: A little more investigation leads me to believe the problem was introduced during the grub-install portion of the update to grub. Basically, this problem happens if the grub-install is done to a drive that isn’t the actual boot drive. Here’s the thing, I know the boot drive of this computer and simply would NOT have pooched it. So I’m thinking that grub-install got confused due to a combination of a several internal drives, two of them being IDE and one being SATA. I’ve noticed that my /dev/hda drives are gone. All the drives have ‘sd’ designations in the /dev directory. So quite a few things have changed.
Still, the strangest thing is how the boot device order got mangled. I haven’t touched the BIOS since I set this system up about 6 months ago. Very odd.
LAST UPDATE: Well, I stepped into that one full stride.
Turns out that I did NOT setup the system with my 60GB drive as boot. I DID setup my SATA drive with a boot partition. How do I know? Because I blogged it way back when I did it! Therefore, my problem was entirely self-inflicted. No mysterious changes to my BIOS. No confusion by grub-install. The only confusion was on my part.
When grub was recently updated, I incorrectly installed it to the 60GB drive. I should have installed it to the SATA drive. I’ve now run dpkg-reconfigure grub-pc and rectified the situation. Amusingly, I had to go back into the BIOS and undo all my changes from earlier this morning.
On the plus side, at least I was smart enough to write this stuff down!
Yeesh.
9 replies on “Grub Rescue Mode on AMD64”
Thanks for blogging about this. I got hit with this issue as well, but I don’t have multiple disks in my system. In my case I guess the issue is that grub is installed to my linux partition, not the MBR.
I’ve been putting off fixing this, and am wondering how you went about booting into your system with a broken grub.
Thanks
Well, in my case, I lucked out because the *prior* version of grub still existed and was able to boot the system from my actual boot partition. Once I was running, I just had to reinstall grub as mentioned.
How much are you able to do from grub-rescue? Does ‘help’ work or anything like that?
‘help’ does not work. I can do ‘ls’ which shows my partitions, and ‘ls /’ lets me view the directories of my linux partition.
I haven’t tried other commands.
When you use the ‘ls’ commands, does anything come up like an ‘initrd’ file, or a ‘vmlinuz- file?
If so, and you know what your root partition is, you might be able to boot your system manually. Basically, you’ll need to enter a command like “linux (hd0,2)/boot/vmlinuz- root=/dev/sda2” to load the kernel image. If an initrd file is present, load it with a command like “initrd /initrd-“. Finally, entering the command ‘boot’ will try to do exactly that.
In the above command, “hd0” is the hard disk device, and the ‘2’ is the partition to attempt to boot from followed by the location of the kernel image, which will most likely be under the “boot” directory. If you have a dedicated ‘boot’ partition, then don’t specify ‘boot’ in the path. The “root=” part defines what partition is the root partition of the file system after boot. If the “linux” command fails, try a “set root=(hd0,2)” sort of command to set root of the boot partition, then redo the linux command and omit the (hd0,2) portion.
If none of those commands are working, try to load the normal grub shell using the command “insmod /boot/grub/normal.mod”. If successful, the above commands should become available.
If none of that is successful, you may need to fix it using a live-usb/cd or potentially using the rescue mode of an install image.
> If none of that is successful, you may need to fix it using a live-usb/cd or potentially using the rescue mode of an install image.
I guess that’s what I’m going to do. I can’t seem to load any module with insmod. They all die with the “‘grub_xputs’ not found” error
thanks for the feedback.
I got that problem when doing a clean install of Mint 10.10 using the main procedure – backed up home directory, then did full install. It didn’t even ask me where to plant grub.
Mint 9 put grub on a different partition by default and it worked great. Mint 10, without asking, changed my primary boot drive to the one with the Ext4 partition – and when I rebooted: `token_xputs’ not found. Talk about feeling blindsided…
Restoring my original boot partition in the BIOS fixed the problem. But why did Mint 10 change my boot partition without asking? It also didn’t seem to notice I was also running Windows 7, unlike Mint 9. If it doesn’t ask, it really should not change any BIOS entries. That’s beyond rude.
I found your blog entry here and it saved the day for me. And yes, it ran the grub-install update on a multiple-drive system without consulting me about the boot partition. It just changed an entry in my BIOS without my permission.Without your help I’d have searched for the solution for hours.
Many thanks!
TJ
You’re welcome. Glad my pain was someone else’s gain.
Thanks for blogged this !
I got that boring issue since ages ago, and you just gave me the idea to change the HDD priority in the bios setups !
It was so simple and all… then you resolved both of my problems, thanks !
You’re welcome, glad it helped.