Translation(s): English - Français

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:

Ex:

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.

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

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.