Translation(s): English - Français
Contents
Overview
GRUB2 is the default BootLoader used by Debian. A boot loader can be thought of as a mini operating system used to launch the main operating system's 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 order in which the available bootloaders will run: 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. The earlier version of GRUB (v1) is now only useful on very old computers, and is called GRUB Legacy. In particular, GRUB2 will normally be needed for a machine with UEFI.
Multi-booting
GRUB2 allows you to have multiple operating systems (and different versions of the same kernel) installed. It will, by default, show the available options in a menu and allow the user to choose which one to boot. GRUB2 has many options for configuring the look and contents of the menu and what will happen when something is chosen. It can also be configured to simply load a particular operating system quietly.
Configuring GRUB2
You can change GRUB2 by editing files in /etc/grub.d/ or /etc/default/grub and running update-grub as root. See https://www.gnu.org/software/grub/manual/grub/grub.html#Simple-configuration for the upstream documentation.
Changing the menu colors
Adding set color_normal=light-gray/black will change the colors used.
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
The background (second) color must be black if you have an image; black is transparent; any other background color will obscure the image.
Showing an image on boot (a '''splash image''')
GRUB can show an image behind the menu. The default comes from the desktop-base package, and there are more in grub-splashimages. You can use an image by:
placing a file with a name ending in .jpg, .JPG, .jpeg, .JPEG, .png, .PNG, .tga, or .TGA, in /boot/grub/; or
setting the GRUB_BACKGROUND variable in /etc/default/grub to the path of an image to use (However, GRUB is not able to access images on encrypted filesystems, so you should copy the image into /boot/grub (See #997844) or to an unencrypted filesystem)
The resolution of the image can be changed via the variable GRUB_GFXMODE. Run update-grub to make GRUB notice any changes.
Make sure that GRUB_TERMINAL=console is commented out in /etc/default/grub (it will be commented out by default): graphical mode will be disabled if this is uncommented.
Encrypted /boot
GRUB supports 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
run grub-install and update-grub
Choosing the default operating system kernel
The default is for the latest installed kernel to be booted by default. To make a different menu item the default, set GRUB_DEFAULT in /etc/default/grub to the number of the entry, starting from zero. See GRUB # Simple-configuration for details.
If SUBMENU is enabled, use '>' to separate values. For example, GRUB_DEFAULT="1>2" will set the default to the item found from position 2 (on the first screen) and then position 3 in the submenu (second screen): all entries start at 0.
Make sure to run update-grub after making any changes.
UEFI vs BIOS boot
GRUB supports booting x86 systems via either the older BIOS method (aka "Legacy" or "CSM"), or the more modern UEFI. Although UEFI and BIOS are quite different, the end result should be all-but-invisible to the user. Here's a comparison of how each works.
BIOS world
The first sector on the disk 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 functionality from modules contained there.
Eventually, GRUB will load a kernel and initramfs and start the kernel.
UEFI world
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.
Migrating from BIOS to UEFI
See GrubEFIReinstall
GRUB2 and software RAID
Debian can be installed onto a software RAID (with mdadm, ZFS or Btrfs), usually to prevent data loss in case a drive fails. In such a case, GRUB2 must already be present on the remaining drive(s) of the RAID array, including possible spare drives, so that the computer can still boot.
In BIOS mode
The GRUB2 stub must be installed on all drives of the RAID array. Simply run dpkg-reconfigure grub-pc, then validate default answers except for the last question, where you should select each drives of the RAID array in sequence.
In UEFI mode
The ESP (EFI System Partition) and its content must be present on all drives of the RAID array. This functionality is not offered by Debian packages (see bug 925591) but GRUB2 hooks are a way to achieve the same goal.