23
edits
Gaia/System/Updates: Difference between revisions
Jump to navigation
Jump to search
→Open questions
Marshall law (talk | contribs) |
Marshall law (talk | contribs) |
||
| Line 101: | Line 101: | ||
* What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?) | * What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?) | ||
** (marshall_law) | |||
** For user prompting sequence / rules, see the requirements laid out by cjones in these bugs: | |||
*** https://bugzilla.mozilla.org/show_bug.cgi?id=740720 | |||
*** https://bugzilla.mozilla.org/show_bug.cgi?id=740722 | |||
** Currently, the plan is to automatically download any Gecko updates to /data/local/updates. IIRC we are working w/ carriers to make sure this isn't billable data. | |||
** After an update is downloaded, the update is staged in /system/b2g/updated, and the b2g process is cleanly shutdown (and then restarted by the system) | |||
** Soon after bootup of the new b2g process, the updater runs again, copying the staged updates into /system/b2g to make them live. | |||
** <b>Note</b>: The updater process will re-mount /system as read-write when it starts, and back to read-only when it exits. This will happen for both staging, and copying the staged files in place. In the event of a failure remounting /system as read-only (before exit), the device will be restarted, allowing the system to mount /system as read-only. See https://bugzilla.mozilla.org/show_bug.cgi?id=764683 for more details | |||
** (/marshall_law) | |||
** How different is process from Gonk updates? | ** How different is process from Gonk updates? | ||
* How often should we check for Gecko update? | * How often should we check for Gecko update? | ||
** Every 18 weeks, according to CLee's etherpad outline... | ** Every 18 weeks, according to CLee's etherpad outline... | ||
*** (sicking) This sounds too rare given that we ship Gecko updates every 6 weeks which always contain security updates. Usually we count on security researchers being able to reverse engineer those updates and create exploits for older versions of Gecko. | *** (sicking) This sounds too rare given that we ship Gecko updates every 6 weeks which always contain security updates. Usually we count on security researchers being able to reverse engineer those updates and create exploits for older versions of Gecko. | ||
*** (marshall_law) IIRC the reasoning had to do with risk mitigation from carriers (it was a compromise of some kind?) | |||
* Can we confirm that there will be a back-up instance of Gecko in event of failed updates? If so, what will sequence of it's application be? | * Can we confirm that there will be a back-up instance of Gecko in event of failed updates? If so, what will sequence of it's application be? | ||
** (marshall_law) That is the plan for stage 2 of the update mechanism. See [https://bugzilla.mozilla.org/show_bug.cgi?id=715816#c1 the list of stages proposed by cjones] | |||
* Does being on 3G/Edge affect when we check for Gecko updates? | * Does being on 3G/Edge affect when we check for Gecko updates? | ||
** Should not, since updates will be free OTA via Carrier's private APN. | ** Should not, since updates will be free OTA via Carrier's private APN. | ||
* What—if anything—should we tell the user when a Gecko updated is detected? Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available? | * What—if anything—should we tell the user when a Gecko updated is detected? Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available? | ||
** Download update and apply silently in background, same as Gonk process? Might be too intrusive for these more frequent (18 weeks) Gecko updates? | ** Download update and apply silently in background, same as Gonk process? Might be too intrusive for these more frequent (18 weeks) Gecko updates? | ||
** (marshall_law) see above | |||
* Do we have the technical ability to download the update in the background and only notify the user once the new version is available? | * Do we have the technical ability to download the update in the background and only notify the user once the new version is available? | ||
** (marshall_law) yes | |||
* Should we do anything special if the phone has been turned off for a few days and is then started? | * Should we do anything special if the phone has been turned off for a few days and is then started? | ||
** (marshall_law) IIRC, the existing Gecko update internals already have the logic for knowing how long it's been since the last update check. They should be able to detect this and do an update check as soon as the phone is on. We should confirm this, though. | |||
* Do we need to have a mechanism for pushing extra-critical updates? | * Do we need to have a mechanism for pushing extra-critical updates? | ||
* Should we inform users about how big updates will be before downloading them? Do we have the ability to tell before doing the actual download? | * Should we inform users about how big updates will be before downloading them? Do we have the ability to tell before doing the actual download? | ||
** (marshall_law) We do have the ability -- the update MAR format specifies update size. We don't currently have plans to inform about the size of an update, but feel free to chime in on any of the bugs listed on how that might work. | |||
* Do we require the user to plug in the phone if battery is below X %? | * Do we require the user to plug in the phone if battery is below X %? | ||
** (sicking) See answer for Gonk | ** (sicking) See answer for Gonk | ||
* What prompts do we present to user? | * What prompts do we present to user? | ||
** (marshall_law) see above | |||
* Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no... | * Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no... | ||
** (marshall_law) we do in Phase 2, which I don't think we plan to have for v1. Will need to check w/ cjones to verify though | |||
* What is time to install? Several minutes? | * What is time to install? Several minutes? | ||
** (marshall_law) It all depends on the size of the update, the speed of the internal disk, the device hardware.. :) We might want to profile this in a few configurations.. | |||
* Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example. | * Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example. | ||
** (marshall_law) yes, see the bugs about prompting | |||
* How many device reboots are required in the process? | * How many device reboots are required in the process? | ||
** (marshall_law) for Gecko, there shouldn't be any. only a process restart is required. the only time a restart might happen is if /system is somehow left in read-write after the updater is finished, as a fail safe. | |||
* Do we provide link to changelog so user can review update details before installing? | * Do we provide link to changelog so user can review update details before installing? | ||
** (marshall_law) good question! not currently.. I've opened a new bug for this here: https://bugzilla.mozilla.org/show_bug.cgi?id=781233 | |||
** (sicking) See answer for Gonk | ** (sicking) See answer for Gonk | ||
* How large are these updates? | * How large are these updates? | ||
** (marshall_law) they are binary diff'd, so potentially not "huge", but again this all depends on how big the update is. definitely smaller than if we were downloading fresh binaries. | |||
* Do we check for available device storage before downloading? If insufficient, how do we mitigate? | * Do we check for available device storage before downloading? If insufficient, how do we mitigate? | ||
* If the user powers down the device while an update is silently downloading in background, can we resume download later on? | * If the user powers down the device while an update is silently downloading in background, can we resume download later on? | ||