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.
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.
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:
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
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.
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’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).
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.
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
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.