Introduction: Beyond the Static Boot Menu
For advanced Linux users, system administrators, and multi-boot enthusiasts, the default GRUB2 boot menu, while functional, often falls short in terms of flexibility and automation. Imagine a bootloader that intelligently detects operating systems, conditionally boots into specific environments based on system state, or even offers a recovery option only when a particular flag is set. This isn’t just a fantasy; it’s entirely achievable with GRUB2’s powerful scripting capabilities.
This ultimate guide delves deep into the art of dynamic GRUB2 menus, empowering you to move beyond static entries. We’ll explore conditional logic, environment variables, OS detection techniques, and practical scripting examples to create a GRUB2 menu that adapts to your system’s needs, enhancing your multi-boot experience, server management, and disaster recovery strategies.
GRUB2 Fundamentals: A Quick Recap
The Core Files: grub.cfg and 40_custom
At the heart of GRUB2’s configuration lies /boot/grub/grub.cfg. This file is the primary configuration, but it’s generated automatically by update-grub (or grub-mkconfig). Manual edits to grub.cfg are almost always overwritten. Instead, we use a modular approach.
The recommended way to add custom entries and scripts is by creating executable files in /etc/grub.d/. The most common file for custom entries is /etc/grub.d/40_custom. Files in this directory are sourced by update-grub in numerical and then alphabetical order, and their output forms part of the final grub.cfg. By default, 40_custom contains a placeholder:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.All your dynamic scripting and custom menu entries will reside here, or in new files you create (e.g., 41_mydynamicboot).
Environment Variables and Defaults
GRUB2 relies on variables defined in /etc/default/grub for global settings. Key variables include:
GRUB_DEFAULT: Specifies the default boot entry. Can be an integer (0 for first entry), a quoted menu entry title, orsavedto boot the last chosen entry.GRUB_TIMEOUT: Sets the delay in seconds before the default entry is booted.GRUB_TIMEOUT_STYLE: Can behidden,menu, orcountdown.
For dynamic menus, we’ll often manipulate GRUB_DEFAULT and leverage GRUB2’s internal environment variables.
Unleashing GRUB2 Scripting Power
GRUB2’s shell-like environment allows for powerful scripting directly within its configuration. This is where the magic of dynamic menus truly begins.
Conditional Logic: if/else/elif/fi
The fundamental building block for dynamic behavior is conditional execution. GRUB2 supports familiar if/else/elif/fi constructs:
if [ condition ]; then
# commands if condition is true
elif [ another_condition ]; then
# commands if another_condition is true
else
# commands if no condition is true
fiThis syntax is crucial for making decisions about which menu entries to show or which OS to boot.
Testing Conditions: The ‘test’ Command
The test command (or [ ] shorthand) is used within if statements to evaluate conditions. Common tests include:
test -f /path/to/file: Checks if a file exists.test -d /path/to/directory: Checks if a directory exists.test x = y: Compares strings (xandy). Usingxprefix handles empty strings safely.test x != y: Checks for string inequality.
Example: Check if a recovery flag file exists:
if test -f /recovery_mode_flag; then
echo "Recovery mode enabled!"
fiVariables and Persistence: set & save_env
GRUB2 allows you to set and manage variables:
set VARNAME="value": Defines a variable for the current GRUB session.save_env VARNAME: Persistently saves the current value ofVARNAMEto/boot/grub/grubenv.load_env: Loads all persistently saved variables fromgrubenvinto the current session.
To use persistent variables effectively, you typically enable GRUB_DEFAULT=saved in /etc/default/grub and then use save_env in your custom entries to remember the last booted OS.
Advanced OS Detection Techniques
True dynamic menus require the ability to detect the presence and location of operating systems or specific boot environments.
Identifying Partitions: The ‘search’ Command
The search command is indispensable for locating partitions without relying on fixed GRUB device names (like (hd0,msdos1)), which can change. It can search by UUID, filesystem label, or even by file presence.
search --set=root --fs-uuid UUID_STRING: Setsrootto the partition with the given UUID.search --set=root --label LABEL_STRING: Setsrootto the partition with the given label.search --set=root --file /path/to/file --hint hd0,msdos1: Finds a partition containing a specific file. The hint improves search speed.
Example: Finding a Linux partition by UUID:
search --set=root --fs-uuid a1b2c3d4-e5f6-7890-1234-567890abcdef
set prefix=(${root})/boot/grubProbing for OS Presence
Once you’ve identified a potential root partition, you can use test -f to check for OS-specific files.
- For Linux: Check for
/vmlinuz,/boot/vmlinuz,/etc/fstab. - For Windows: Check for
/EFI/Microsoft/Boot/bootmgfw.efi(UEFI) or/bootmgr(BIOS).
Combined example: Detect a specific Linux installation:
# Attempt to find the partition by UUID
search --no-floppy --set=linux_root --fs-uuid a1b2c3d4-e5f6-7890-1234-567890abcdef
if [ "${linux_root}" != "" ]; then
# Check if a Linux kernel exists on that partition
if test -f (${linux_root})/boot/vmlinuz; then
echo "Linux found on ${linux_root}!"
# You can now define a menuentry using this root
else
echo "Linux partition found, but no kernel."
fi
else
echo "Specific Linux partition not found."
fiPractical Dynamic Menu Scenarios & Implementation
Let’s put these concepts into practice with real-world scenarios. All these examples will be placed into /etc/grub.d/40_custom (or a similar custom file).
Scenario 1: Default to Last Booted OS
This is a common desire. GRUB2 supports it natively using saved environment variables.
First, edit /etc/default/grub and change:
GRUB_DEFAULT=0
to
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=trueThen, in your 40_custom or any menu entry in other /etc/grub.d/ files, ensure the --id option is used, and save_env boot_once is called. This example defines a custom menu entry for an imaginary OS and ensures GRUB remembers if it was selected:
menuentry 'My Custom OS (Persistent)' --id='my_custom_os' {
set root=(hd0,msdos2)
linux /boot/vmlinuz-custom root=/dev/sda2 quiet splash
initrd /boot/initrd.img-custom
save_env boot_once
}After booting this entry, grubenv will record boot_once=my_custom_os, making it the default until another entry is selected.
Scenario 2: Conditional Boot into a Recovery Environment
Imagine a system that normally boots into a production OS, but if a specific flag file exists (e.g., /force_recovery on your main partition), it should offer a prominent recovery option or even boot directly into it.
menuentry 'Production System' --id='production_os' {
search --set=root --label MyProdOSLabel
linux /boot/vmlinuz root=LABEL=MyProdOSLabel ro quiet splash
initrd /boot/initrd.img
}
# --- Conditional Recovery Mode ---
# Search for the main production OS partition to check for the flag file
search --no-floppy --set=prod_root --label MyProdOSLabel
if [ "${prod_root}" != "" ]; then
if test -f (${prod_root})/force_recovery; then
menuentry '!!! EMERGENCY RECOVERY MODE !!!' --id='recovery_mode' {
# Assuming recovery kernel/initrd are on the same partition or a dedicated one
set root=${prod_root}
linux /boot/vmlinuz-recovery root=LABEL=MyProdOSLabel ro recovery_mode
initrd /boot/initrd.img-recovery
}
# Optionally, make recovery the default if the flag is present
set default="recovery_mode"
set timeout="10"
fi
fiThis script first defines the regular