Closed Bug 715816 (b2g-gecko-updates) Opened 12 years ago Closed 11 years ago

Tracking: Automatic updates of b2g "userspace" (gecko, built-in apps and dependencies; not third-party apps)

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:-)

RESOLVED FIXED
blocking-basecamp -

People

(Reporter: cjones, Assigned: marshall)

References

Details

(Whiteboard: [B2GTest:Blocker])

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.
No longer blocks: b2g-demo-phone
Whiteboard: [b2g:blocking-]
All dependencies are blocking. Tracking bugs don't block. Marked the deps.
blocking-basecamp: --- → -
Whiteboard: [b2g:blocking-]
Summary: Tracking: Automatic updates of b2g "userspace" (gecko and dependencies) → Tracking: Automatic updates of b2g "userspace" (gecko and dependencies, not apps)
Alias: b2g-gecko-updates
Assignee: nobody → marshall
Depends on: 777514
Depends on: 777939
Whiteboard: [B2GTest:Blocker]
Depends on: 776742
No longer blocks: basecamp-security
Depends on: 781233
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: 784079
Depends on: 785124
Depends on: 785138
Depends on: 776789
Depends on: 787398
Depends on: 787578
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: 795051
Depends on: 798948
Depends on: 801742
Depends on: 801987
Depends on: 802016
Claiming victory.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.