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.
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...
- Changes to the drive cables or BIOS boot order. Correct this by reversing the changes or by re-installing GRUB.
- 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.
- Botched attempts at re-installing GRUB that are always caused by errors of the user. Correct this by re-installing GRUB.
- 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.
- BIOS settings related to the hard drives. Correct this by trying different settings.
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.
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).
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...
- 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)
- 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.
- 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.