Hi,
On 31-05-18 13:59, Stephen Gallagher wrote:
On Thu, May 31, 2018 at 6:53 AM Hans de Goede <hdegoede@xxxxxxxxxx <mailto:hdegoede@xxxxxxxxxx>> wrote:
Hi,
On 31-05-18 12:36, Stephen Gallagher wrote:
>
> On Thu, May 31, 2018 at 6:24 AM Hans de Goede <hdegoede@xxxxxxxxxx <mailto:hdegoede@xxxxxxxxxx> <mailto:hdegoede@xxxxxxxxxx <mailto:hdegoede@xxxxxxxxxx>>> 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.
Ok.
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?
Up to multiple seconds (depending on the hardware and amount of attached
USB devices).
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?
For F29 the plan is to just hide it (unless a previous boot failed)
the not checking for a keypress is the full fastboot implementation
which is best left for Fedora 30 I think. Once we get the full
fastboot implementation then the 1 second delay indeed will be
removed.
So for F29, single OS install we get:
1) grub menu hidden by default with a 1 second timeout to press ESC
or F8 to show it
2) grub menu shown with 5 sec timeout after a failed boot
And for F30, single OS install we get:
1) grub menu not shown, 0 second timeout, no way to get to the menu
2) grub menu shown with 5 sec timeout after a failed boot
Originally I was planning on doing the failed-boot detect only
for F30, but I agree it makes sense to have it for F29 and this
will also give us some field testing of this while we still have
a fallback in the form of the 1 sec wait for ESC / F8.
This is all defaults btw and can all be overridden by the user if
so desired.
Regards,
Hans
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx/message/BYAFAPUNZRN4JUNFIIOX4E7XELMJJ7QD/
