GRUB_CMDLINE_LINUX is ignored when installing a new kernel

Noticed this on three installations of Workstation. The ‘options’ portion of a newly created entry in /boot/loader/entries/ seems to be created from the kernel command line and not /etc/default/grub. If I am correct, it seems /etc/default/grub should be sourced instead.
Steps to reproduce:
1 - From grub boot menu, edit the entry. I added ‘3’ for text mode; removed
‘plymouth.enable=0 quiet’
2- systemctl get-default
Note: found “3” on the kernel commandline, which overrides the default unit.
3 - Upgrade kernel. Examine the newly created entry in /boot/loader/entries
In the above case, ‘3’ is present; ‘plymouth.enable=0 quiet’ is absent.

Expected result is GRUB_CMDLINE_LINUX in /etc/default/grub should be sourced to create entries in /boot/loader/entries/ instead of the kernel command line.
If my observations are correct, and this behavior as expected, what is the merit of ignoring /etc/default/grub? Is a bug report in order?
Thanks in advance for any response. - Ron H.


This has been happening to me for the past few months, as well. I have just been living with it.

I think it straightened out one time when I regenerated grub.cfg, manually. But then it went back the next time dnf upgraded the kernel.


Once you make the change in /etc/default/grub then you need to run grub2-mkconfig to put those changes into the grub.cfg file (and whatever else it does). The grub.cfg file is what is used during boot, not /etc/default/grub.

During a kernel update, once the new kernel is installed, grub2-mkconfig is invoked to update grub.cfg as well as whatever else is needed to support the new kernel. Whatever changes you made in /etc/default/grub would be sourced then even if you had not run grub2-mkconfig previously.

/etc/default/grub is not ignored. It is used when the kernel is updated or when you manually update the grub.cfg file to build the new configuration.


Thank you JV. /etc/default/grub is not being touched during the entire process I describe, therefore a manual run of grub2-mkconfig is not needed. grub.cfg sources the files in /boot/loader/entries, which are created during a kernel install. The edits I describe are when using ‘e’ to make temporary changes to an entry in the grub boot menu ([Shift] key at boot if your’s does not display).
Tim C. - Thanks for your input.


I am running Sliverblue 33.

Just got update notification that includes kernel-5.10.12, so before reboot to apply the updates, I manually edit /etc/default/grub.

Result: After update and new kernel is booted, /etc/default/grub are ignored when creating the new boot loader entries under /boot/loader/entries

# cat ostree-3-fedora.conf
title Fedora 33.20210205.0 (Silverblue) (ostree:0)
version 3
options root=UUID=fb968c76-784e-40ad-8246-975bcb46a7f1 rootflags=subvol=sbrootfs ostree=/ostree/boot.1/fedora/3cb4e18187b8e5056450a0f6b8a301fb31db5bc961aa94caaeb8bd74d83a1a10/0
linux /ostree/fedora-3cb4e18187b8e5056450a0f6b8a301fb31db5bc961aa94caaeb8bd74d83a1a10/vmlinuz-5.10.12-200.fc33.x86_64
initrd /ostree/fedora-3cb4e18187b8e5056450a0f6b8a301fb31db5bc961aa94caaeb8bd74d83a1a10/initramfs-5.10.12-200.fc33.x86_64.img

Note: I manually edited “quiet” to “quiets” before the update as a testing.

[root@amdf entries]# cat /etc/default/grub
GRUB_DISTRIBUTOR="(sed 's, release .*,g’ /etc/system-release)"
GRUB_CMDLINE_LINUX=“rhgb quiets”


1925776 – GRUB_CMDLINE_LINUX is ignored when installing a new kernel


Thanks for filing the bug report for us.

I commented there to indicate I also got the same issue.


Tracking down the issue…

On one hand, we have grub2-mkconfig which relies on /etc/grub.d that can properly process GRUB_CMDLINE_LINUX.

On the other hand:

> rpm -q --scripts kernel-core | grep -A 1 -e posttrans
posttrans scriptlet (using /bin/sh):
/bin/kernel-install add 5.10.12-200.fc33.x86_64 /lib/modules/5.10.12-200.fc33.x86_64/vmlinuz || exit $?

That relies on /usr/lib/kernel/install.d which writes configs to /boot/loader/entries fetching the boot options from /proc/cmdline and ignoring GRUB_CMDLINE_LINUX:

> grep -w -r -e [.]\\s\*/etc/default/grub -e /etc/grub.d -e GRUB_CMDLINE_LINUX -e /proc/cmdline /usr/lib/kernel/install.d 
/usr/lib/kernel/install.d/20-grub.install:[[ -f /etc/default/grub ]] && . /etc/default/grub
/usr/lib/kernel/install.d/20-grub.install:                read -r -d '' -a line < /proc/cmdline
/usr/lib/kernel/install.d/99-grub-mkconfig.install:[[ -f /etc/default/grub ]] && . /etc/default/grub
/usr/lib/kernel/install.d/90-loaderentry.install:    read -r -d '' -a line < /proc/cmdline
/usr/lib/kernel/install.d/50-dracut.install:            read -r -d '' -a line < /proc/cmdline
/usr/lib/kernel/install.d/51-dracut-rescue.install:    read -r -d '' -a line < /proc/cmdline

So, the root cause appears to be missing support for GRUB_CMDLINE_LINUX in those scripts:

> find /usr/lib/kernel/install.d/*grub*

A simple workaround:

sudo tee /etc/kernel/install.d/99-custom.install << "EOF"
if [ "${GRUB_CMD}" != "add" ]
then exit 0
if [ -d "/sys/firmware/efi" ]
then GRUB_CONF="/etc/grub2-efi.cfg"
else GRUB_CONF="/etc/grub2.cfg"
grub2-mkconfig -o "${GRUB_CONF}"
sudo chmod +x /etc/kernel/install.d/99-custom.install

I wish they fix this soon.

As tested, doing upgrade from Fedora 33 to Fedora 34, the /etc/default/grub is being ignored also.

1 Like

This might sound crazy but I had this problem and it turned out that the GRUB_CMD_LINUX line in /etc/default/grub had the wrong LVM group name ( When I corrected that line to match the actual LVM group of the actual disk, it worked. …something to check.

1 Like