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