It wouldn't boot from the hard drive period. Evidently the hard drive with containing the root partition was corrupt. I could only boot from the livecd. If the livecd had a repair option the user could try and check his hard drive, setup his video, etc from the livecd. Just a thought...
Grub had my primary boot partition as root (hd0,4) instead of root (hd0,0) and had added those two map statements to the XP section of menu.lst.
root (hd 0,4)
map (0x81) (0x80)
map (0x80) (0x81)
So I couldn't boot into XP either.
I don't know how it had gotten do messed up, I had not had any severe crashes or anything.
I don't know how that Windows stanza was created in that fashion, but grub did not create it as such. Grub only uses the map lines when the Windows installation is on a separate drive, ie (hd1,n) (hd2,n) not (hd0,n). On the other hand, we have no idea what else is in your /boot/grub/menu.lst because you haven't posted that information.
As far as the original premise of the thread goes, if the OS boots to a command line log in, all the command line tools of Linux are at your disposal, to fix almost anything. If the OS does not boot at all, there is no OS from which to run any utilities, so no use for such a menu. Not knowing what might possibly be wrong on any given boot to the command line, there are no magic apps to just fix things. You as the system operator need to learn what apps are part of a standard installation, and how to best use them, when faced with a specific problem.
In other words, the menu is in your head, if you learn the various apps functions. Most of the tools you use in the GUI have their CLI counterparts. You just call them by name, rather than click on an icon. If you don't know the names of the apps, a menu wouldn't do much good anyway.
On the other hand, you can use both command line and GUI apps, from the liveCD, to repair almost anything on your installed OS, so if you are command line impaired, at the moment, just boot the liveCD and use the GUI tools.
