Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Modifying Kernel Boot Parameters

Modifying Kernel Boot Parameters

Publication Date: 02 Dec 2024
WHAT?

This article introduces the concepts, examples and modification process for kernel boot parameters to customize the boot process and optimize the resulting environment.

WHY?

Modifying kernel boot parameters is essential for achieving specific system configurations and addressing several scenarios, including performance optimization, better hardware compatibility, and troubleshooting issues such as graphics drivers.

EFFORT

It takes 15 minutes to fully understand the concepts and the process, and five minutes to modify kernel boot parameters and observe their effect after a reboot.

GOAL

Modify kernel parameters to customize the boot process and the subsequent environment.

REQUIREMENTS

Depending on whether you want to apply changes in kernel boot parameters to the upcoming boot process, or all subsequent boot processes, the requirements are as follows:

  • To change kernel boot parameters on an experimental basis only for the upcoming boot process, there are no requirements.

  • To change kernel boot parameters for all subsequent boot processes, you should have root or equivalent administrative privileges.

1 Introduction to kernel boot parameters

 

Before modifying kernel boot parameters, it is important to understand the basic concepts: definition, methods, benefits and examples of modifying kernel boot parameters.

1.1 What are kernel boot parameters?

 

Kernel boot parameters are configurations passed to the SUSE Linux Enterprise kernel during the boot process managed by the GRUB 2. The configurations are instructions to the GRUB 2 boot loader on how to configure certain features and make them behave in the intended manner. The method of modification depends on whether you want the changes to impact only the next boot, or all subsequent boots until further changes are made.

1.2 Methods of modification

 

You can modify the kernel boot parameters using the following methods:

Temporarily

Changes are held in memory and apply only to the upcoming boot process. These changes made through the GRUB 2 boot menu are not written to any configuration file and are discarded after reboot.

Permanently

Changes are written to /etc/default/grub file and persist across all subsequent boot processes. For permanent changes, we recommend using the YaST Control Center instead of directly editing the /etc/default/grub file.

However, if you directly edit the /etc/default/grub file, modify the GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT variables. After modification, regenerate the GRUB 2 configuration by running the following command with administrative privileges. 

> sudo grub2-mkconfig -o /boot/grub2/grub.cfg

1.3 Benefits of modifying kernel boot parameters

 

Modifying kernel boot parameters is essential for achieving specific system configurations and addressing several scenarios, including:

  • Performance optimization.  Tweaking parameters to enhance system performance, responsiveness, and overall efficiency based on specific system requirements. For example, using the quiet parameter suppresses most boot messages, reducing boot time and improving performance during startup.

  • Hardware compatibility.  Tailoring parameters to ensure compatibility with specific hardware components, addressing potential compatibility issues. For example, the acpi=off parameter can be used to disable the Advanced Configuration and Power Interface (ACPI) to resolve boot problems on older hardware.

  • Troubleshooting.  Altering parameters to troubleshoot issues such as graphics driver problems, ensuring a more stable and functional system. For instance, the nomodeset parameter can disable kernel mode setting, which is helpful when troubleshooting issues with graphics drivers that prevent the system from booting.

1.4 Examples of commonly modified kernel boot parameters

 

There are several kernel parameters that you can optionally modify to customize your boot process. Based on your use case, you can consider a few of the most commonly modified kernel boot parameters:

  • root=: Specifies the path to the root file system.

  • quiet: Suppresses most boot messages.

  • splash: Displays a graphical boot splash screen.

  • nomodeset: Disables kernel mode setting.

  • debug: Enables debugging output.

  • acpi=: Toggles the Advanced Configuration and Power Interface (ACPI) settings.

For a detailed understanding of all available kernel parameters and their possible values, source documentation is available at https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt.

1.5 General rules for specifying values of kernel boot parameters

 

When modifying kernel boot parameters, follow these essential formatting rules:

Basic Parameter Spacing

Separate individual parameters with a single space:

  • In YaST, select System › Boot Loader › Boot Loader Settings › Kernel Parameters. Enter parameters in the Optional Kernel Command Line Parameter field with spaces between them.

  • In the /etc/default/grub configuration file for GRUB 2, use spaces between kernel parameters when passing them as string values to the GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT variables.

  • At the boot menu, press E to edit, locate the line starting with linux, and add parameters with spaces.

Example 1: Separate individual parameters with a single space
 
root=/dev/sda1 quiet splash
Parameter Value Assignment

When assigning values, use the equals sign (=) without spaces:

Example 2: Correct method of assigning values to kernel parameters
 
root=/dev/sda1 video=1920x1080
Example 3: Incorrect method of assigning values to kernel parameters
 
root = /dev/sda1 video = 1920x1080
Values Containing Spaces

For values containing spaces, the handling differs between methods:

YaST Control Center Boot Loader

Enter the value with quotes directly in the parameter field; the YaST Control Center handles the spacing appropriately before passing it on to GRUB 2.

Example 4: Kernel parameter values containing spaces in the YaST Control Center
 
root="/dev/mapper/USER VOLUME"
GRUB 2 configuration file

Use either double quotes with escape characters, or use backslashes.

Example 5: Kernel parameter values containing spaces in the GRUB 2 configuration file
 
GRUB_CMDLINE_LINUX="root=\"/dev/mapper/USER VOLUME\""
GRUB_CMDLINE_LINUX="root=/dev/mapper/USER\ VOLUME"
GRUB 2 Boot Menu

Use only double quotes for values containing spaces:

Example 6: Kernel parameter values containing spaces in the GRUB 2 boot menu
 
root="/dev/mapper/USER VOLUME"
Multiple values for a kernel parameter

Use commas without spaces to separate multiple values for a single parameter in all methods:

Example 7: Multiple values for a kernel parameter
 
console=tty0,tty1 video=HDMI-A-1:1920x1080@60,VGA-1:1024x768

2 Difference between kernel boot parameters and linuxrc parameters

 

Kernel boot parameters and linuxrc parameters are often similar in appearance, but conceptually they are entirely different. It is important that you do not confuse them and understand their basic difference.

2.1 What are linuxrc parameters and why are they different from kernel boot parameters?

 

In SUSE Linux Enterprise, the linuxrc script is executed during the boot process before the system's root file system is mounted. It acts as the initial RAM disk (initrd) entry point and sets up the environment needed for the kernel to load the root file system. linuxrc parameters are used to pass configurations that affect this early stage of the boot process, such as driver loading, debugging options, or hardware initialization.

In contrast, kernel boot parameters are passed to the kernel by the boot loader (such as GRUB 2) after the initial RAM disk has handed control to the kernel. The kernel boot parameters directly influence how the kernel operates and manages system features such as power management, debugging and hardware interaction after the root file system is mounted.

The distinction is critical because linuxrc parameters are used to configure the environment before the kernel fully initializes, whereas kernel boot parameters control the behavior of the kernel after this point. Misinterpreting or interchanging the two can lead to improper configurations and boot failures.

To learn more about the linuxrc parameters and their usage, refer to https://documentation.suse.com/sles/html/SLES-all/appendix-linuxrc.html.

2.2 Examples of linuxrc parameters

 

The following examples highlight common linuxrc parameters and their use cases to configure the environment before the kernel initializes:

  • rd.driver.blacklist=: Specifies drivers to be blocked in the initrd. For example, rd.driver.blacklist=nouveau prevents the nouveau graphics driver from loading during the early stages of boot. This can be useful when troubleshooting driver-related boot issues.

  • rd.break: Interrupts the boot process and drops the system to a shell within the initrd for debugging purposes. This parameter is helpful for diagnosing issues related to the early boot process, such as driver loading or file system mounting errors.

  • rd.retry=: Specifies the number of retries for device scanning in the initrd. For example, rd.retry=3 configures the system to retry scanning devices three times before giving up, which can be critical for resolving transient hardware initialization issues.

  • rd.luks=1: Enables support for encrypted devices in the initrd. This parameter is essential for systems that use encrypted root file systems, ensuring that decryption takes place during the initial boot stage.

By contrast, equivalent kernel boot parameters such as quiet or nomodeset are not used in the initrd phase but take effect after the kernel is fully initialized. This reinforces the need to distinguish between these two types of parameters.

3 Temporarily modifying kernel boot parameters

 

To change kernel boot parameters on an experimental basis only for the upcoming boot process, edit the options available on the GRUB 2 boot screen. Such changes are applied only to the upcoming boot process and the resulting session; the changes do not persist after reboot.

Example 8: Temporarily modify kernel boot parameters using the GRUB 2 boot menu
 

As an example of modifying kernel boot parameters for the upcoming boot process, we disable the splash screen that you can see during the boot.

  1. Switch on your computer to start the boot process.

  2. In the GRUB 2 boot screen, highlight the entry you want to modify using the arrow keys ↑ and ↓.

  3. Press the E key. You are presented with an editor and the content of the selected boot entry. It looks similar to the following: 

    setparams ' '
...
...
echo 'Loading Linux KERNEL_VERSION ...'
linux /boot/vmlinuz-KERNEL_VERSION
root=UUID=56d052b3-9148-4161-8065-3d97378d5783 ${extra_cmdline} splash=silent resume=/dev/disk/by-uuid/69ff0e54-23a7-4ba8-8983-5a29c54ffa5e
quiet security=apparmor crashkernel=301M,high crashkernel=72M,low mitigations=auto

  4. Search for the string splash=silent and remove it.

  5. To boot the entry, press F10 or Ctrl–X.

    To discard the changes and start anew, press the Esc key.

After executing the procedure and continuing with the boot process, no splash screen is observed for the current boot process. On the next boot, the splash screen reappears.

4 Permanently modifying kernel boot parameters

 

To change kernel boot parameters persistently for all subsequent boot processes, edit the kernel parameters using YaST Control Center as root or a user with equivalent administrative privileges.

Example 9: Permanently modify kernel boot parameters using YaST Control Center
 

As an example of modifying kernel boot parameters persistently for all subsequent boot processes, we disable the splash screen that you can see during the boot.

Warning
Warning

Before modifying kernel boot parameters, create a copy of the existing stable GRUB 2 configuration (/etc/default/grub) somewhere outside of your system. If the boat loader gets corrupted and your system fails to boot, or you face problems after booting your system, the backup helps you compare and restore the parameters to the last known working configuration.

  1. Log in to your system as root, or switch to a user with equivalent administrative privileges after logging in to your system.

  2. In your running system, open a root shell and run the following command: 

    # yast bootloader

    Alternatively, open the YaST Control Center application and select System › Boot Loader.

  3. Under the Kernel Parameters tab, edit the string for the Optional Kernel Command Line Parameter field. 

    splash=silent resume=/dev/disk/by-uuid/69ff0e54-23a7-4ba8-8983-5a29c54ffa5e  quiet security=apparmor crashkernel=301M,high crashkernel=72M,low

    As you can see, the string splash=silent is printed. Remove splash=silent from the string.

  4. Select OK to save the boot loader configuration.

  5. Reboot. You should see that the splash screen does not appear.

After executing the procedure and rebooting the system, we do not observe any splash screen for all subsequent boot processes.

Note
Note: Editing the GRUB 2 configuration file

If you directly edit the /etc/default/grub file, modify the GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT variables. After modification, regenerate the GRUB 2 configuration by running the following command with administrative privileges. 

> sudo grub2-mkconfig -o /boot/grub2/grub.cfg

5 Troubleshooting and FAQs

 

While modifying kernel boot parameters, challenges may arise, potentially leading to system instability or boot failure. It is important to understand the potential challenges and systematic approaches to resolving configuration issues.

5.1 Troubleshooting kernel boot parameter modifications

 

Effective troubleshooting requires a methodical investigation of system behaviors and configuration changes. A few troubleshooting strategies and steps to address a few common issues are listed in this section.

5.1.1 Identifying and correcting parameter issues

 

  1. Validate parameter syntax and configuration:

    1. Verify the spelling accuracy of all kernel parameters.

    2. Check for correct formatting without unnecessary spaces.

    3. Confirm that the parameters are recognized by the kernel. If you are modifying a parameter that is already part of the standard configuration, check the output of the cat /proc/cmdline command. For a complete list of allowed parameters, refer to the kernel documentation at https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt.

  2. Investigate system logs for detailed error information: 

    > sudo dmesg | grep -i error
    > sudo journalctl -b | grep -i "kernel parameter"

  3. Temporarily enable or disable suspicious parameters to isolate issues. For example, use nomodeset to troubleshoot device driver issues related to graphics cards.

5.1.2 Recovering from boot failures

 

  1. Access system recovery options:

    • Use the GRUB 2 recovery mode during system startup.

    • Select advanced boot options to enter a minimal working environment.

  2. Restoration methods for different configuration approaches:

    YaST Control Center modifications

    1. Open the YaST Boot Loader module.

    2. Revert to the previous working boot configuration.

    3. Save changes and reboot.

    Direct GRUB 2 configuration restoration

    1. Restore from pre-modification backup: 

      > sudo cp /etc/default/grub.bak /etc/default/grub

    2. Regenerate the GRUB 2 configuration: 

      > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

5.1.3 Managing system stability

 

  1. Perform a comprehensive system log analysis: 

    > sudo journalctl -xe
    > sudo dmesg | tail
    > sudo systemd-analyze verify

  2. Systematically remove the recently added kernel parameters.

  3. Create configuration backups before modifications: 

    > sudo cp /etc/default/grub /etc/default/grub.bak
    > sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak

  4. If the issues persist, consider restoring the working configurations from a backup or booting using a previously working system snapshot.

6 For more information