Grub2-mkconfig isn't applying settings in /etc/default/grub

Here is my /etc/default/grub file again. Is there something that needs to be in these configs to cause the grub menu to appear from every reboot, from when I’m logged in to Rocky or not? I have secure boot set in the bios. The rocky mount is booting /boot/efi/EFI/rocky/shimx64.efi

GRUB_TIMEOUT=120
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=UUID=7101ee64-4965-41e1-9e3e-affad0737949 rd.lvm.lv=rockydesk/root rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
sudo grub2-editenv - unset menu_auto_hide

Will expose the menu on reboot. Please note that the dash preceding “unset” is bracketed by spaces.
You could have pressed F8 or SHIFT to expose the menu prior to unsetting it.
How did you set up your sudo environment. Typically you have to issue a password to proceed with the initial command though subsequent sudo invokations within the next 5 minutes do not.

The user I use sudo with is a member of the wheel group and in sudo config I remove the need for a password for that group. I either run commands directly with sudo or I do sudo -i interaction to become root and then run commands. I’ll try this command gub2-editenv and then reboot.

Yes, thank you. the grub2-editenv unset command did the trick. Now I’m presented the grub menu on all reboots.

The (note Simple configuration) in info grub2-mkconfig describes the content of /etc/default/grub

Apparently GRUB_TIMEOUT_STYLE=menu should make the menu visible, although the menu_auto_hide can rule. There might be a way to avoid that, according to /etc/grub.d/12_menu_auto_hide

What adds the menu_auto_hide to grubenv? The grub2-mkconfig can supposedly update the grubenv, so is it the “culprit”?

It’s a default if no other OS is detected. I guess that RH does not consider win11 another OS or win11 is on a separate disk.
On my vm that I installed RL9 there is a Fedora39 install on the same .vdi that I retained. The rl9 install did not see f39 because that instance uses the btrfs for the root fs but osprober fails to read that so I had no boot menu. I fixed it with the same command I furnished here.

os prober doesn’t detect Win11 in my setup, but I didn’t inquire as to why. I’ve suspected it’s because of the location of the efi partition on the separate disk I have it installed on. It’s a middle partition on the drive. What’s interesting is that I also put in 2 additional ssd drives that were previously booting windows. The efi partition was still on those disks as the first partition. Windows wasn’t even installed on them and os prober detected both and added them to the grub menu, two “window boot loader” items for each disk. I of course deleted the partitions. But for Win11 I added a custom.cfg file to the /boot/grub2 directory:

menuentry "Windows 11 Enterprise" {
            insmod part_gpt
            insmod fat
            insmod chain
            search --no-floppy --fs-uuid --set=root FEBA-7422
            chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Yes, the /etc/grub.d/30_os-prober may add to grub.cfg:

# Other OS found, undo autohiding of menu unless menu_auto_hide=2
if [ "\${orig_timeout_style}" -a "\${menu_auto_hide}" != "2" ]; then
  set timeout_style=\${orig_timeout_style}
  set timeout=\${orig_timeout}
fi

I do use the custom.cfg too. One could override the timeout_style in it, because 41_custom is the last section in grub.cfg.


Being default is not the crucial question. “Who writes the default to grubenv?” is.

Observation: Setting/changing GRUB_TIMEOUT_STYLE in /etc/default/grub does not make grub2-mkconfig to touch the menu_auto_hide.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.