No fallback if the system update process fails at any point
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical System Image |
Confirmed
|
Low
|
Unassigned | ||
Ubuntu system image |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
For someone to install a system update, all of the following need to be true:
(A) The phone needs to start up completely.
(B) Unity needs to be usable (e.g. bug 1436538).
(C) The networking stack needs to let Ubuntu check for updates.
(D) If System Settings is not in the Launcher, the Apps scope needs to not crash.
(E) System Settings needs to launch without crashing.
(F) The System Settings "Updates" screen needs to open without crashing.
(G) The system-image update system itself needs to work properly.
This is a long and brittle chain. If *any one* of these steps breaks, the phone is no longer updateable. And at worst -- if A, B, or C fails -- the phone is effectively bricked.
This is not a theoretical problem. On Ubuntu for PC, crasher bugs in update-manager often persist for a long time in the list of most common errors, because the updates that fix them can't themselves be installed until a nearby geek cracks out a terminal to use apt-get. That's not so practical on a phone.
Therefore, there should be a fallback path for installing system image updates in emergency situations. This path may not avoid all of the requirements listed above, but it should avoid as many as practical.
no longer affects: | system-image (Ubuntu) |
Changed in ubuntu-system-image: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
description: | updated |
Changed in canonical-devices-system-image: | |
assignee: | nobody → John McAleely (john.mcaleely) |
importance: | Undecided → Low |
status: | New → Confirmed |
Changed in canonical-devices-system-image: | |
assignee: | John McAleely (john.mcaleely) → nobody |
I agree it's critical to think about. At the lowest level of the above stack, a shell + system-image-cli + networking should be able to update the device, but it's probably not super easy for the average user. I can imagine a small script that would use adb to shell in and run the update.
If the device's network is down, then I can also imagine that script could optionally push all the data and keyring files obtained in some other way (e.g. via a web site visited on the host). Once the device is attached to USB, this script would push the files into the right place and invoke s-i-cli over adb.