Open voxik opened 1 year ago
@superm1 like I don't know how easy it is to capture non-blocking keyboard input in the loader. Maybe we could do something like "Press a key to skip the firmware update...5...4...3...2...1..." etc. @vathpela any pointers?
I'm wondering how common this situation really is. We prompt to reboot. So someone would have to actively say no to the reboot prompt, keep using their machine and then shut it down.
I guess we have no data to show one way or another though.
Another way we could help this situation is to "cancel" the update when someone issues a shutdown instead of a reboot.
Does BS know how long the machine has been powered on for? i.e. a counter not cleared by restart but cleared by a cold boot. Then we could check that the counter > 1 minute or something.
The problem is that the firmware update process itself is quite... rough? There is no screen output, the computer restarts, or seems to do nothing for a long time...
Knowing that the update started, and that it can take minutes would make it much less stressful.
that the firmware update process itself is quite... rough
Ya, newer builds of firmware from Lenovo all use the bootspash with a progress spinner, but if you're upgrading from something factory-installed-in-2015 then it's pretty raw and geeky.
Another thing we could do is show a nice pretty fwupd logo in fwupd-efi for 10 or 20 seconds.
Then if someone is in this situation of "rough" old firmware to start they will know what is about to happen.
@superm1 like I don't know how easy it is to capture non-blocking keyboard input in the loader. Maybe we could do something like "Press a key to skip the firmware update...5...4...3...2...1..." etc. @vathpela any pointers?
It's pretty simple to do with EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.ReadKeyStrokeEx()
and a CreateEvent()
/SetTimer()
/WaitForEvent()
, with a few caveats:
ReadKeyStrokeEx()
will be the triggering event to enumerate USB, which can take some timeEFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL
. I don't think we care about them, but if we do, we'll have to fall back to EFI_SIMPLE_TEXT_INPUT_PROTOCOL
, which does not meaningfully support using ctrl
There's some basic timer code here https://github.com/rhboot/grub2/blob/fedora-38/grub-core/kern/arm/efi/init.c#L53 and some basic keyboard code here: https://github.com/rhboot/shim/blob/main/lib/console.c#L31
It seems that some users might schedule FW update, but instead of restarting an applying the update immediately, they just switch of their computer off. Next time, powering on the computer, it might be surprising it does not boot normally and it might even lead to corrupted HW and further issues.
Therefore I wonder, would there be possibility to interrupt the FW update? Of course the question is what would it mean precisely. E.g. if it was
Just FTR, this idea came just after discussion on some random ML. I would never schedule FW updates and switched off computer instead of applying the updates immediately, but other apparently do.