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
- 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
- write really good instructions on how devs can unbork from bad updates (download gecko and make install-gecko, approximately)
- 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.
All dependencies are blocking. Tracking bugs don't block. Marked the deps.
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.
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.