Using grubby to set GRUB_DEFAULT

My understanding is that grubby exists to make changing boot parameters a little more robust, but from what I can tell a user still needs to manually edit /etc/default/grub to change GRUB_DEFAULT= from 0 to saved, then run the following:

grub2-mkconfig -o /etc/grub2.cfg
grub2-mkconfig -o /etc/grub2-efi.cfg
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/efi/EFI/[os_flavor]/grub.cfg

Is that correct? This seems like a great step to automate. Are there any plans to allow grubby to assist with setting the GRUB_DEFAULT parameter?

I don’t know the answer to your question. But …

The files /etc/grub2.cfg /etc/grub2-efi.cfg are symbolic links to /boot/grub2/grub.cfg

The file /boot/efi/EFI/[os_flavor]/grub.cfg should never be modified by grub2-mkconfig

So only run

grub2-mkconfig -o /boot/grub2/grub.cfg
2 Likes

NO

the first 3 lines are redundant since the first 2 files are both symlinks to the file in line 3.

The 4th line breaks automatic updates for future kernel upgrades and would need to be repaired in order for kernel updates to be automatically seen with the next boot.

Using grubby takes care of all that is needed (including the changes to /etc/default/grub) and most frequently only applies when making changes to kernel boot options. Grubby makes changes to /boot/grub2/grub.cfg, /etc/kernel/cmdline, /etc/default/grub, the applicable .conf file(s) in /boot/loader/entries/, and does other updates as well.

I have tested to confirm the changes I already noted above.

The default for GRUB_DEFAULT in /etc/default/grub appears to be saved as seen with a clean install of fedora.

1 Like

@vekruse @computersavvy thank you both for your guidance. It appears the vendor I’m working with did suggest running the above commands which has broken automatic updates.
What would be the best way to fix the /boot/efi/EFI/[os_flavor]/grub.cfg file to revert the changes made by the above?

The following should fix that properly

  1. sudo rm /boot/grub2/grub.cfg /boot/efi/EFI/fedora/grub.cfg
  2. sudo dnf reinstall grub2-common
  3. Wait a minute or so then reboot

Following step 3 then run sudo cat /boot/efi/EFI/fedora/grub.cfg and the result should look something like this

$ sudo cat /boot/efi/EFI/fedora/grub.cfg
search --no-floppy --fs-uuid --set=dev c4eb1f4d-eaab-4b8a-a952-302402d8844d
set prefix=($dev)/grub2

export $prefix
configfile $prefix/grub.cfg

The trailing UUID at the end of the first line would be specific to your own system.

1 Like

I wonder how different Fedora is from other flavors of Enterprise Linux. The server I’m working on is CloudLinux 8, which is built from the folks maintaining AlmaLinux and that’s where I got the previous commands. There are other references I found on various forums from flavors such as Rocky that specifically recommend running the grub2-mkconfig command against the grub.cfg file located under /boot/efi/EFI/[os_flavor]/.
Where did you learn that that breaks future kernel upgrades?
Thank you!

I can’t check what is correct on Rocky or Alma or Centos or RHEL. But for several years /boot/efi/EFI/fedora/grub.cfg has been a stub configuration and the real and only grub configuration is at /boot/grub2/grub.cfg. For many more years, the symbolic link /etc/grub2-efi.cfg on UEFI systems has been referring to the grub.cfg file that should be updated. and on non-UEFI systems the symbolic link /etc/grub2.cfg refers to the grub.cfg file for those systems.

Also, some forum posts and Youtubers are misguided or provide outdated advice.

PS: I wouldn’t be surprised if RHEL 8 and look-alikes would be the same as Fedora.

That’s clearly misguided as there is only one grub file all the others are symlinks, even on rhel8.

To set the kernel to boot I use the this sudo grubby --set-default-index=0 and use sudo grubby --info=ALL to see all the boot entries.

And /boot/efi/EFI/fedora/grub.cfg is … what?

@icyhoipolloi

About version 34 - 36 fedora changed uefi boot. (I don’t remember exactly which version did the change)

Prior to that change the uefi boot used that file to actually perform the grub configs.
When that change was made fedora switched to using the same grub.cfg file located at /boot/grub2/grub.cfg for both legacy boot and for uefi boot. The change made the file located at /boot/efi/EFI/fedora/grub.cfg a pointer file that contains only 4 lines and redirects the boot loader to read the other file

Thus, for several release versions now /boot/grub2/grub.cfg is the only real grub.cfg file and system updates (such as kernel updates) only modify that file, so the one located at /boot/efi/EFI/fedora/grub.cfg is never altered by the system once installed. If a user changes it then it breaks future kernel updates and forces manual use of grub2-mkconfig to update the file.

1 Like

My question was about RHEL 8 or clones.

So is this the file to run grub2-mkconfig -o against? (at least for Fedora)

As an attempt to fix this, if I move these files:

mv /etc/grub2.cfg	/etc/grub2.cfg.bak
mv /etc/grub2-efi.cfg	/etc/grub2-efi.cfg.bak
mv /boot/grub2/grub.cfg	/boot/grub2/grub.cfg.bak
mv /boot/efi/EFI/[os_flavor]/grub.cfg	/boot/efi/EFI/[os_flavor]/grub.cfg.bak

and then run dnf reinstall grub2*, grub2-common will be reinstalled and will run grub2-mkconfig as part of its scriptlet:

root@fedora:~# rpm -q --scripts grub2-common
posttrans scriptlet (using /bin/sh):
set -eu

EFI_HOME=/boot/efi/EFI/fedora
GRUB_HOME=/boot/grub2
ESP_PATH=/boot/efi

if ! mountpoint -q ${ESP_PATH}; then
    exit 0 # no ESP mounted, nothing to do
fi

if test ! -f ${EFI_HOME}/grub.cfg; then
    # there's no config in ESP, create one
    grub2-mkconfig -o ${EFI_HOME}/grub.cfg
fi
...

So as long as the grub2-common package is reinstalled is there any reason for me to run grub2-mkconfig -o against any files manually?

Do not touch /etc/grub-efi.cfg or /etc/grub2.cfg.
Both of those are symlinks that point to /boot/grub2/grub.cfg and should not be changed.

$ ls -l /etc/grub2*
lrwxrwxrwx. 1 root root 22 May 28 19:00 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root 22 May 28 19:00 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg

The fix when /boot/efi/EFI/fedora/grub.cfg has been overwritten is 3 steps.

  1. sudo rm /boot/grub2/grub.cfg /boot/efi/EFI/fedora/grub.cfg
  2. sudo dnf reinstall grub2-common
  3. wait about 1 minute then reboot.

Not required. It does that for you. But only if the original files are removed first.

I’m getting there. It looks like /etc/grub2.cfg only exists if grub2-pc is installed, which as I understand it is only required if you’re trying to boot from legacy:

# ls -l /etc/grub2*
lrwxrwxrwx 1 root root 22 Apr 22 12:02 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx 1 root root 31 Apr 22 12:01 /etc/grub2-efi.cfg -> ../boot/efi/EFI/centos/grub.cfg
# dnf remove grub2-pc -y
Removed:
  grub2-pc-2:2.02-156.el8.cloudlinux.1.x86_64

# ls -l /etc/grub2*
lrwxrwxrwx 1 root root 31 Apr 22 12:01 /etc/grub2-efi.cfg -> ../boot/efi/EFI/centos/grub.cfg

Another anomaly is that on AlmaLinux 8, the scriptlet responsible for re-creating /boot/efi/EFI/[os_flavor]/grub.cfg is part of the grub2-efi-x64 package, not the grub2-common package as it is in Fedora:

# rpm -q --scripts grub2-common
# rpm -q --scripts grub2-efi-x64
posttrans scriptlet (using /bin/sh):
if [ -d /sys/firmware/efi ] && [ ! -f /boot/efi/EFI/centos/grub.cfg ]; then
    grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg || :
fi
if [ -d /sys/firmware/efi -a -f /boot/grub2/grubenv -a ! -L /boot/grub2/grubenv ]; then
    mv /boot/grub2/grubenv /boot/efi/EFI/centos/grubenv
    pushd /boot/grub2
    ln -s ../efi/EFI/centos/grubenv grubenv
    popd
fi