You added a kernel parameter and it vanished after reboot
You typed nomodeset into your boot configuration, restarted the machine, and the flag disappeared. Or you spent twenty minutes tweaking /boot/grub2/grub.cfg only to watch dnf upgrade overwrite every change the moment a new kernel ships. GRUB2 on Fedora does not work like a traditional text file you edit and save. It works like a template system. If you edit the wrong file, your changes disappear. If you edit the right file but skip the regeneration step, the bootloader never sees them.
What is actually happening
GRUB2 separates configuration from execution. The file you modify lives in /etc/default/grub. It contains variables, defaults, and menu timing settings. The file that actually runs lives in /boot/grub2/grub.cfg on BIOS systems or /boot/efi/EFI/fedora/grub.cfg on UEFI systems. That generated file is built by a script that reads your variables, scans your disks for kernels, detects initramfs images, and writes a complete boot menu. Every time you run a major package update or explicitly trigger the generator, the script overwrites the generated file from scratch.
Direct edits to the generated file are temporary by design. Fedora treats /etc/ as the source of truth and /boot/ as the compiled output. The package manager and the bootloader generator both assume the generated file can be safely destroyed and rebuilt. This matches the broader Linux convention where configuration lives in /etc/ and package-managed or generated files live in /usr/ or /boot/. Edit /etc/. Never edit /boot/grub2/grub.cfg directly.
Think of /etc/default/grub as a recipe and /boot/grub2/grub.cfg as the baked cake. You can scrape frosting off the cake, but the next time the oven runs, it bakes a fresh one from the recipe. Change the recipe if you want the cake to taste different.
How to apply kernel parameters
Open the template file with your preferred editor. The GRUB_CMDLINE_LINUX variable holds the default parameters passed to every kernel entry. Add your flags inside the double quotes, separated by spaces. Do not break the quotes.
sudo nano /etc/default/grub
# WHY: Opens the template file that grub2-mkconfig reads during generation
# WHY: sudo is required because /etc/default/grub is owned by root
Locate the line starting with GRUB_CMDLINE_LINUX. It usually looks like this on a fresh Fedora install:
GRUB_CMDLINE_LINUX="rhgb quiet"
Append your parameters inside the existing quotes. If you need to disable kernel mode setting for older hardware, it becomes:
GRUB_CMDLINE_LINUX="rhgb quiet nomodeset"
Save the file and close the editor. The generator will not run automatically. You must trigger it manually.
The command differs slightly depending on your firmware type. Run the UEFI command first. If it fails, fall back to the BIOS command.
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
# WHY: Writes the new configuration to the UEFI boot partition
# WHY: The -o flag specifies the exact output path for UEFI systems
# WHY: UEFI systems mount the EFI System Partition under /boot/efi
If your system uses legacy BIOS, the output path changes. Run this instead:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# WHY: Writes the new configuration to the traditional BIOS boot directory
# WHY: BIOS systems do not use the EFI System Partition for GRUB files
# WHY: The generator scans /boot for vmlinuz and initramfs images
The generator will scan your /boot directory, list available kernels, and print a summary. You will see lines like Found linux image: /boot/vmlinuz-6.x.x-.... When it finishes, your changes are baked into the boot menu.
Run the generator immediately after editing. Delaying it leaves you with a mismatched template and a stale boot menu.
Verify it worked
Reboot the system. Once Fedora loads, check the active kernel command line. The /proc/cmdline file shows exactly what the kernel received at boot time.
cat /proc/cmdline
# WHY: Displays the actual parameters passed to the running kernel
# WHY: Confirms whether your new flag survived the boot process
# WHY: This file is virtual and reflects the current session only
Look for your parameter in the output. If it appears, GRUB2 applied it correctly. If you need to verify the generated menu without rebooting, inspect the output file you just wrote. Search for your parameter in the linux lines.
grep -A 2 "linux /vmlinuz" /boot/efi/EFI/fedora/grub.cfg | head -n 10
# WHY: Extracts the kernel boot lines from the generated configuration
# WHY: head limits the output so you can quickly spot your parameter
# WHY: Adjust the path to /boot/grub2/grub.cfg if you are on BIOS
Check /proc/cmdline first. Reading the actual kernel arguments beats guessing from a menu file.
Common pitfalls and error messages
Syntax errors in /etc/default/grub break the generator. If you accidentally remove a closing quote or add a space where a variable assignment expects one, grub2-mkconfig will abort. You will see an error like this:
/etc/default/grub: line 15: syntax error near unexpected token `quiet'
/etc/default/grub: line 15: `GRUB_CMDLINE_LINUX="rhgb quiet nomodeset'
The generator refuses to write a broken configuration. Open the file again, fix the quotes, and run the command once more.
Another common trap involves UEFI Secure Boot. If you modify GRUB2 on a Secure Boot enabled system and manually replace files in /boot/efi/EFI/fedora/, you might hit a boot loop or a secure boot violation screen. Fedora ships with signed GRUB binaries. Running grub2-mkconfig does not break the signature, but dropping unsigned custom scripts into the EFI directory will. Stick to the template and the generator.
Some users try to add parameters only to a specific kernel version instead of all versions. The GRUB_CMDLINE_LINUX variable applies globally. If you need per-kernel flags, you must use the grubby tool or edit the GRUB_CMDLINE_LINUX_DEFAULT variable. Global parameters are simpler for most desktop setups. Per-kernel parameters are necessary when testing a new driver on a single release.
Always run journalctl -xe after a boot change. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu systemd-boot muscle-memory style when something goes wrong.
Recovery procedure when the system refuses to boot
A botched parameter can leave you unable to mount the root filesystem or start the display manager. Follow these steps in order. A misstep here can lock you out of the system.
- Interrupt the boot countdown by pressing any key when the GRUB menu appears.
- Highlight the Fedora entry you want to boot and press
eto edit the configuration. - Find the line starting with
linux. Move the cursor to the end of that line. - Remove the problematic parameter or add
rd.breakto drop into an emergency shell. - Press
Ctrl+XorF10to boot with the modified parameters. - Once the system loads, open a terminal and run
sudo nano /etc/default/grubto fix the template. - Run
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfgto regenerate the menu. - Reboot normally to confirm the fix persists.
If the boot menu is gone, GRUB rescue is your friend, not your enemy. Use ls to find the partition with the grub directory, set the prefix and root, and load the normal module.
When to use this versus alternatives
Use grub2-mkconfig with /etc/default/grub when you want permanent kernel parameters that apply to every boot and survive system updates. Use grubby when you need to add or remove a single parameter without touching the template file or regenerating the entire menu. Use the GRUB2 interactive menu at boot when you are debugging a broken kernel and need a one-time flag that disappears after reboot. Stay on the template method if you only modify the bootloader occasionally and prefer a single source of truth.
Trust the package manager. Manual file edits drift, snapshots stay.