Translation(s): English - Français


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.

Feature overview

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:


set color_normal=light-gray/black

The variables that control the console menu colors are the following:

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:

So putting your favorite image file to /boot/grub/` is the easiest way.

If you are to use grub2-splashimages, do as follows.

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.

See also Grub/SplashImage, GrubEFIReinstall

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:

  1. add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub

  2. backup the contents of your /boot partition somewhere

  3. create an LUKS container where your /boot partition was and unlock it

  4. create an ext2 filesystem your LUKS container and mount it to /boot

  5. restore the backup of your /boot partition to your new encrypted /boot

  6. 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.

BIOS world

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 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.

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.