HOWTO Deal with GRUB _, grub> _, and GRUB GRUB GRUB

[stoat]

Those are the manifestations of three situations in which GRUB fails to boot but does not produce an error message or any other indication of what is wrong. They are discussed often enough here and elsewhere on the Internet. However, there is very little explanation to be found. I offer these opinions of mine about them and some suggested actions until someone can prove them wrong or produce better ideas.


GRUB _


When GRUB stage1 runs, but the next stage does not for some reason, the boot process can hang with "GRUB _" on the screen. When it happens, the underline is blinking and the system is frozen requiring a hard reboot.

What I think is happening...

When GRUB boots normally, stage1 prints the word "GRUB" followed by a space in the upper left corner of a blank black screen. The next stage is usually stage1.5 when GRUB is installed in the master boot record and stage2 when it is installed in a partition boot sector. When the next stage runs, it completes the phrase on the screen to either "GRUB Loading stage1.5" or "GRUB Loading stage2". It reminds me a little of how LILO prints the letters "L", "I", "L", and then "O" as it progresses through stages of booting.

Circumstantial evidence of that can be seen by using a binary file editor like ghex or hexedit to view the text "GRUB " (including the trailing space) amongst other message text in the binary file /boot/grub/stage1 which is the image file used by the GRUB shell to create the actual stage1 that it installs (Note: grub-install uses the image files located in /usr/share/grub/i386-redhat in Fedora or in /usr/lib/grub/i386-pc in most other Linuxes). The text phrase "Loading stage1.5" can be seen amongst other message text in the binary file /boot/grub/e2fs_stage1_5 which is one of the file system image files used by the GRUB shell to create the actual stage1.5 that it installs. And the text phrase "Loading stage2" can be seen amongst other message text in the binary file /boot/grub/stage2 which is, of course, the actual stage2 involved in the GRUB boot process.

If that momentary message seen while GRUB is booting is partly written by stage1 and partly by either stage1.5 or stage2, then this system hang with "GRUB _" is an indication that stage1 ran, but the subsequent stage probably never started. The GRUB manual states that stage1 usually handles errors by printing an error message and then halting. The very small size of stage1 that allows it to reside in the master boot record also precludes extensive error handling capabilities which often leads to the occurrence of this anomaly.

Some possible ways for stage1 to run but fail to find the next stage...

1. Changes to the drive cables or BIOS boot order. Correct this by reversing the changes or by re-installing GRUB.
   
   
2. Faulty installation of GRUB that manifests itself immediately after installing the system. Most examples of this are clearly caused by errors of the user during the installation of the system. Sometimes it appears to "just happen" (the root cause is not obvious or never understood). Correct this by re-installing GRUB or the entire system.
   
   
3. Botched attempts at re-installing GRUB that are always caused by errors of the user. Correct this by re-installing GRUB.
   
   
4. Corruption of the next stage in some way. This is known to occur sometimes after a yum update. The root cause of these incidents is usually never understood. Correct this by re-installing GRUB.
   
   
5. BIOS settings related to the hard drives. Correct this by trying different settings.

http://fedoraforum.org/forum/showthread.php?t=154727
http://fedoraforum.org/forum/showthread.php?t=150264
http://fedoraforum.org/forum/showthread.php?t=201191
http://ubuntuforums.org/showthread.php?t=328616
http://www.linuxquestions.org/questi...d.php?t=503078
http://www2.linuxcompatible.org/Fedo...B__t34474.html
http://www.linuxforums.org/forum/lin...ng-newbie.html


grub> _


This occurs when GRUB stage1 runs and is followed eventually by stage2 which also runs but halts without displaying the GRUB menu. It is not a system hang but is a working GRUB shell prompt that is preceded by simple editing instructions.

What I think is happening...

The text "grub> " (including the trailing space) and the text of the GRUB shell editing instructions can be seen with a binary file editor in the messages section of the binary file /boot/grub/stage2. Those particular pieces of text do not appear in the binary file /boot/grub/stage1 nor any of the stage1.5 image files. So having the boot process abort to this grub> prompt is good circumstantial evidence that stage2 is at least successfully starting. For example, one of the first tasks of stage2 is to read the file /boot/grub/grub.conf to create the GRUB menu. If grub.conf is not found or is corrupted or is badly misconfigured, booting is suspended ending at this GRUB shell command prompt where commands may be entered manually.

This situation requires correction of the problem with grub.conf. Re-installing GRUB does nothing for a missing or busted grub.conf file. Nevertheless, other reasons for this event apparently happen and are amenable to simply re-installing GRUB as the first example below demonstrates. Therefore, re-installing GRUB should always be tried for this situation if no obvious problem with the grub.conf file can be found.

http://fedoraforum.org/forum/showthread.php?t=214548
http://fedoraforum.org/forum/showthread.php?t=29835
http://fedoraforum.org/forum/showthread.php?t=150590
http://fedoraforum.org/forum/showthread.php?t=2195
http://fedoraforum.org/forum/showthread.php?t=155361
http://fedoraforum.org/forum/showthread.php?t=195339


GRUB GRUB GRUB...


This situation appears to be one in which GRUB stage1 is restarting itself in an infinite loop and filling the entire screen with many copies of the word "GRUB". There are a variety of anecdotal reports of this abnormality on the Internet, and I was able to reproduce none of them. This problem is said by some to be caused by the BIOS drive detection being set to "AUTO" instead of "USER" in some hardware situations. Another Internet anecdote left the drive detection setting on "AUTO" but found that changing a BIOS drive setting called "Access Mode" from "CHS" to "AUTO" solved the problem. I have seen a few other scenarios only anecdotally related to this particular GRUB phenomenon.

Other examples of this problem are a little more understandable. The Gentoo GRUB Error Collection says this GRUB behavior can be caused by a botched attempt to re-install GRUB in the master boot record. One example of this occurred in a Windows/Linux dual boot system where the Linux system was re-installed several times while also switching its BIOS drive priority. I have read about several examples of this problem occurring after multiple, frantic, thrashing attempts at re-installing the system or GRUB.

I consider this to be the least common of these "undocumented" GRUB anomalies. The correction of it is harder to suggest with any confidence since it occurs in such various scenarios of which most are only anecdotal in nature. Studying the situation to untangle the mess is about the only thing to do. Re-installing GRUB should always be tried since there are examples where it was a remedy for this. Then there is always the option to clear out and start over being older and wiser (hopefully).

http://www.trilithium.com/johan/2005/06/grub-grub-grub/
http://www.linuxquestions.org/questi...d.php?t=518849
http://linux.derkeiler.com/Mailing-L...5-05/0041.html
http://fedoraforum.org/forum/showthread.php?t=192527
http://fedoraforum.org/forum/showthread.php?t=189381
http://fedoraforum.org/forum/showthread.php?t=150007
http://www.linuxquestions.org/questi...d.php?t=578583
http://www.gentoo.org/doc/en/grub-error-guide.xml


NOTE: The re-installation of GRUB is one of the most discussed subjects in this forum. Nevertheless, I do have a few comments about that...

1. Some examples of classic methods to re-install GRUB from a terminal command line prompt...
   
   Re-install GRUB in MBR of /dev/sda (Fedora 7 and later)
   Re-install GRUB in MBR of /dev/hda (ante Fedora 7)
   Re-install GRUB in the first sector of a boot partition (/dev/sdc1)
   
   
2. The Super Grub Disk is a free utility that is capable of re-installing GRUB in the master boot record or in a partition boot sector. It can also be used to emergency boot the wounded system if it is still capable of booting. Once the system is running, another alternative is to use one of the classic methods in a terminal to re-install GRUB.
   
   
3. The well-known grub-install command is a front-end script for the GRUB shell, and they can both be used to re-install GRUB. But grub-install and the GRUB shell behave differently when they re-install GRUB. For example, the GRUB shell does not recreate any of the files in the /boot/grub subdirectory, whereas the grub-install command always recreates stage2 and all of the stage image files located there (but not grub.conf, menu.lst, device.map, or splash.xpm.gz). The reason that I mention this now is to recommend that if one of them fails to correct a GRUB problem, then try the other. It could make a difference in some situations.

[RonPolley]

Thanks for the link to Super Grub Disk, This is a tool all of us multi OS,multi distro linuxers should have.

[pnelsonsr]

After upgrading a F9 install to F10 I got the GRUB _ problem as well. I grabbed my handy Super Grub Disk (here). Booted it up and had it detect my current Grub setup (MBR on /dev/sda) and then I told it to fix it. It did and I rebooted and was able to boot up f10!

[glennzo]

Nice job Stoat. I thought this was worth a "sticky" since, as you stated, it's discussed often enough, so its "stuck".

[chaime]

Stoat --

Thanks for all your posts on grub.

Unfortunately, I can't seem to get this thing to work. I love fedora, but this grub thing seems pretty finnicky. All I did was I added another partition on sda (which is actually hda) with the Windows XP control center that I was going to use as the page file drive, to avoid disk thrashing, anyways...

Now Fedora won't load, in fact nothing will. I get grub>

I have tried a lot of things, including going to a shell on the Live CD and doing

grub-install /dev/sda

It tells me something like

Probing devices to guess BIOS drives. This may take a long time.
The file /boot/grub/stage1 not read correctly.
#

I also tried to edit the grub.conf file using sudo gedit...interestingly enough, it is already pointing to the proper partition (hd0,2) as root. All I could imagine based on the posts is that the UUID might not be right, but I checked it with blkid and it's fine.

The only thing I haven't tried is deleting the partition because I'm not too familiar with either GRUB or fdisk and I don't want to screw anything up.

I don't get this. Should I just reinstall Fedora?

Help?

[pnelsonsr]

Have you tried the Super Grub Disk mentioned above? If not give that a try.

[chaime]

You know if I had read the whole section I probably would have given that a try. After trying everything I could think of with the Live CD and Grub, I just reinstalled Fedora 10...

But I'm happy to announce that the whole process took less than 15 minutes once I decided to do that, on a 5 year old system. This thing is NICE.

Chaim

[jbkt23]

Well, timely article. I just upgraded my laptop and then a number of follow up installs. I went from F8 to F10 i386. When I rebooted the third time I got the .........Grub_ prompt. So fortunately I had made the dvd, I did a HD install, so I booted into rescue mode did a little look around, backed up grub.conf, chrooted into the image and did # grub-install /dev/sda. All was well on reboot.

I am wondering if one cause of the first stage boot failure is a stagnant /boot/grub/device.map that points to a path that has been renamed. This could happen often on upgrades. Just speculation no evidence here.

[chaime]

Okay...feel free to tell me at any time if I shouldn't be posting this in a sticky, but in my own thread.

Anyways, the problem I'm having now is I often want to boot into one or the other of my operating systems, but Grub seems to be set up to go to Fedora unless I press a key (in fact it used to tell me to press a key, now if I don't press a key at the _ prompt it doesn't even tell me it's going to boot automatically).

This is different from GRUB configurations I've seen in the past which almost always go to the boot menu (splash screen?) and give me 30 seconds to choose. My preference would be just go to the splash screen and let me choose.

What controls all this? Any pointers?

Thanks,

Chaim

[glennzo]

What controls that is the line that reads default=. Default=0 boots the first option in the menu, default=1 boots the second and so on.

[jbkt23]

The line:
hiddenmenu
in grub.conf does what it says. So comment out that line:
#hiddenmenu

and then change:
timeout=5
to the length of time you want the menu to wait in seconds before choosing the default as glennzo described previous. Note that pressing any key other than enter and maybe space bar will halt grub from choosing until a choice is made.