GRUB2 is a bootloader and the one used by Debian. A bootloader can be thought of as a mini operating system used to launch an operating system kernel. GRUB2 can also pass control to another bootloader. This is called "chainloading" and is often needed for dual-boot machines.
GRUB2 is typically installed during the installation of Debian itself. If properly installed, GRUB2 will be automatically detected by the computer's UEFI during boot (or BIOS for older computers). If multiple bootloaders exist on the same computer, such as with a dual boot machine, the user will need to enter their computer's UEFI or BIOS to set the priority order of the bootloaders present since the computer will execute only one bootloader after a successful power-on self-test (POST). (They may also need to turn off the Secure Boot option in UEFI to stop it from preventing GRUB2 from launching.)
NOTE: GRUB2 is often referred to as simply GRUB. GRUB2 is a re-write of an earlier version of GRUB, still in use but mostly on older computers, and now called GRUB Legacy. GRUB2 will normally be what is wanted for a machine with UEFI. It can also work with older machines with BIOS but GRUB Legacy may be found on those.
GRUB2 supports multiple operating systems on the same computer and can even be configured to present the user a menu of kernels from which to select. Other times it is configured to simply load a particular kernel quietly. GRUB2 has many options for configuring the look of the menu and how the entries in the menu behave when chosen.
Configure console menu colors
As of DebianWheezy, there is no support for easily modifying the colors of the console menu. /etc/default/grub does not have any variables that can set the colors for this video mode.
The easiest way to modify the console menu colors is to create a new file /boot/grub/custom.cfg and put your configurations there:
The variables that control the console menu colors are the following:
color_normal - the “normal” foreground and background terminal colors
color_highlight - the “highlight” foreground and background terminal colors
menu_color_normal - the foreground and background colors to be used for non-highlighted menu entries
menu_color_highlight - the foreground and background colors to be used for the highlighted menu entry
If you configured /boot/grub/custom.cfg, there is no need to run update-grub; the file will be automatically loaded by /boot/grub/grub.conf at boot.
Configure graphical splashimage
As of Bullseye, splash image is set in the following order:
If the GRUB_BACKGROUND variable in /etc/default/grub is set, this is used upon executing update-grub.
If /boot/grub/ has *.jpg *.JPG *.jpeg *.JPEG *.png *.PNG *.tga *.TGA, this is used upon executing update-grub.
background image and colors specified by desktop-base (select one via update-alternative), this is used upon executing update-grub
So putting your favorite image file to /boot/grub/` is the easiest way.
If you are to use grub2-splashimages, do as follows.
install the grub2-splashimages package: aptitude install grub2-splashimages
- choose one of the nice images to use as the splashimage. You can look at the images with any image viewer (Ex: display)
configure/add the GRUB_BACKGROUND variable in /etc/default/grub. Ex: GRUB_BACKGROUND="/usr/share/images/grub/Lake_mapourika_NZ.tga"
make sure that GRUB_TERMINAL=console is commented out. The graphical mode will not be enabled if this is uncommented. By default it's commented, so you shouldn't worry too much.
the graphical resolution can be changed via the variable GRUB_GFXMODE
- reboot to observe the change
NOTE: The version of grub-probe in DebianBookworm (and possibly others) does not always correctly detect encrypted volumes underlying LVM, so it does not create the needed .background_cache on the boot partition. In the meantime, the easiest way to work around this is to copy the image to /boot/grub/desktop-grub.png and set GRUB_BACKGROUND="/boot/grub/desktop-grub.png" in /etc/default/grub.
Configure encrypted /boot
Grub 2.02~beta2-29 supports reading an encrypted /boot partition.
Assuming you already have an encrypted system as setup by debian installer:
add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub
backup the contents of your /boot partition somewhere
create an LUKS container where your /boot partition was and unlock it
create an ext2 filesystem your LUKS container and mount it to /boot
restore the backup of your /boot partition to your new encrypted /boot
grub-install and update-grub
Configuring / choosing non-default or older kernel to boot
Set GRUB_DEFAULT in /etc/default/grub to other value than 0. A good description is in the official grub docs with samples GRUB # Simple-configuration. If SUBMENU is not disabled, use '>' character as an input key, for example, if you want to choose second menu/entry (first screen) and the 3rd kernel/entry in the submenu (second screen), then GRUB_DEFAULT=1>2. Remember that entries in grub2 start with 0/zero counter.
If you've changed grub configuration file /etc/default/grub, make sure to run update-grub to update its configuration.
UEFI vs BIOS boot
GRUB supports booting x86 systems via either the traditional BIOS method (aka "Legacy" or "CSM"), or more modern UEFI. How they start up is quite different, but in most cases the end result should be all-but-invisible to the user. Here's a comparison of how each works.
The first sector is important - that's how PCs boot. The firmware is very dumb - it just loads the first sector and executes code from it directly. See https://en.wikipedia.org/wiki/Master_boot_record for more information about the exact layout.
There's not very much space in the first sector, just enough for the partition table and a very small bootable stub. That stub knows just enough to be able to locate and load the second-stage loader (aka GRUB core).
The second stage loader fits in the gap between the first sector and the first partition. On most modern systems, the first partition will start at 1 !MiB into the disk so there's just under 1 !MiB of space for the GRUB core. That's a lot more space than just the boot sector, but it's still quite limited. It has the main bits of GRUB code built-in: typically key things like code to read different storage systems, partitioning layouts and filesystems. It also has a module loader.
Older systems that have a smaller partition gap here are becoming more and more difficult to support in GRUB - space is getting tighter and tighter as the core code grows and more features are added.
The core will locate the /boot/grub directory as instructed by its config, then potentially load all sorts of extra GRUB functionalitly from modules contained there.
Eventually, GRUB will load a kernel and initramfs and start the kernel.
In UEFI, the firmware is much more intelligent. Instead of just loading a raw sector from disk and executing code from it directly, the firmware includes (limited) support for storage and filesystems. This allows for many more useful options at boot time.
By setting UEFI Boot Variables, the firmware can be configured with a list of different UEFI programs to try to load and boot. If it can't find anything in the configured boot locations, the firmware will fall back to a hard-coded location: the so-called Removable Media Path.
For extra security, the firmware can also be configured to only allow running EFI programs that are signed with keys the firmware knows about (aka SecureBoot).
For GRUB, UEFI removes many of the older BIOS limitations. There is no need for the stub loader. Instead, the firmware loads and runs GRUB as a standard UEFI program (typically "grubx64.efi" on a 64-bit PC platform).
The default way to configure GRUB for UEFI is to install the GRUB core here. Just as for the BIOS boot case, it can then find /boot/grub and load modules for extra functionality.
In the SecureBoot case, however, the GRUB EFI binary is different. As GRUB does not (yet!) include support for signed modules, it cannot verify any modules that might be loaded later. So, in this case the module loader is disabled. All of the modules that might be needed are instead built in to a larger monolithic binary that can be signed. At runtime, this single binary is all that will run.