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.
- 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.
- 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.
- 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.
- 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