How to Customize the GRUB2 Bootloader in Linux

As a critical component that loads your Linux operating system, configuring the GRUB2 bootloader properly is an essential sysadmin task. This in-depth 3200+ word guide will teach you how to edit the GRUB configuration file to customize different boot options for your Linux system.

We will cover the following topics:

• Overview of the GRUB boot process stages
• Finding and editing the main configuration file safely
• Changing defaults for the GRUB menu at startup
• Altering timeout delays, kernel options, backgrounds and themes
• Adding custom boot entries for rescue environments
• Passing advanced kernel parameters for debugging
• Integrating GRUB with systemd targets
• Securing the boot process against modification
• Rebuilding the bootloader when troubleshooting issues
• Comparisons vs. alternative boot programs like rEFInd

Follow along to gain expert-level experience configuring bootloaders on Linux!

Detailed Stages of the GRUB Boot Process

Before learning how to customize options, you need an overview of what GRUB does when booting Linux. When your system first turns on, the motherboard firmware initializes hardware and looks for bootable devices. This firmware then launches the main bootloader program.

GRUB has four stages to progressively load and prepare the Linux operating system kernel:

Stage 1(boot.img):

• Located in boot sector of bootable device
• Initializes minimal devices like block I/O
• Also has optional BIOS drivers and filesystem plugins for access
• Loads and executes the next stage

Stage 1.5:

• Optional transitional stage
• Provides interim filesystem and graphics drivers
• Allows loading stage 2 from difficult locations

Stage 2 (core.img):

• Parses GRUB configuration files
• Contains majority of GRUB code for features
• Provides environment for scripts to generate menu entries
• Handles graphical console output and user input
• Finally jumps to kernel execution

Stage 2 Continued:

• Called after firmware transition
• Performs pre-boot adjustments as needed by kernel
• Alters hypervisor settings if enabled
• Passes any designated kernel options
• Starts the Linux kernel image execution

After stage 2, GRUB parses the /boot partition and generates boot menu with titles and options. It then shows this menu, waits for user input, allows editing commands or options, and finally boots target OS.

This multi-stage process makes GRUB extremely flexible – being able to chainload boot processes from different locations. Understanding what each stage does helps debug issues later.

Now let‘s move on to the key file where GRUB boot options can customized.

Editing the Main Configuration File Safely

The main configuration file used by GRUB stage 2 is /boot/grub/grub.cfg. This contains script-generated menus and options from other snippet files.

Caution: Avoid directly editing /boot/grub/grub.cfg. It gets rewritten based on template files every time grub-mkconfig is called. You will lose any changes.

Instead, the file edited to customize GRUB options is:

/etc/default/grub

This is read by GRUB during generation of grub.cfg. Making changes to parameters in this file allows configuring the boot experience.

Some examples of /etc/default/grub options:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=3 udev.log_priority=3"
GRUB_DISABLE_RECOVERY=true

However, directly editing this file is also risky. Corrupted syntax can lead to abrupt boot failures.

I recommend the following safe process instead:

1. Backup the existing working configuration file
2. Make incremental changes to the backup copy first
3. Test bootloader rebuilds between sets of changes
4. Replace working config only after full validation

This helps recover easily after mistakes, compared to breaking boot process completely.

Now let‘s explore what options are available to customize the Linux boot experience.

Configuring the Default GRUB Boot Menu Entry

The first thing to set after GRUB menu appears is what operating system, kernel or recovery mode to boot by default. This allows skipping selection screen and automating startup.

The GRUB_DEFAULT variable decides the default boot menu entry. For example:

GRUB_DEFAULT=saved

If only one OS installed, index 0 selects the first auto-detected Linux image. Otherwise, counting starts from 0 for each title.

You can also boot from custom entries added to /etc/grub.d/40_custom script. Or use shortcuts like saved to load the most recent entry.

Setting an invalid number will fallback to automatic menu mode. So GRUB_TIMEOUT_STYLE=menu is useful as a failsafe here.

Altering the GRUB Menu Timeout Duration

The boot menu allows interrupting default OS boot to pick another option. Waiting period before auto-booting the default entry is controlled via:

GRUB_TIMEOUT=5

Where 5 is number of seconds. Increase for more time to react. Decreasing or zeros value immediately boots default entry.

You still hold down Shift or Esc while booting to temporarily access menu. But near-zero timeout provides convenience of skipping menu when desired.

I recommend keeping timeout between 5-15 seconds for dual-boot. Higher risks missing menu unless having issues to debug.

Passing Custom Kernel Options and Parameters

Bootloaders allow passing special options and tweaks to alter kernel behavior. This helps debugging issues or performance tuning your Linux system.

For example, disabling selinux:

GRUB_CMDLINE_LINUX="selinux=0"

… or removing ‘quiet‘ kernel messages suppression:

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT verbose" 

Make sure parameters separated by spaces are quoted in value.

These tweaks will apply to every new kernel. You can also pass options to just a specific Image section via:

menuentry "Linux" {
  linux /boot/vmlinuz-linux root=UUID=32d07d38-a611-4341-b38f-27ea4566faca rw loglevel=4
  initrd /boot/initramfs-linux.img
}

Where loglevel=4 will just enable debug for this Image.

Consult kernel docs for all available options. Useful for troubleshooting boot issues.

Let‘s next look at customizing background, graphics and themes in the GRUB menu.

Enhancing GRUB Visuals with Themes and Background Images

By default, GRUB uses a basic black-and-white color scheme. But customizing backgrounds and full themes adds polished UI aesthetics.

Setting a custom background logo or image uses:

GRUB_BACKGROUND="/boot/grub/background.png"  

Filesystem path points to a 1920×1080 resolution image matching display. Otherwise, distortion occurs trying to fit.

For further customization like transparent backgrounds, GRUB_BACKGROUND_RGBA:

GRUB_BACKGROUND_RGBA="0x2266AA80"

Uses 8-bit RGB and alpha opacity value. Helps integrated UI feel.

Beyond backgrounds, complete alternate themes packages drastically refresh menus:

• Font colors, highlights, gradients
• Widget borders, tab icons
• Notification dialogs, input forms

The Pixz GRUB Themes collection provides clean, modern light and dark options.

To use, add packaged theme under /boot/grub/themes/ directory. Then in /etc/default/grub:

GRUB_THEME="/boot/grub/themes/manjaro-19/theme.txt"  

Points to theme text file controlling asset variants used.

Boot UX polish wins Linux style points for desktops! Now on to advanced topics like adding custom entries.

Creating Additional Boot Menu Entries

While GRUB auto-detects installed operating systems, you may need to manually specify custom boot entries.

For example, old kernel versions for testing or recovery:

menuentry "Linux 4.19 LTS" {
  linux /boot/vmlinuz-4.19.0-21-amd64 root=UUID=bcdd08b3-236d-4528-90e7-58cebeafe645 ro
  initrd /boot/initrd.img-4.19.0-21-amd64
}

This loads the older 4.19 image rather than latest kernel each round.

You can also directly boot ISOs or external media paths for utility environments:

menuentry "Boot GParted ISO" {
  set isofile="/isos/gparted-live-1.3.0-1-amd64.iso" 
  loopback loop (hd0,1)$isofile
  linux (loop)/live/vmlinuz boot=live config noswap noprompt noeject nolocales union=aufs hostname=gpartedlive ip=frommedia toram quiet splash 
  initrd (loop)/live/initrd.img
}

This loads the GParted partition editor on demand from ISO.

Another common use case is booting fallback initramfs in emergencies:

menuentry "Arch Linux Fallback" {
  linux /boot/vmlinuz-linux root=UUID=riVAkv-nlWt-hQYW-jy8t-lm63-c6gb-fETWzi rw
  initrd /boot/initramfs-linux-fallback.img
}

Handy situational tools to have in menu for rescue, testing or recovery!

Securing the Boot Loader Configuration Against Changes

As GRUB boots the kernel directly, any tampering can compromise systems. Attackers with physical access replacing core.img or configuration files becomes risky.

So hardening GRUB against external or unauthorized modification is important for security. Some useful protective measures include:

1. Password-protecting boot menu and console commands preventing any runtime alterations:

   --unrestricted
   set superusers="youruser"
   export superusers
   password youruser YOUR-PASSWORD  

2. Using UEFI Secure Boot with keys checked against trusted signatures to prevent loading unsigned changed code or bootloaders.

3. Enabling GRUB‘s TPM support to store measurements in firmware and validate boot images cleanly entered boot state:

   grub_tpm_init
   initrd /EFI/BOOT/core.img_TPM
   boot

4. Custom certificates and encryption of critical assets like configuration file on unencrypted drives:

   GRUB_ENABLE_CRYPTODISK=y

A combination of encryption, validation, instrumentation and access controls hardens GRUB comprehensively. Preventing contamination of the boot sequence is crucial for trusted continuity of operations.

Rebuilding the Boot Loader After Making Changes

When customizing /etc/default/grub, always regenerate grub before rebooting:

grub-mkconfig -o /boot/grub/grub.cfg

or simply:  

update-grub

This applies changes to grub.cfg used on boot. Failing to update can lead to GRUB loading old configurations.

If you get errors like file not found, double check path values set match locations properly. Syntax issues also commonly appear.

Use backed up known working configs to easily revert problematic changes. This avoids breaking boot process completely when testing or learning.

That covers key options for customizing GRUB config. Now a quick comparison to alternatives….

How GRUB Compares to Other Bootloaders like rEFInd

The GRUB bootloader has been Linux standard for long time thanks to hardware compatibility and feature flexibility:

Advantages:

• Supports wide array of filesystems: ext2/3/4, iso9660, ufs2, etc
• Custom Lua scripts enhancing functionality
• Password protection restricts tampering
• Graphical bg images and themes
• UEFI and legacy BIOS platforms
• Grandfathered boot wisdom!

However modern alternatives like rEFInd have appeared for UEFI-based systems:

Key Differences:

• Automatic kernel finding without updates
• Support new filesystems like BtrFS or XFS
• Slick graphical UI with smooth animations
• Responsive touchscreen support out of box
• Beginner friendly descriptions and visuals

For most use cases, GRUB remains versatile Swiss army knife. But rEFInd simplifies configuration via "it just works" discovering. Nice for those valuing UEFI-first approach.

Now let‘s wrap up with some general troubleshooting advice…

Tips for Troubleshooting GRUB Boot Issues

Here are best practices when debugging GRUB problems:

• If menu background image doesn‘t load, verify custom path set exists and permissions allow reading file
• Text or graphical corruption likely means GRUB_GFXMODE doesn‘t match screen resolution – set proper dimensions
• Instantly booting default entry without menu visible indicates GRUB_TIMEOUT=0. Change back to 10+ seconds
• Error booting after changes could mean invalid GRUB_CMDLINE_LINUX parameter passed or syntax issue
• Boot hangs or screen stuck could also from bad config causing GRUB image problem – safe configs help recover
• Try older kernel versions or fallback initramfs from GRUB menu when boot issues suspected
• Boot live USB outside primary operating installations for forensic debugging as needed

Following along meticulously and isolating change sets makes troubleshooting easier. With practice customizing core configurations becomes second nature!

Conclusion

Learning to configure bootloaders provides great insight into initializing Linux environments. Practicing safely with GRUB options teaches how user settings cross-pollinate into early userspace. Mastering these foundational components will equip you for challenging tuning situations down the road!

I encourage grabbing a spare test system and trying some advanced kernel customizations. See the performance implications from boot tweaks. And explore visual theming adding polish to the bootflow.

Understanding the spectrum of configurations possible even before init systems boot hardens your Linuxfu skills significantly. Graduating from end user to enabling the entire stack is the hallmark of an expert.

With the comprehensive coverage here, you now have the knowledge to customize, enhance and tailor GRUB2 bootloaders to specific use cases. I invite you to join discussions with me on Linux Forum @ FreeCodeCamp if you have any further questions!