Hi,
On 29-06-18 17:46, Nicolas Mailhot wrote:
Le 2018-05-31 14:25, Hans de Goede a écrit :
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.
Do please make sure that:
So there are 2 components involved in fastboot, the firmware and grub,
if the firmware sucks, there is nothing we can do (and that already
is the case today). E.g. I've several machines where if I enable
the fastboot option to not scan the USB bus, the USB bus will not
be scanned once grub makes a text input EFI protocol "read key stroke"
call.
IOW if I enable that fastboot option today, with grub as is in F28,
I cannot navigate the grub menu, I believe that the firmware should
delay scanning the USB bus until the first "read key stroke" call in
this case, but in practice on some systems it seems to simply not
bother to scan the USB bus *ever* if this fastboot option is
enabled.
Now let me answer your questions, with the caveat that my answers
are only valid assuming sane firmware, if things are already broken
with F28 grub, we cannot fix them.
1. there is a way to demand the next boot will provide the full boot menu with working display and keyboard
sudo grub2-set-bootflag menu_show_once
Will do this in (F29+) the plan is to also change the "Restart"
option in the GNOME3 shutdown modal dialog to "Boot Options"
when alt is pressed and then set that flag before rebooting if
the user clicks the "Restart/Boot Options" button with alt
pressed (similar to how the poweroff icon which gives this menu
changes to a pause icon / suspend button when alt is pressed).
This will all be documented in the the admin guide and a link
to that part of the admin guide will be added to the
release-notes.
2. there is a way to demand all boots provide the full boot menu with working display and keyboard
This requires running this command *once* :
sudo grub2-editenv - unset menu_auto_hide
This will also be documented in the admin guide.
3. those ways are easily discoverable by laymen (typically, a notice on the default gfx or cli login screen)
See above for the plans to make this discoverable, we believe
these are advanced options which should not be visible by
default.
4. you check every single bit needed to use them works before declaring a boot successful
A boot is declared successful if a user logs in (or the
user session starts if autologin is enabled) and the
usersession lasts at least 2 minutes. So even if login
works, but then for some reason the session crashes immediately
afterwards, that still will NOT count as a boot success.
This means that we may get a few false positive failed
boot detects (e.g. reboot/shutdown within 2 minutes), but
the side-effects of that are harmless (menu shown for 5
seconds) where as a false-negative could be troublesome.
IOW I agree with you that we need to be careful when we
mark a boot successful.
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/5T6A7DXYD4RO7BZPENTUQ6SYSF6YXAVW/
