When the kernel needs a nudge
You upgraded your graphics driver and the display stays black after login. Or your laptop refuses to wake from sleep without a specific ACPI flag. Or you are debugging a hardware interrupt storm and need to disable a device at boot. The solution is almost always the same: pass a parameter to the Linux kernel before it finishes initializing. You know you have to touch the bootloader, but you are worried about typing the wrong thing and locking yourself out of your own machine.
What the bootloader actually does
The Linux kernel does not probe your hardware blindly. It reads a single line of space-separated flags that tell it how to handle memory, drivers, and hardware quirks. GRUB sits between your firmware and the kernel. It loads the kernel image into RAM, hands it that flag string, and steps aside. The string you see in the boot menu is generated from a template file. If you edit the template and do not regenerate the menu, your changes vanish on the next package update. If you edit the generated menu directly, your changes disappear on the next reboot. You need to change the source of truth, rebuild the configuration, and verify the kernel actually received the flags.
The boot chain follows a strict order. Your firmware hands control to GRUB. GRUB loads the kernel and the initial ramdisk. The kernel mounts the real root filesystem and hands control to systemd. Kernel parameters only matter during the first two stages. Once systemd takes over, the flags are already baked into the running system. Changing them requires a reboot. Trust the boot chain. Edit the template, regenerate the menu, and restart.
Test the parameter first
Never bake a new kernel flag into your permanent configuration without testing it. A typo in a driver parameter can drop you into a root shell or freeze the display manager. Test from the GRUB menu before touching any files.
Here is how to pass a temporary flag that only lasts for one boot cycle.
# Hold Shift or Esc during boot to interrupt GRUB automatically
# Press e to edit the highlighted boot entry
# Find the line starting with linuxefi or linux
# Append your parameter to the end of that line
# Press Ctrl+X or F10 to boot with the temporary change
If the system boots and the issue resolves, you know the parameter works. If the system hangs or drops to a shell, reboot and skip the edit. The temporary change never touches disk. Test until the flag works, then make it permanent.
Make the parameter permanent
Fedora stores the GRUB template in /etc/default/grub. The file you actually boot from lives in /boot/grub2/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. You only edit the template. The system regenerates the boot file automatically during kernel updates, but you must run the generator manually after editing the template.
Here is how to open the template and add your parameter safely.
# Open the GRUB template with your preferred editor
sudo nano /etc/default/grub
# Locate the GRUB_CMDLINE_LINUX variable
# Keep the existing flags intact
# Append your new parameter inside the quotes
# Save and exit the editor
The variable should look like this after your edit.
# Reserves memory for kernel crash dumps
crashkernel=auto
# Hides boot spam and shows the Fedora logo
rhgb quiet
# Disables the nouveau driver for NVIDIA hardware
nouveau.modeset=0
The crashkernel=auto flag reserves memory for kernel crash dumps. The rhgb and quiet flags hide boot spam and show the Fedora logo. Your new flag sits at the end. Do not remove the existing flags unless you know exactly what they do. Missing rhgb quiet will flood your screen with kernel messages. Missing crashkernel=auto will break kdump if you ever need it.
Here is how to regenerate the boot configuration and apply the change.
# Rebuild the GRUB configuration from the template
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# The output path depends on your firmware type
# BIOS systems use /boot/grub2/grub.cfg
# UEFI systems use /boot/efi/EFI/fedora/grub.cfg
# Reboot to load the kernel with the new flags
sudo reboot
Fedora convention dictates that you edit files in /etc/ and never touch /usr/lib/. The /usr/lib/ directory holds package-managed files that get overwritten on updates. The /etc/ directory holds your overrides. grub2-mkconfig reads /etc/default/grub and merges it with hardware detection scripts to produce the final boot menu. Run the generator after every template edit. Trust the package manager. Manual file edits drift, snapshots stay.
Verify the kernel received the flags
The kernel prints its command line to a virtual file in /proc. You can read it without root privileges.
Here is how to confirm the parameter is active.
# Read the exact string the kernel booted with
cat /proc/cmdline
# Check the kernel ring buffer for driver initialization
journalctl -k | grep nouveau
If your parameter appears in the output, the bootloader passed it correctly. If it is missing, you either edited the wrong variable, forgot to run grub2-mkconfig, or booted a different kernel version. Check the kernel version with uname -r and verify you edited the correct template. Run journalctl -k first. Read the actual initialization log before guessing.
Common pitfalls and recovery
Typos in kernel parameters do not always produce clear error messages. The kernel silently ignores unrecognized flags. If you type nouveau.modeset=0 as nouveau.modeset=of, the driver loads normally and your fix does nothing. Double check spelling and spacing.
Missing quotes around the variable value breaks the shell parsing. If you leave the quotes off, the shell splits the string at spaces and passes only the first word to GRUB. The configuration generator will fail with a syntax error.
/etc/default/grub: line 15: syntax error near unexpected token `quiet'
UEFI and BIOS systems use different output paths for grub2-mkconfig. Running the BIOS path on a UEFI system creates a configuration file that GRUB never reads. Your reboot will load the old parameters. Check your firmware type with lsblk -o TYPE,FSTYPE or efibootmgr. Use the correct path.
Editing the generated grub.cfg directly is a dead end. The file contains hardware UUIDs and menu entries that change on every kernel update. Your edits vanish without warning. Always edit /etc/default/grub.
If a bad parameter locks you out, follow this recovery sequence. Order matters because an incorrect step can overwrite your working configuration.
- Reboot and interrupt GRUB by holding Shift or pressing Esc.
- Highlight the working boot entry and press e.
- Remove the problematic parameter from the linux or linuxefi line.
- Press Ctrl+X to boot into a working state.
- Open
/etc/default/gruband remove the bad flag from the template. - Run
sudo grub2-mkconfig -o /boot/grub2/grub.cfgto sync the menu. - Reboot normally to confirm the system stays stable.
Reboot before you debug. Half the time the symptom is gone.
When to use this vs alternatives
Use the GRUB menu edit when you need to test a parameter for a single boot cycle. Use /etc/default/grub and grub2-mkconfig when you want a permanent change that survives kernel updates. Use grubby when you prefer a single command that handles both the template and the boot configuration automatically. Stay on the manual GRUB method if you are troubleshooting a broken bootloader and need to see exactly what gets generated.
Fedora ships grubby as the official tool for managing kernel boot parameters. It reads the template, updates the boot entries, and handles UEFI versus BIOS differences automatically.
Here is how to apply the same change using the Fedora-native tool.
# Update the kernel command line for the default boot entry
sudo grubby --args="nouveau.modeset=0" --update-kernel=DEFAULT
# Verify the change took effect
grubby --default-kernel --args
# The output shows the active flags for the running kernel
# grubby modifies boot entries directly without touching the template
# Future grub2-mkconfig runs will not overwrite grubby changes
grubby modifies the boot entries directly without touching /etc/default/grub. It is faster and less error prone. It does not change the template, so future grub2-mkconfig runs will not overwrite it. Choose the tool that matches your workflow.