search

GrapheneOS / platform_packages_apps_Updater

Automatic background updater for modern Android. See https://github.com/GrapheneOS/script/blob/13/generate_metadata.py for the server metadata generation tool.
https://seamlessupdate.app/
MIT License
33 stars 40 forks source link

Defer system updates until substantial battery power is available? #82

Closed de0u closed 11 months ago

de0u commented 11 months ago

Here are some user reports indicating that a device running out of power during a system update can result in file-system corruption, sometimes seemingly severe:

This situation is presumably rare, but it seems to be troublesome for affected users. Might it be helpful to either require a 50% charge before applying an update, or add a user-settable threshold?

thestinger commented 11 months ago

Running out of power during an update is safe. If the update isn't correctly installed, it will be rolled back.

There's already a toggle to disable automatic updates when battery is low. What's wrong with the existing toggle? There's also one to only update which the device is charging.

thestinger commented 11 months ago

Each of these threads is about power running out during the initial boot of a new version. Most of these issues appear to be a kernel bug and the situation is resolved by automatic rollback. It also appears f2fs does not always work as intended if power is cut during the late boot process. That's not particularly surprising since we know that f2fs is quite buggy. There's not really anything that can be done about this. We can enable the non-low battery requirement for the update client by default, but the issue is not caused by power loss during installation of the update but rather during first boot of the new version. If someone has an update fully installed, then runs out of power later, they'll potentially trigger these firmware or f2fs bugs when they try to boot it without hooking it up to fast charging. What can be possibly do about that? We know about these firmware bugs and they're reported upstream. We know f2fs is buggy but there's little hope of a short term solution to that.

d2ro commented 5 months ago

We had the same "Your device is corrupt. It can’t be trusted and may not work properly" issue after a power loss. It seemed that a "merging" process had been interrupted. We managed to continue it with fastboot snapshot-update merge while in fastbootd (not fastboot, mind the "d") mode.

See our blog post or cross-post on the GrapheneOS forum: https://discuss.grapheneos.org/d/12814

de0u commented 2 months ago

It also appears f2fs does not always work as intended if power is cut during the late boot process. That's not particularly surprising since we know that f2fs is quite buggy. There's not really anything that can be done about this.

I have been thinking about this off and on, and I wonder if maybe there is something that could be done.

Would it be possible for the end of the kernel's boot sequence to refuse to hand off to user space, or for the beginning of user space to refuse to proceed, if the battery is low? For example, could something near the beginning of user space check the battery level and, if it's too low, just display a low-battery icon and stall in some low-power state? Or display a low-battery icon for some seconds and power the device off?

My trigger for commenting on this closed issue is a recent report on the discussion forum: https://discuss.grapheneos.org/d/14823-stuck-in-reboot-loop-flashing-the-lock-screen-after-app-optimizations

It may be rare, but I think some users are being nailed by a power outage somewhere during the update process. I can easily imagine it might be f2fs's fault, but it would be nice if there were a way to protect some users.

thestinger commented 2 months ago

The main issue appears to be a firmware one, not a software one. The speculation about it here was likely wrong.