On Thu, May 31, 2018 at 6:53 AM Hans de Goede <hdegoede@redhat.com> wrote:

On 31-05-18 12:36, Stephen Gallagher wrote:
> On Thu, May 31, 2018 at 6:24 AM Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> wrote:
>     Hi All,
>     I'm working on improving the Fedora boot experience, with the
>     end goal being a user pressing the on button and then going
>     to the graphical login manager without him seeing any
>     text messages / menus filled with technical jargon.
>     IIRC we used to hide the grub-menu by default on single
>     OS installs, but we seemed to have stopped doing that,
>     for new Fedora 29 installs I would like us to start
>     hiding the menu by default on single OS installs again,
>     see:
>     https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
>     The goal if this email is to:
>     1) Give people an advance warning about the plan to change
>     this so we can discuss this early on
>     2) See if anyone knows why we stopped doing this, I think
>     we may simply have stopped doing this to simplify to bootconfig
>     code in anaconda and because we did not always identify the
>     single OS case correctly, but I wonder if there were other
>     reasons?
> I think part of the reason is that non-technical people might not know how to recover if a kernel update had a regression leaving their system unbootable. At least with the boot config screen there, it offers them something to try.
> I would be concerned if we drop this without instituting an alternative way to (perhaps automatically) revert to an older kernel if boot failed to reach some sensible systemd target.

Revert to the older kernel, or show the menu?

Showing the menu provides the user a way to revert to the older kernel, so it's fine with me.

I also have working on fastboot support on my TODO, which means not
checking for a keypress in grub *at all* because that check will
cause EFI firmware to scan all USB busses for a keyboard which can
be quite slow. This indeed involves setting a "boot_success"
grub environment variable, which grubs clears at boot and if
not re-set the next boot grub will not fastboot.

Interesting. How slow are we talking about? Measured in milliseconds or seconds?
The fastboot stuff is more of a Fedora 30 then 29 thing, but I
guess I could bring the bits which signal a successful boot
forwards to 29 and use that to decide between showing the menu
with our default 5 second timeout and hiding it and waiting 1 sec.

If we are hiding it and have no detected keyboard, what's the value of waiting one second anyway? Shouldn't we skip the wait entirely?
The plan for fastboot was to show the menu, not to auto fallback
as there can be many reasons why the boot has failed.

This will basically get us back the F28 behavior of showing the
menu but only after a failed boot, I think that is a good
solution, do you agree?

Yeah, that would be fine with me.