Modifying Kernel Boot Parameters

Publication Date: 14 Sep 2026

Kernel boot parameters configure how the SUSE Linux Enterprise Server for NVIDIA kernel starts and behaves, controlling areas such as hardware compatibility, performance and diagnostics. Set them temporarily from the GRUB 2 boot menu to test a change for a single boot. To apply a change to every subsequent boot, set it permanently in the boot loader configuration instead. Understanding the correct syntax and where to apply it lets you tune a system for a specific workload and resolve hardware-related boot problems. You can also roll back safely if a change causes issues.

Prerequisites:

To change kernel boot parameters on an experimental basis for the upcoming boot process, you need physical or remote console access to the system. Examples include a hypervisor console or a hardware management interface. This method does not work over SSH, since the system is not yet reachable over the network at that point in the boot process.
To change kernel boot parameters for all subsequent boot processes, you need root or equivalent administrative privileges.

Revision History: Modifying Kernel Boot Parameters

1 Introduction to kernel boot parameters #

Kernel boot parameters tell the kernel how to behave at startup. Knowing where they come from and how GRUB 2 passes them to the kernel makes it easier to change them correctly. This knowledge also helps you reason about which change to make for a given problem.

1.1 What are kernel boot parameters? #

Kernel boot parameters are configurations passed to the kernel during the boot process managed by 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 change to affect only the next boot, or all subsequent boots.

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 the /etc/default/grub file and persist across all subsequent boot processes. For permanent changes, we recommend using the update-bootloader command 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

This command applies only to the standard, non-immutable system. It fails on the immutable mode of SLE for NVIDIA, whose read-only root file system is only writable inside a new transactional snapshot. There, run update-bootloader through transactional-update instead of calling it directly:

> sudo transactional-update run update-bootloader --add-option PARAMETER=VALUE

To only regenerate the GRUB 2 configuration, without adding or removing a parameter, use the dedicated subcommand instead:

> sudo transactional-update grub.cfg

In immutable mode, changes take effect only after a reboot, since they live in a new snapshot until then.

Note: Snapshots do not stack without a reboot

Each transactional-update run call branches its new snapshot from the currently running system, not from an earlier snapshot you have not yet booted into. Running the command again before rebooting does not combine the two changes: only the most recent snapshot becomes the one that boots next, and it does not include the earlier, not-yet-activated change. Reboot to activate each change before making the next one.

1.3 Benefits of modifying kernel boot parameters #

A few common reasons to modify kernel boot parameters:

Performance. Tune the kernel for a specific workload. For example, the quiet parameter suppresses most boot messages, which shortens boot time.
Hardware compatibility. Work around a hardware quirk the kernel misdetects by default. For example, the acpi=off parameter disables the Advanced Configuration and Power Interface (ACPI), which can resolve boot problems on older hardware.
Troubleshooting. Isolate a driver or subsystem that is preventing the system from booting. For instance, the nomodeset parameter disables kernel mode setting, which helps when a graphics driver prevents the system from booting.

1.4 Examples of commonly modified kernel boot parameters #

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.
selinux=0: Disables SELinux, which is enabled by default on SLE for NVIDIA 16. For the recommended approach, the permissive mode alternative, and how to relabel the file system after reenabling SELinux, see .

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:

With update-bootloader, add each parameter with its own --add-option call. The command inserts the spacing for you:
```
> sudo update-bootloader --add-option quiet
> sudo update-bootloader --add-option splash
```
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:

update-bootloader

Warning: Configuration corruption from unescaped spaces

update-bootloader --add-option does not quote or escape a value for you: a value containing a space is split into two separate boot parameters, corrupting the configuration. For a value containing spaces, edit /etc/default/grub directly or use the GRUB 2 boot menu instead, both described below.

GRUB 2 configuration file

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

Example 4: 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 5: Kernel parameter values containing spaces in the GRUB 2 boot menu #

root="/dev/mapper/USER VOLUME"

Multiple values for a kernel boot parameter

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

Example 6: Multiple values for a kernel boot parameter #

module_blacklist=nouveau,radeon

2 Difference between kernel boot parameters and linuxrc parameters #

Older SUSE documentation distinguishes kernel boot parameters from linuxrc parameters. On SUSE Linux Enterprise Server for NVIDIA 16, that distinction no longer applies to an installed system: linuxrc is gone, and the parameters that used to be associated with it are ordinary kernel boot parameters handled by dracut.

2.1 What happened to linuxrc on SLE for NVIDIA 16? #

linuxrc was the boot-time parameter parser used by the installer on earlier SLE for NVIDIA releases. It ran only during installation, before the target system's root file system existed, so it played no part in an already-installed system. It is not present on SLE for NVIDIA 16 at all: SLE for NVIDIA 16 installs exclusively with Agama, which does not use linuxrc. Agama provides a compatibility layer for a handful of linuxrc option names, for administrators migrating scripts or profiles built around the old parser. For the installer-time options and the compatibility mapping, see Section 6, “For more information”.

What remains is dracut, the framework that builds the initial RAM disk (initramfs). It brings up the environment the kernel needs before the real root file system is mounted, such as loading storage drivers or unlocking encrypted devices. Unlike linuxrc, dracut is not specific to installation. It also runs on every boot of an installed system.

The options that configure dracut are not a separate parameter category with their own syntax. They are ordinary kernel boot parameters, entered on the same GRUB 2 command line and following the same rules described in this article. Among these, dracut simply acts on the ones it recognizes before handing off to the rest of the boot process.

2.2 Examples of dracut parameters #

The following kernel boot parameters are handled by dracut during the initrd stage, before the root file system is mounted:

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 how long, in seconds, dracut retries configuring devices before giving up. For example, rd.retry=240 extends the default 180-second timeout, which can help on hardware that takes longer than usual to initialize storage devices.
rd.luks=0: Disables LUKS-encrypted device detection in the initrd. Detection is enabled by default on a system with an encrypted root file system. Use this parameter only if you need to turn it off, for example while troubleshooting an unrelated storage issue.

Because these are kernel boot parameters like any other, the temporary and permanent modification methods described elsewhere in this article apply to them. They work the same way as for quiet or nomodeset.

3 Temporarily modifying kernel boot parameters #

To change kernel boot parameters on an experimental basis for the upcoming boot process, edit the options in the GRUB 2 boot menu. This method requires physical or remote console access to the system and does not work over an SSH connection. Such changes apply only to the upcoming boot process and the resulting session, and do not persist after reboot.

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

Restart the system. By default, the GRUB 2 menu appears with a brief countdown, and the saved entry boots automatically once it expires. If your system has been configured to hide the menu instead, press Esc while the SLE for NVIDIA boot logo shows to reveal it.
In the GRUB 2 boot menu, highlight the entry you want to modify using the arrow keys ↑ and ↓.

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 'SLE for NVIDIA 16.1'
...
...
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=selinux selinux=1 crashkernel=377M,high crashkernel=72M,low mitigations=auto

Search for the string splash=silent and remove it.
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, use the update-bootloader command as root or a user with equivalent administrative privileges.

update-bootloader options used in this task #

--get-option PARAMETER: Prints the current value of a parameter, if set.
--add-option PARAMETER=VALUE: Adds a parameter, or replaces its value if it is already set.
--del-option PARAMETER: Removes a parameter.
--config: Applies pending changes to the boot loader configuration.

Tip: Test before making a change permanent

On a production system, test the parameter temporarily first, as described in Section 3, “Temporarily modifying kernel boot parameters”. Confirm it has the effect you expect before committing to a change that applies to every subsequent boot.

Example 8: Permanently modify kernel boot parameters using update-bootloader #

As an example of modifying kernel boot parameters permanently, we disable the splash screen that appears during boot.

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 boot loader gets corrupted, or you face problems after booting, your system might fail to start. The backup lets you compare and restore the last known working configuration.

Log in as root, or switch to a user with equivalent administrative privileges.
Check whether the parameter you want to change is already set:
```
# update-bootloader --get-option splash
```
The command prints the currently configured value, for example splash=silent.
Remove the parameter from the default boot options:
```
# update-bootloader --del-option splash
```
To add or change a parameter instead of removing one, use update-bootloader --add-option PARAMETER=VALUE. Setting an already-present parameter again replaces its value rather than adding a duplicate entry.
Apply the change to the boot loader configuration:
```
# update-bootloader --config
```
Reboot to confirm the splash screen no longer appears.

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

Note: Editing the GRUB 2 configuration file directly

update-bootloader works consistently across the boot loaders SUSE supports, including GRUB 2 and the systemd-boot preview. If you prefer to edit /etc/default/grub directly instead, see Section 1.2, “Methods of modification” for the variables to modify and the command required to apply the change.

5 Troubleshooting and FAQs #

A wrong or unsupported kernel boot parameter can leave a system unstable or unable to boot. This section covers how to identify a bad parameter, recover a system that no longer boots, and confirm stability after a change.

5.1 Troubleshooting modifications to kernel boot parameters #

The following steps cover the most common issues: an incorrect parameter, a system that fails to boot, and a system that boots but behaves unpredictably afterward.

5.1.1 Identifying and correcting parameter issues #

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 the parameter is already part of the standard configuration, check the current value with cat /proc/cmdline. For a complete list of allowed parameters, refer to the kernel documentation at https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt.
Investigate system logs for detailed error information:
```
> sudo dmesg | grep -i error
```
```
> sudo journalctl -k -b
```
The journalctl -k -b output includes a Command line: entry showing the exact kernel boot parameters the kernel received for the current boot, which you can compare against what you intended to set.
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 #

A system that fails to boot is no longer reachable over the network. You need physical or remote console access (for example, a hypervisor console or a hardware management interface) to perform the following steps.

Boot into recovery mode:
1. Restart the system.
2. By default, the GRUB 2 menu appears automatically with a brief countdown. If your system has been configured to hide the menu instead, press Esc while the SLE for NVIDIA boot logo shows to reveal it.
3. At the GRUB 2 menu, select Advanced options for SLE for NVIDIA 16.1.
4. Select the (recovery mode) entry for the kernel version you want to boot.
Recovery mode boots the system in single-user mode, without the parameters set for normal boot. It gives you a minimal working environment to fix the configuration.
Fix the configuration. Recovery mode does not use GRUB_CMDLINE_LINUX_DEFAULT, so you have a working root shell regardless of what it currently contains:
- If you have a pre-modification backup, restore it:
```
> sudo cp /etc/default/grub.bak /etc/default/grub
```
- If you do not have a backup, remove the offending parameter directly:
```
> sudo update-bootloader --del-option PARAMETER
```
Regenerate the GRUB 2 configuration:
```
> sudo update-bootloader --config
```

5.1.3 Managing system stability #

Before making further changes, back up the current, still-working configuration:

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

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

Check the system logs for errors or warnings introduced by the change:
```
> sudo journalctl -xe
```
```
> sudo dmesg | tail
```
If a parameter change made the boot noticeably slower, check which units took the longest to start:
```
systemd-analyze blame
```
Remove the recently added parameters one at a time, rebooting after each, to find the cause.
If the issues persist, restore the backup from the first step, or boot from a previously working system snapshot.

6 For more information #

For a full list of kernel parameters and their possible values, see the https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt upstream kernel documentation.
For the boot options recognized by the Agama installer at install time, see . These replace the linuxrc parameters used by earlier SUSE installers.

7 Legal Notice #

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.

For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.