This is a tracking bug for Change: Hide the grub menu For more details, see: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu On systems with only a single OS installed, the grub menu does not offer any useful functionality, so we should hide it by default.
I see one commit in the grub2 package history relating to this - 1d36e193e6b6a712adaed44ce459af8c5bcfa5f0 , "Add support for setting boot_success / boot_indeterminate grubenv flags", but it seems a long way from 'testable' state right now overall.
(In reply to Adam Williamson from comment #1) > I see one commit in the grub2 package history relating to this - > 1d36e193e6b6a712adaed44ce459af8c5bcfa5f0 , "Add support for setting > boot_success / boot_indeterminate grubenv flags", but it seems a long way > from 'testable' state right now overall. Hmm, all the changes are in place if you do a fresh rawhide workstation install, or a workstation livecd install on a system without Windows then the grub menu should no longer show by default. E.g. anaconda has these 2 commits: https://github.com/rhinstaller/anaconda/commit/0d9e4dba9262a20dde3ff699818a60932124f35d https://github.com/rhinstaller/anaconda/commit/7c3cbf565f3e5e4c52d9e0b39061fb708774990a So any fresh rawhide workstation install should show "menu_auto_hide=1" in the output of "sudo grub2-editenv list" and the menu should be hidden. If the grubenv variable is not set, please let me know, in the mean time you can test by using: sudo grub2-editenv - set menu_auto_hide=1 Note you can even make the menu hide on a system with Windows if you want to because you e.g. almost never use Windows by doing: sudo grub2-editenv - set menu_auto_hide=2 The only remaining thing which I still need to do and which I hope to be able to start working on next week is write some docs about all this.
Ah, OK, I was expecting to see more 'enabling' changes in the grub2 commit log - I didn't realize the other bits were already in place. So let's mark this as MODIFIED then?
Yes marking this as modified is fine.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
FWIW, I think this may not be working correctly yet. Looking at recent openQA tests of Rawhide (the first F29 compose failed to boot past grub), the first boot of a fresh install *does* show a grub menu. I'm not 100% sure from the Change page whether that's expected or whether it's only expected that the *second* and subsequent boots will show no menu. But I also noticed some suspicious messages in the logs of a fresh Workstation live install while I was investigating https://bugzilla.redhat.com/show_bug.cgi?id=1618794 : Aug 17 10:44:57 localhost-live systemd[1510]: Starting Mark boot as successful... Aug 17 10:44:57 localhost-live pkexec[2396]: gdm: The value for the SHELL variable was not found the /etc/shells file [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/sbin/grub2-set-bootflag boot_success] Aug 17 10:44:57 localhost-live pkexec[2396]: The value for the SHELL variable was not found the /etc/shells file Aug 17 10:44:57 localhost-live pkexec[2396]: This incident has been reported. Aug 17 10:44:57 localhost-live systemd[1510]: grub-boot-success.service: Main process exited, code=exited, status=127/n/a Aug 17 10:44:57 localhost-live systemd[1510]: grub-boot-success.service: Failed with result 'exit-code'. Aug 17 10:44:57 localhost-live systemd[1510]: Failed to start Mark boot as successful. on the other hand, there are *also* these messages: Aug 17 10:42:36 localhost-live systemd[1510]: Started Mark boot as successful after the user session has run 2 minutes. Aug 17 10:46:11 localhost-live systemd[1510]: Stopped Mark boot as successful after the user session has run 2 minutes. Aug 17 10:46:17 localhost-live systemd[2427]: Started Mark boot as successful after the user session has run 2 minutes. so, I'm not totally sure of the status there :) I'll test this some more manually when I'm back from devconf.us.
Hi, (In reply to Adam Williamson from comment #6) > FWIW, I think this may not be working correctly yet. Looking at recent > openQA tests of Rawhide (the first F29 compose failed to boot past grub), > the first boot of a fresh install *does* show a grub menu. Is this a workstation install ? The hidden menu is only enabled for workstation installs. > I'm not 100% sure > from the Change page whether that's expected or whether it's only expected > that the *second* and subsequent boots will show no menu. The menu is expected to be hidden from the first boot on. Note that for subsequent boot the user needs to log in and stay logged in for at least 2 minutes for the boot to count as successful. I've patches pending to also mark the boot successful if the user reboots or shutsdown from the gnome system menu within that time (or directly from within gdm). > But I also noticed > some suspicious messages in the logs of a fresh Workstation live install > while I was investigating > https://bugzilla.redhat.com/show_bug.cgi?id=1618794 : > > Aug 17 10:44:57 localhost-live systemd[1510]: Starting Mark boot as > successful... > Aug 17 10:44:57 localhost-live pkexec[2396]: gdm: The value for the SHELL > variable was not found the /etc/shells file [USER=root] [TTY=unknown] > [CWD=/var/lib/gdm] [COMMAND=/usr/sbin/grub2-set-bootflag boot_success] > Aug 17 10:44:57 localhost-live pkexec[2396]: The value for the SHELL > variable was not found the /etc/shells file > Aug 17 10:44:57 localhost-live pkexec[2396]: This incident has been reported. > Aug 17 10:44:57 localhost-live systemd[1510]: grub-boot-success.service: > Main process exited, code=exited, status=127/n/a > Aug 17 10:44:57 localhost-live systemd[1510]: grub-boot-success.service: > Failed with result 'exit-code'. > Aug 17 10:44:57 localhost-live systemd[1510]: Failed to start Mark boot as > successful. I did not think about the gdm greeter session also executing services from /lib/systemd/user. So I need to add a ConditionUser=!@system to the timer file for this. I will do this asap, otherwise these errors are harmless. > on the other hand, there are *also* these messages: > > Aug 17 10:42:36 localhost-live systemd[1510]: Started Mark boot as > successful after the user session has run 2 minutes. > Aug 17 10:46:11 localhost-live systemd[1510]: Stopped Mark boot as > successful after the user session has run 2 minutes. > Aug 17 10:46:17 localhost-live systemd[2427]: Started Mark boot as > successful after the user session has run 2 minutes. Those are for the normal logged in user and are expected and should have actually set the flag (unlike the services executed by the gdm systemd --user, which fail by accident, which is actually a good thing). Note you can check the status of the autohide stuff by running: sudo grub2-editenv list If anaconda has enabled the autohide stuff then you should see "menu_auto_hide=1" in there, note that if you run this directly after boot (so before your login session has lasted 2 minutes then you will always see "boot_success=0", since that gets set by grub itself, and if you then run "sudo grub2-editenv list" again after 2 minutes it will be 1. So you can only check the boot_success value just before rebooting/shutdown, not after reboot as grub clears it itself.
Thanks for the notes! I'm not 100% sure whether I checked a Workstation install for my previous comment, it may not have been. Looking at the video of the last passed Rawhide Workstation install test, it does look like the grub menu was skipped, so that's good. I'll still double check things manually when I get back from this conference.
Today is the '100% code complete deadline' Change Checkpoint[1], meaning that Fedora 29 Changes must now be code complete. All the code required to enable to the new change should now be finished. If your Change is code complete, please update the status of this tracker back to "ON_QA". The change does not have to be fully tested by this deadline. We have now reached the Beta freeze. If your Change is not code complete, you need to request a Freeze Exception[2] or invoke the contingency plan. [1] https://fedoraproject.org/wiki/Changes/Policy#Beta_deadline.2Faccepted_changes_100.25_complete [2] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
So, on further manual testing, this does appear to be working as intended more or less. However, one unfortunate consequence has been reported on devel@: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DMY3J2PNSG4YO7CLZVKIGKG2OY3U7UCN/ someone running into the known bug with dbus failing to start - https://bugzilla.redhat.com/show_bug.cgi?id=1623781 - reported: "There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it." That sounds to me like this situation is considered a 'successful boot' by the mechanism that decides whether the boot succeeded or not (and thus whether to show the boot menu on the *next* boot), but it's not successful so far as the user is concerned...
Hi, (In reply to Adam Williamson from comment #6) > Aug 17 10:44:57 localhost-live systemd[1510]: Starting Mark boot as > successful... > Aug 17 10:44:57 localhost-live pkexec[2396]: gdm: The value for the SHELL > variable was not found the /etc/shells file [USER=root] [TTY=unknown] > [CWD=/var/lib/gdm] [COMMAND=/usr/sbin/grub2-set-bootflag boot_success] > Aug 17 10:44:57 localhost-live pkexec[2396]: The value for the SHELL > variable was not found the /etc/shells file > Aug 17 10:44:57 localhost-live pkexec[2396]: This incident has been reported. > Aug 17 10:44:57 localhost-live systemd[1510]: grub-boot-success.service: > Main process exited, code=exited, status=127/n/a > Aug 17 10:44:57 localhost-live systemd[1510]: grub-boot-success.service: > Failed with result 'exit-code'. > Aug 17 10:44:57 localhost-live systemd[1510]: Failed to start Mark boot as > successful. These errors should be gone once a new grub2 build is done which includes this pull-req: https://github.com/rhboot/grub2/pull/31 This pull-req adds: "ConditionUser=!@system" to the timer file as discussed before. (In reply to Adam Williamson from comment #10) > So, on further manual testing, this does appear to be working as intended > more or less. However, one unfortunate consequence has been reported on > devel@: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > message/DMY3J2PNSG4YO7CLZVKIGKG2OY3U7UCN/ > > someone running into the known bug with dbus failing to start - > https://bugzilla.redhat.com/show_bug.cgi?id=1623781 - reported: "There is no > root acoount on a default F29 installation. Also, you can't see the boot > menu and I haven't been able to trigger it." > > That sounds to me like this situation is considered a 'successful boot' by > the mechanism that decides whether the boot succeeded or not (and thus > whether to show the boot menu on the *next* boot), but it's not successful > so far as the user is concerned... So I guess that this is caused by the system-wide gnome-initial-setup session starting a systemd --user session and that lasting more then 2 minutes. I assume that this special session runs as a system user, so the "ConditionUser=!@system" should help there too. Note this will only happen if the user just lets the broken system-wide gnome-initial-setup screen sit there for 2 minutes. If the user reboots/shutdown before then the menu should show. For now the reboot/shutdown can be done from either the gnome system-menu (this worked for me when I hit this myself on a recent fresh install) or by pressing "ctrl + alt + F4" and then "ctrl + alt + del" or just pressing the power button for 4 seconds for a forced power-off. I plan to make the gnome system-menu route set the boot-success flag though, to avoid false-positive failure detects if users e.g. directly shutdown / reboot from gdm if they realize they don't want to use the computer after all. But that still leaves "ctrl + alt + F4" and then "ctrl + alt + del" or just pressing the power button for 4 seconds. And there are 3 ways to get the menu to show even if it is hidden: a) Keeping shift pressed during boot, note you typically need to press it a bit after the vendor logo / bios post shows otherwise it might not register b) Pressing Esc during boot (needs to be done at the right time, so press it repeatedly during boot) c) Pressing F8 during boot (needs to be done at the right time, so press it repeatedly during boot) Which reminds me that I really need to make some time *before* the beta to document all this. Regards, Hans
grub2-2.02-58.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c8b9386151
grub2-2.02-58.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c8b9386151
(In reply to Hans de Goede from comment #11) > And there are 3 ways to get the menu to show even if it is hidden: > > a) Keeping shift pressed during boot, note you typically need to > press it a bit after the vendor logo / bios post shows otherwise > it might not register > > b) Pressing Esc during boot (needs to be done at the right time, > so press it repeatedly during boot) > > c) Pressing F8 during boot (needs to be done at the right time, > so press it repeatedly during boot) > > Which reminds me that I really need to make some time *before* the beta to > document all this. > > Regards, > > Hans The problem with these is that none of them allows you to get the menu to show allows you to do it versus the /boot/grub2/custom.cfg file. IMHO it should be a requirement that there needs to be a method to do this via this file.
(In reply to Bill Gianopoulos from comment #14) > The problem with these is that none of them allows you to get the menu to > show allows you to do it versus the /boot/grub2/custom.cfg file. IMHO it > should be a requirement that there needs to be a method to do this via this > file. If you can edit that file, then that means you've a working root shell, in that case you can simply do: grub2-editenv - unset menu_auto_hide To permanently disable the hiding of the menu
Sounds like exactly what I was looking for but the format of this file is it contains what look like lines to define values for shell variables. What I was looking for was an autohide_menus variable that would be defined as true that I could set the opposite in this file by saying autohide_menus=false in this file. exactly what is the exact format of the line I need to add to this file to effect this change?
You should not edit the grub environment yourself, instead run the grub2-editenv - unset menu_auto_hide Command to change the environment, this is also what anaconda is doing during a workstation install.
Created attachment 1484069 [details] Menu entry which IMHO should result in grub menu display My understanding of this bug is that the intention is to NOT display the grub mnu if the only menu choices are current fedora and the 2 back kernels saved and any rescue image. SO exactly why is the presence of this entry NOT sufficient to force the menu display.
Oops wrong file posted.
Created attachment 1484070 [details] Menu entry which IMHO should result in grub menu display
I am not trying to be obstructive here. My opinion is that all of this new code needs to be under a new grub option called autohide_menu that by default is set to true and can be overridden by setting autohide_menu=false in custom.cfg. Also even if set to true if timeout=-1 th e menu needs to be displayed. it makes zero sense to have an infinite wait time to select a choice form a hidden menu.
The menu will be unhidden when /etc/grub.d/30_os-prober detects another OS. What it does is inject this bit of code into grub.cfg then: # 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 So you could out that in /boot/grub2/custom.cfgif you want to disable the feature through a custom.cfg file. Note I do not believe that installing memtest86 should result in unhiding the menu.
We have chosen to make the feature controllable through the grub2nv instead of through the configfiles so that you do not need to re-generate the grub.cfg file when en- or dis-abling it. Note with the BLS work also being done for F29: https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault We no longer need to rewrite the grub.cfg on every kernel update and in the future we may want to make it entirely static.
Also running a simple command to disable this is much easier for most users then editing a file and then running grub2-mkconfig. And note that you can never overwrite settings like this from custom.cfg custom.cfg gets inserted at the end of grub.cfg and grub.cfg is parsed in order, so we've already decided to hide the menu by the time custom.cfg comes into play. The feature could be controlled through /etc/default/grub, but as said we prefer to use the environment to control this. As for the -1 timeout, the feature works by overriding the timeout setting, so that works fine.
(In reply to Hans de Goede from comment #17) > You should not edit the grub environment yourself, instead run the > > grub2-editenv - unset menu_auto_hide > > Command to change the environment, this is also what anaconda is doing > during a workstation install. Trying to do that results in this error: sudo grub2-editenv unset menu_auto_hide Unknown command `menu_auto_hide'. Usage: grub2-editenv [OPTION...] FILENAME COMMAND Try 'grub2-editenv --help' or 'grub2-editenv --usage' for more information. [wag@maine-rawhide ~]$ sudo grub2-editenv unset menu_auto_hide Unknown command `menu_auto_hide'. Usage: grub2-editenv [OPTION...] FILENAME COMMAND Try 'grub2-editenv --help' or 'grub2-editenv --usage' for more information.
You're missing the " - " between "grub2-editenv" and "unset" you need to run: "grub2-editenv - unset menu_auto_hide" You can check the result by doing: "grub2-editenv - list" Before and after the command.
F29 host, F29 UEFI(EDK2) guest using virt-manager, default Workstation install: F8, ESC, SHIFT do not unhide the menu at boot like the feature page says $ sudo grub2-editenv - unset menu_auto_hide This causes the menu to show up for one boot and then it goes back to being hidden. And in a separate instance with clean Silverblue install which hangs on multipath in the middle of boot, again I can't get a grub menu with keyboard short cuts and since I can't successfully boot, I can't change the grubenv, which then gets reset by something.
Reboot 5 times in a row from the gdm menu (no logging in), as fast as I can. Every time, grub menu. Then poweroff the VM. Power on the VM, and now no grub menu. The grubenv each time is the same, when I inspect it from outside the VM (kpartx on the backing LV, mount the ESP, hexdump grubenv). .boot_success=0.boot_indeterminate=0. Pretty goofy. I guess I'm gonna look next at BIOS VM and see if that behaves any differently.
BIOS VM: ESC, F8, SHIFT do nothing, no grub menu. And even though the boot fails halfway and I have to force quit, the following boot still has no grub menu.
comment 29 (BIOS test case) f28s.local chris ~ sudo hexdump -C /mnt/test/grub2/grubenv 00000000 23 20 47 52 55 42 20 45 6e 76 69 72 6f 6e 6d 65 |# GRUB Environme| 00000010 6e 74 20 42 6c 6f 63 6b 0a 62 6f 6f 74 5f 73 75 |nt Block.boot_su| 00000020 63 63 65 73 73 3d 30 0a 23 23 23 23 23 23 23 23 |ccess=0.########| 00000030 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 |################|
Chris, please open a new bug against grub2 component for this, with me in the Cc. Also please attach the /etc/grub2-efi.cfg file (for the EFI case) or the /etc/grub2.cfg file. Note my first hunch here is that qemu is directly loading the kernel + initrd itself instead of using grub. That would explain why it works on reboot, but not power-off + on and also why the menu is hidden despite the boot_success variable being 0.
grub2-2.02-58.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
I think the GRUB boot menu should be hidden as long as GRUB remains unaware of hi-DPI screens. Pausing boot to display unreadable text doesn't do anything but slow the boot process. I personally have three OSes on my ThinkPad, and simply use the EFI boot selector (F12 key at boot) to select which OS to boot.
That doesn't help you pick a kernel or edit boot parameters if you need to. (And it's not an option for BIOS installs).
I can't pick my kernel now, as the GRUB text is too tiny to read. I can type in boot parameters of course, I just can't read what I type. In the bigger picture, I wonder if there's any plans to make GRUB hi-DPI aware, so that it could scale by some integer value. Perhaps Anaconda could write something to /boot/grub2/grub.cfg, so at first post-install boot, the GRUB boot menu is scaled properly from there on out. I'm not a programmer, just thinking of ways to improve the user experience.
(In reply to Phil Baker from comment #35) > I can't pick my kernel now, as the GRUB text is too tiny to read. I can type > in boot parameters of course, I just can't read what I type. > > In the bigger picture, I wonder if there's any plans to make GRUB hi-DPI > aware, so that it could scale by some integer value. grub uses the textmode as provides by the EFI firmware. The same text too tiny problem happens when: 1) The shim wants to show an error message 2) mok (the shim's keymanager) tries to interact with you for you to prove you are physically sitting behind the keyboard after running "mokutil --disable-validation" So we consider this tiny text a firmware problem. We are reaching out to vendors about this and we've (very recently) filed a bug with the generic opensource base most UEFI firmwares use: https://bugzilla.tianocore.org/show_bug.cgi?id=1199 Note you can force the grub menu to be hidden even though you've multiple OS-es installed by doing: sudo grub2-editenv - set menu_auto_hide=2 When set to 2 (instead of 1) grub will ignore the presence of other OS-es. Note you will still get the grub menu after having booted another OS *through grub*, as booting through grub clears the boot-success flag and that other OS will not set it again.
"the grub menu does not offer any useful functionality" Really? Choosing previous kernel, editing a boot commands are not "useful". Why have they been maintained for decades then? Someone apart from me must be finding them useful. Dumbing down the user is not useful either. If I wanted to be running MS Windows, I would be. Does having memtest86+ count as a dualboot system which makes grub menu visible again? thx.