On Thu, May 31, 2018 at 6:53 AM Hans de Goede <hdego...@redhat.com> wrote:
> Hi, > > On 31-05-18 12:36, Stephen Gallagher wrote: > > > > On Thu, May 31, 2018 at 6:24 AM Hans de Goede <hdego...@redhat.com > <mailto:hdego...@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.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TTA5ZZUVJAHJB5Z46MAEHX27JRXBXXJT/
