Unset menu_auto_hide is how to force grub2 boot-menu visibility on every boot for kernel-parameters

I totally get it that the Fedo 34 “clean bootup screen” is seen as cool.

It would be nicer though to have in /etc/defaults/grub

or wherever, a hint of how to FORCE visibility of the boot menu.

Not having the grub menu takes away a lot of power and capability away from the user. This, really, is not so cool. Tried to find sth. but gave up since so many other problems occurred.

It has got to be possible somehow, since it is supposed to - but will not always - show after a crash.

So the automatism is kinda faulty and users want the real thing: manual control over grub menu instead of some automatism-algorithm stuff like on a censored media platform. :grin:


sudo grub2-editenv - unset menu_auto_hide

thanks, gonna try it right away.

I am sure, that behaviour of hiding the crucial grub-boot-menu
will be intensely disliked by some, especially , as no quick hint textline
in /etc/defaults/grub is to be found to make up for such a grave loss.

it is difficult to hit ESC key at exactly the right moment during the boot-up and the time window for that is small.

Till you know that you can get it pressing ESC while booting. While hiding you save at least 3 to 5 seconds of boot time. Time is money :smiley:


point being, I would have known it, if a lead had been given in


for such hidden functionality.

Disabling the menu-hiding by running sudo grub2-editenv - unset menu_auto_hide, as well as a whole bunch of other questions which people may have about the hidden-grub-menu feature are documented in the FAQ which I wrote about this:

If someone knows a better place to put all the info, by all means feel free to copy this and use it in other Fedora documentation resources, as long as it is published under some FOSS license.


above FAQ was written in 2018 for Fedo29, this is Fedo34.

I am doubtful whether it still fully applies.

It does not mention “grubby” even though frequently, people ask: “What is grubby?”

In Fedo34 it is tricky to know whether HIDDEN is OFF since maybe a crash was detected.

So whether SHIFT or ESC works to force the menu visible is difficult to find out.


can manually be edited in case of doubt or dissatisfaction.

It still fully applies. If you see anything which is not correct please let me know, but to the best of my knowledge (and I’m the author of most of the involved code) everything in the FAQ is still correct.


sudo grub2-editenv - unset menu_auto_hide

note the undocumented " - " in there (kind of offputting :face_with_raised_eyebrow: ) .

OK I am in the process of finding out. thanks.

See grub2-editenv --help output for the documentation for the -.

1 Like

stupid me… I was relying on

man grub2-editenv

for documentation where the " - " is not being mentioned. Sorry… my mistake!

On my BIOS-based machine, the Shift-key seemingly will force visibility of grub2 menu, while the exact moment of keypress is more relaxed than with the ESC-key.

to change the preset, consider these bash lines:

sudo grub2-editenv - unset   menu_auto_hide
sudo grub2-editenv -   set   menu_auto_hide=1
sudo grub2-editenv    list
sudo grub2-editenv -  list
sudo grub2-editenv -- list

grubby is not being used for this functionality. Do not rely on the man page.

sudo dnf reinstall grub2-common  # to put stuff back to normal after mess-up
manpage leaves out the parameter  " - "  which is offputting.

       grub2-editenv                    --help
Usage: grub2-editenv [OPTION...] FILENAME COMMAND
                              If FILENAME is " - " then the default value 
                              /boot/grub2/grubenv is used.

Tool to edit the grub2 environment block.

  create                     Create a blank environment block file.
  incr  [NAME ...]           Increase value of integer variables.
  list                       List the current variables.
  set   [NAME=VALUE ...]     Set variables.
  unset [NAME ...]           Delete variables.

  -?, --help                 give this help list
      --usage                give a short usage message
  -v, --verbose              print verbose messages.
  -V, --version              print program version

There is no "delete" command; if you want to delete the whole environment
block,  use "rm /boot/grub2/grubenv"

Report bugs to    bug-grub@gnu.org

above, FILENAME is optional so it should read [FILENAME]


grub-editenv [-v | --verbose] [FILE]   <create | list | set NAME=VALUE | unset NAME>

else the " - " bashism boggles the mind. so it’s only documentation, but the above FAQ of 2018 seems to apply fully.

So these 2 tiny inconsistencies of documentation could lead to a little dissatisfaction.

AFAIK the FILENAME argument to grub2-editenv is mandatory, that is why the - needs to be there.

As for the manpage not documenting the -, yes that is less then ideal.

If someone feels up to writing a fix for that, then that would be great.

Ideally you would submit the fix upstream yourself, but if you commit
the changes with “git commit -as” and then do “git format-patch HEAD~”
and email me the generated patch file at hdegoede@redhat.com, then I
can submit it upstream for you if you want.

1 Like


Usage: grub2-editenv [OPTION...] FILENAME COMMAND

were correct, then

grub2-editenv  list # why no error ? does not conform to  --usage

Yes list is special in that it will use the default file if no filename is given, unlike the others. I thought this was documented behavior, but I cannot find this documented anywhere, so this is another thing to fix in both the manpage and the --help output.

1 Like

Do you have a link to the sourcecode? Mybe @lff proposes you a pull request. I think this is the spirit of opensourse to help with ready code/text :wink:

The official grub git repo is here: grub.git - GNU GRUB note grub still uses an email based workflow. There is a Fedora specific grub git repo here: GitHub - rhboot/grub2: Ongoing downstream work on grub2, including Fedora and RHEL. ***This is not upstream; please send code upstream first*** you can submit a pull-req there and then I can take care of submitting it upstream through the email workflow. Note that any grub patches need to have a Signed-of-by as part of their commit message, see: Developer Certificate Of Origin - eLinux.org . If you use git commit -s to commit your changes then git will add this to the commit-message automatically.