The HTML UI layer will update on its own schedule. We hope to never need to update the kernel, but that will be a separate mechanism. This bug covers updating what approximately corresponds to firefox-bin. The general approach will be to ship with a validated-good version of gecko, and on first update copy a new gecko to a second partition (or wherever). If a problem in the upgrade is detected, it's ditched and we fall back on the known-good version. The update is totally UI-agnostic, although the update protocol will include notifying the UI. Filing in Boot2Gecko because much of this will live in the b2g/ chrome package, and will cross several boundaries.
Forgot to post this. Current plan is to roll this out in three stages First stage - existing updater code downloads and verifies updates - existing update applier applies updates on top of /system/b2g, while b2g is running. This is somewhat dangerous, and not correct. - restart b2g process - pray - write really good instructions on how devs can unbork from bad updates (download gecko and make install-gecko, approximately) Second stage - have separate /system/b2g (live) and /system/b2g-staging directories - after downloading verifying update, remount /system to rw (don't assume /system is rw) - use existing update applier to update b2g-staging - atomic-swap b2g and b2g-staging. This is dangerous and incorrect, but less so than in stage 1. - restart b2g process Third stage --- the above, except - verify *extracted* files in b2g-staging. We don't have that infrastructure yet. - pause/freeze/kill b2g process so that it can't see an inconsistent state in /system/b2g. Restart after atomic swap. - use watchdog process to detect bad updates, fall back on previous version if something goes wrong
This plan is focused on updates to gecko files. We need to figure out what needs to be done for other userspace libs. Ideally we won't try to update them except in emergencies, using the system update mechanism.
Depends on: 737368
Depends on: 737598
Depends on: 737601
All dependencies are blocking. Tracking bugs don't block. Marked the deps.
blocking-basecamp: --- → -
Depends on: 764683
Depends on: 764684
Summary: Tracking: Automatic updates of b2g "userspace" (gecko and dependencies) → Tracking: Automatic updates of b2g "userspace" (gecko and dependencies, not apps)
Assignee: nobody → marshall
Depends on: 778079
Depends on: b2g-fota-updates
No longer depends on: b2g-fota-updates
I just want to clarify what we are targeting for v1 out of the separate stages here. No bugs have been filed for Stage 3, but stage 1 is already covered, and remount / staging support (from stage 2) is as well. Is atomic-swap from Stage 2 (or anything from Stage 3) important for v1? They don't currently have filed bugs..
The current updater code tries very hard to do an atomic swap, probably as well as we'll be able to do for v1.
Depends on: 787436
Does this summary "(b2g-gecko-updates) Tracking: Automatic updates of b2g "userspace" (gecko and dependencies, not apps)" need to be updated to include system apps? Final decision from a month ago was that system apps would be updated as part of Gecko.
Summary: Tracking: Automatic updates of b2g "userspace" (gecko and dependencies, not apps) → Tracking: Automatic updates of b2g "userspace" (gecko, built-in apps and dependencies; not third-party apps)
Depends on: 802423
Depends on: 802487
Depends on: 821192
Depends on: 821194
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 1155851
You need to log in before you can comment on or make changes to this bug.