Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Allow to interrupt scheduled FW update #27

Open
voxik opened this issue Oct 4, 2022 · 7 comments
Open

[RFE] Allow to interrupt scheduled FW update #27

voxik opened this issue Oct 4, 2022 · 7 comments

Comments

@voxik
Copy link

voxik commented Oct 4, 2022

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

  • attempted next time again
  • treated as the attempt never happened
  • was perceived as failed update.

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.

@hughsie
Copy link
Member

hughsie commented Oct 4, 2022

@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?

@superm1
Copy link
Member

superm1 commented Oct 4, 2022

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.

@hughsie
Copy link
Member

hughsie commented Oct 4, 2022

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.

@tomato42
Copy link

tomato42 commented Oct 4, 2022

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.

@hughsie
Copy link
Member

hughsie commented Oct 4, 2022

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.

@superm1
Copy link
Member

superm1 commented Oct 4, 2022

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.

@vathpela
Copy link
Contributor

vathpela commented Oct 4, 2022

@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:

  • on most devices where the keyboard isn't driven by the EC, the first time you call ReadKeyStrokeEx() will be the triggering event to enumerate USB, which can take some time
  • Early intel macs don't support EFI_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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants