GRUB version 1 (GRUB legacy)
The master boot record (MBR) usually contains GRUB stage1, but can contain another bootloader which can chain boot GRUB stage1 from another boot sector such as a partition’s volume boot record. Given the small size of a boot sector (512 Bytes), stage1 can do little more than load the next stage of GRUB by loading a few disk sectors from a fixed location near the start of the disk (within its first 1024 cylinders).
Stage1 can load the stage2 directly, but it is normally set up to load the stage 1.5. GRUB stage 1.5 is located in the first 30 KB of hard disk immediately following the MBR and before the first partition. If this space is not available (unusual partition table, special disk drivers, GPT or LVM disk) the install of stage 1.5 will fail. The stage 1.5 image contains file system drivers. This enables the stage 1.5 to directly load stage 2 from any known location in the filesystem, for example from /boot/grub. Stage 2 will then load the default configuration file and any other modules needed.
GRUB version 2 (GRUB)
boot.img has the exact size of 446 bytes and is written to the MBR (sector 0). core.img is written to the empty sectors between the MBR and the first partition, if available (for legacy reasons the first partition starts at sector 63 instead of sector 1, but this is not mandatory). The /boot/grub directory can be located on an distinct partition, or on the root partition.
Stage 1: boot.img is stored in the master boot record (MBR), or optionally in any of the volume boot records (VBRs), and addresses the next stage by an LBA48 address (the 1024 cylinder boundary of GRUB legacy is omitted); at installation time it is configured to load the first sector of core.img.
Stage 1.5: core.img is by default written to the sectors between the MBR and the first partition, when these sectors are free and available. For legacy reasons, the first partition of a hard drive does not begin at sector 1 (counting begins with 0) but at sector 63, leaving a gap of 63 sectors of empty space. That space is not part of any partition or file system, and therefore not prone to any problems related with it. Once executed, core.img will load its configuration file and any other modules needed, particularly file system drivers; at installation time, it is generated from diskboot.img and configured to load the stage 2 by its file path.
Stage 2: files belonging to the stage 2 are all being held in the /boot/grub directory, which is a subdirectory of the /boot directory specified by the Filesystem Hierarchy Standard (FHS).
Once GRUB stage 2 has loaded, it presents a TUI-based operating system selection (kernel selection) menu, where the user can select which operating system to boot. GRUB can be configured to automatically load a specified kernel after an user-defined timeout. If files or the partition become unavailable, or if the user wishes to take direct control, stage 2 will drop the user to the GRUB command prompt, where the user can then manually specify the boot parameters.
In the operating system selection menu GRUB accepts a couple of commands:
By pressing e, it is possible to edit parameters for the selected operating system before the operating system is started. Typically, this is used for changing kernel parameters for a Linux system. The reason for doing this in GRUB (i.e. not editing the parameters in an already booted system) can be an emergency case: the system has failed to boot. Using the kernel parameters line it is possible, among other things, to specify a module to be disabled (blacklisted) for the kernel. This could be needed, if the specific kernel module is broken and thus prevents boot-up. For example, to blacklist the kernel module nvidia-current, append modprobe.blacklist=nvidia-current at the end of the kernel parameters.[9]
By pressing c, the user enters the GRUB command line. The GRUB command line is not regular Linux shell, like e.g. bash, and accepts only certain GRUB-specific commands, documented by various Linux distibution[10]
Once boot options have been selected, GRUB loads the selected kernel into memory and passes control to the kernel. Alternatively, GRUB can pass control of the boot process to another boot loader, using chain loading. This is the method used to load operating systems such as Microsoft Windows, that do not support the Multiboot Specification or are not supported directly by GRUB.
If the usage of dm-crypt is intended, the contents of /boot, i.e. /boot/grub, the Linux kernel and initramfs respectively initrd need to be on a distinct non-encrypted partition, because the logic to handle encrypted partitions resides inside of the Linux kernel.
Installation