I checked my grub file, /etc/default/grub
and it has GRUB_TIMEOUT=5
This setting didn’t affect my older system; no menu shows up upon booting, nor any delay.
I did try setting it to 0, but there are clear few seconds on the bootloader, displaying a message on which kernel is booted.
I’ve heard if there are three installed kernels, then the bootloader is automatically activated?
I have had this happen to me on Silverblue after an update. Sometimes I see it with Workstation, but very rarely. Normally it will happen if there is a problem with something from last boot. You may want to review your boot journal, but without knowing what is causing issues (if there are any), it will take you some reading through to find it/them. It is generally harmless in almost all cases. There is a log viewer in Gnome utilities, and from the command line it is journalctl -b -1 to view the previous boot. You may want to pipe it to another command such as grep. So maybe a command such as journalctl -b -1 | grep "grub".
It by no means is harmful, just a nuisance.
This is what I got:
Sep 11 06:02:38 fedora systemd[8161]: grub-boot-success.timer - Mark boot as successful after the user session has run 2 minutes was skipped because of an unmet condition check (ConditionUser=!@system).
Sep 11 06:02:52 fedora systemd[8777]: Started grub-boot-success.timer - Mark boot as successful after the user session has run 2 minutes.
Sep 11 06:03:02 fedora systemd[1]: grub2-systemd-integration.service - Grub2 systemctl reboot --boot-loader-menu=… support was skipped because of an unmet condition check (ConditionPathExists=/run/systemd/reboot-to-boot-loader-menu).
Sep 11 06:03:03 fedora systemd[8777]: Stopped grub-boot-success.timer - Mark boot as successful after the user session has run 2 minutes.
I did notice there was some Nvidia driver issues after the recent update, and I reinstalled the driver. The system is working with the grub issue.
I believe that any time the system is dual booting and has a non-fedora OS also installed the grub menu is supposed to automatically appear.
Also any time there is an unclean shutdown or failed boot the grub menu is supposed to appear on the next boot.
How are you shutting down the system? Is it using either the shutdown link on the menu from the top right corner of the system to shutdown or reboot? or using sudo shutdown -h now or sudo reboot? Any of those should give a clean shutdown that the system will recognize at the next boot. Any other way may result in what the system sees as an unclean shutdown or failed boot and result in the grub menu appearing.
You can see the current settings in the grub environment with sudo grub2-editenv - list to verify that the menu_auto_hide=1 attribute is properly set. The attribute boot-success=1 would show a properly completed last boot.
Once again I ask How do you do the shutdown?. A clean shutdown should not force the grub menu to appear, but a forced shutdown or failed boot should cause it to appear.
The only thing in that list to differ from mine is that yours shows boot_indeterminate=2 and mine shows boot_indeterminate=0. While I don’t know the effect of that attribute it potentially could be related.
What are the contents of /etc/default/grub?
That file is one of the configuration files used to define the grub behavior at boot.
I just noticed this in the commands you ran.
That is not a valid command (or rather is an error in the file written to) for grub.
If that error is not fixed then you will see problems in the future since kernel updates will never be seen when booting. The file under /boot/efi is supposed to be a pointer to the grub.cfg file at /boot/grub2/grub.cfg and for normal systems it never gets modified after initial install. Overwriting it means future system updates to kernels and grub will never be properly seen without manual action. It can remain as-is if you intend to manually repeat that same command with every system upgrade that affects grub or kernels.
The fix for that particular error is to do the following.
sudo rm /boot/grub2/grub.cfg
sudo rm /boot/efi/EFI/fedora/grub.cfg
sudo dnf reinstall grub2-common grub2-efi\* which should properly configure both grub.cfg files for normal booting.
I am not sure where you might have heard that, but it is not true. The number of kernels is not related to whether the grub menu displays or is hidden.
Hi Jeff,
Thanks for the instructions. Very helpful.
Now I got:
boot_success=1
boot_indeterminate=0
menu_auto_hide=1
The grub menu still shows up. I checked the red hat website:
which suggests adding this to the grub file: GRUB_TIMEOUT_STYLE=hidden
Then I ran
sudo grub2-mkconfig -o /etc/grub2.cfg
The menu is auto hidden.
There are a lot of different and confusing variations and suggestions as to how to update grub, including the problematic one you pointed out.
If you need a tutorial read the docs.
This tells users how to manage grub.
It explicitly tells users that /boot/grub2/grub.cfg is to be used for all fedora systems, and also notes that /etc/grub2.cfg and /etc/grub2-efi.cfg are both links to that file. The two links in /etc have been present for many years and have always pointed to the proper file for updating. Even in the past when efi systems used the file under /boot/efi and mbr systems used the file under /boot/grub2 the link pointed to the proper file. The change occurred about 3 years ago so all systems now use the file under /boot/grub2 regardless of the boot mode used.
Silverblue after an update. Sometimes I see it with Workstation, but very rarely. Normally it will happen if there is a problem with something from last boot. You may want to review your boot journal, but without knowing what is causing issues (if there are any), it will take you some reading through to find it/them. It is generally harmless in almost all cases. There is a log viewer in Gnome utilities, and from the command line it is 