Think of GRUB as being a fairly sophisticated program in its own right ... a tiny, stand-alone complete single-user operating system
whose main purpose in life is to locate and load another operating-system, or that operating system's own "boot loader" as the case may be, and to pass control to it.
Because GRUB is, of itself, such a complete and sophisticated program, it has the ability to do quite a few things before the system is actually booted. (Needless to say, these commands are especially useful for dealing with cases when the desired system cannot
be booted, and you are late for dinner, and your boss is breathing down your neck and turning an ominous shade of bright cherry red...
and you are trying to figure out why!)
The "MBR," or "master boot record," is the very-simple piece of code that your computer's very-simple built-in BIOS uses, basically, "to find GRUB and load it." As long as your BIOS can find GRUB,
that's all that your BIOS
has to do. Everything else from that point on is handled by GRUB. The GRUB
"miniature operating-system" is, for a brief time, actually in complete control of the machine.
GRUB uses "ordinary" configuration-files located in "ordinary" directories, simply because it knows how to read "ordinary files and directories" for several different types of operating-systems. This makes the system very easy to manage. The boot-sequence is highly customizable. This is what leaves simpler systems like LILO completely
"in the dust," imho.
When a boot-failure occurs in a Linux
environment, it is (in my experience) usually caused by a missing file in the /boot
partition. And the problem is usually easily-corrected by loading a different kernel. (Even if you failed to provide for that in the grub.conf
menu, you can use interactive commands from within grub
to get yourself out of this pickle... you can "do what the menu does, by hand.") The Linux bootup-sequence is fairly nice because the system very quickly puts itself into "a Linux environment" and plays by its own rules.
When a boot-failure occurs in a Windows
environment, assuming that the grub.conf
entries are specified properly, I find that the single most common cause of the problem is a failure to specify the LBA
attribute for the target partition in the partition-table. The Windows boot-loader, which must
carry out the "actual" Windows boot-process, is and always has been a remarkably stupid program that does not enter a "'real' Windows environment" until almost the very last minute. But these are not the fault of Grub.