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
graphical.target
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.

4 Likes

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.

3 Likes

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.

2 Likes

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.

2 Likes

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_TIMEOUT=7
GRUB_DISTRIBUTOR="(sed 's, release .*,g’ /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT=“console”
GRUB_CMDLINE_LINUX=“rhgb quiets”
GRUB_DISABLE_RECOVERY=“true”
GRUB_ENABLE_BLSCFG=true

2 Likes

1925776 – GRUB_CMDLINE_LINUX is ignored when installing a new kernel

5 Likes

Thanks for filing the bug report for us.

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

2 Likes

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*
/usr/lib/kernel/install.d/20-grubby.install
/usr/lib/kernel/install.d/20-grub.install
/usr/lib/kernel/install.d/99-grub-mkconfig.install

A simple workaround:

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

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 (lrd.lvm.lv=). When I corrected that line to match the actual LVM group of the actual disk, it worked. …something to check.

1 Like

That can happen if you customize the lvm name after the initial install instead of during install. The next boot won’t work as I found out some time ago.

I instinctively try to steer clear of LVM, seemingly for 1+ good reasons…

1 Like

The workaround mentioned above can be optimized for Fedora 34:

sudo tee /etc/kernel/install.d/99-custom.install << "EOF"
#!/usr/bin/bash
grub2-mkconfig -o /boot/grub2/grub.cfg &> /dev/null
EOF
sudo chmod +x /etc/kernel/install.d/99-custom.install

Changes/UnifyGrubConfig - Fedora Project Wiki

If you use only online upgrades, then there’s an even simpler solution:

sudo tee /etc/profile.d/custom.sh << "EOF"
export RUN_MKCONFIG="true"
EOF
. /etc/profile

I’ve had to manually run grub2-mkconfig since sometime after upgrading to Fedora 32 (now on F33 but still same issue) after every kernel upgrade in order to get the system to boot to the new kernel as default. The grub menu (without the new grub.cfg being generated) will still boot to the old kernel, even on system upgrades (after upgrade to F33 system default booted to a F32 kernel).

It’s annoying but at least I know how to resolve.

You might check your /etc/default/grub file. I have
GRUB_DEFAULT=0
which should select the top/first kernel in your list as the default
after running grub2-mkconfig.

–Royboy626

This is a fascinating problem from my perspective.

If you are grub user, you expect GRUB_CMDLINE_LINUX from /etc/default/grub to be honored.

On the other hand, if you are a kernel-install user, you expect it to be managed the same way for all bootloaders handled by kernel-install.

In this case, there is a direct conflict between grub and systemd and I guess the maintainers have to decide how to handle this. To me, the great thing about the way that Fedora uses kernel-install is that it provides a consistent way boot loaders are managed. For example, you can uninstall grub, run bootctl install and have a working systemd-boot implementation with almost no hassle since kernel-install handles it in a mostly transparent way.

As side note, a simple workaround is to put the kernel options you want in /etc/kernel/cmdline. If that file is present it overrides /proc/cmdline

2 Likes

It does select the newly installed kernel but only after I run grub2-mkconfig. Other wise it continues to use the kernel that was last moved to the top of the list on last grub2-mkconfig run. I don’t really know what grub2-mkconfig does other than generate a new list of kernels you can choose to boot to. By default the top kernel in the generate list should be the new kernel. In case where it boot to older kernel that kernel seems to be in the middle of the list. On boot when it gives a list of kernels to boot I can use arrow keys to move through the list and select the kernel I want. I prefer that the system default to the newest kernel unless I move the selection to another one.

If you have the line
GRUB_DEFAULT=0
in /etc/default/grub then it might work.
On mine I have
GRUB_DEFAULT=saved
and it always selects the newest kernel after the kernel update. I even checked both my desktop that has only fedora installed and my laptop which dual boots win10 and both are the same.