Closed
Bug 1136329
Opened 9 years ago
Closed 9 years ago
[System][OTA] Restarting a cancelled OTA causes the device to force a reboot, does not apply the update.
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)
RESOLVED
DUPLICATE
of bug 1079244
People
(Reporter: Marty, Assigned: etsai)
References
()
Details
(Whiteboard: [3.0-Daily-Testing])
Attachments
(2 files)
Description: If the user cancels an OTA during the 'Uncompressing...' stage, then selects and restarts the update from the Notification Tray, the device will become temporarily unresponsive at the homescreen. Next, the notification tray will appear, and the OTA will appear to be in the 'Uncompressing...' state again. After a few seconds, the device will reboot itself, without notifying the user. After the reboot, the device will still be on the previous build, they will often be presented with an error banner at the bottom of the screen that reads "There was an error downloading the updates," and they will have to wait for the device to reacquire an update from the server before they can download and apply the update properly. Repro Steps: 1) Update a Flame to 20150223103044 2) Connect to a WiFi or Data network. 3) Check for System Updates 4) Pull down the Notification Tray and begin downloading the OTA. 5) After the OTA has finished downloading, and reads 'Uncompressing,' cancel the OTA from the Notification Tray. 6) Restart the OTA from the Notification Tray. Actual: The device goes temporarily unresponsive, then forcibly reboots without notifying the user. The OTA is not applied. Expected: The device remains responsive, properly decompresses the OTA download, prompts the user to install the update, and then properly applies the update during a reboot. Environmental Variables: Device: Flame 3.0 (319MB)(Full Flash) Build ID: 20150223103044 Gaia: 288bf1c58ef9ccecd68508978a0141ee71974681 Gecko: 9b077c6f3d02 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 Repro frequency: 5/5 See attached: logcat, video (URL)
Reporter | ||
Comment 1•9 years ago
|
||
This issue DOES occur on Flame 2.2, 2.1, and 2.0 Builds The device reboots after restarting a cancelled OTA. The update is not applied. Environmental Variables: Device: Flame 2.2 (319MB)(Full Flash) Build ID: 20150223002503 Gaia: 389542b71c89253c0d176d3b0bfb54e275c19bf1 Gecko: 9fd3441c8983 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Environmental Variables: Device: Flame 2.1 (319MB)(Full Flash) Build ID: 20150223001204 Gaia: 88c44f2243a5ca1683587aca9faf29023974b96c Gecko: efd5205ec813 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.0 (319MB)(Full Flash) Build ID: 20150223000222 Gaia: 366aaa19ac474dc58b79d62a91cff41756ae9dfe Gecko: 611444d72a92 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 32.0 (2.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 2•9 years ago
|
||
NI on component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(gchang)
Is the data kept after the restart? I think this might be a data loss blocker if that is the case.
Flags: needinfo?(mshuman)
Reporter | ||
Comment 4•9 years ago
|
||
Almost all data was kept, with the exception of the Time Zone, which reverted from Los Angeles back to New York. This caused my Calendar events to shift forward 3 hours.
Flags: needinfo?(mshuman) → needinfo?(nhirata.bugzilla)
Thanks Marty! I think the timezone not keeping is a separate bug and needs to be accounted for. Could you file that bug please?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(mshuman)
Updated•9 years ago
|
Flags: needinfo?(gchang)
Reporter | ||
Comment 6•9 years ago
|
||
I have been unable to reproduce the Time Zone change since reporting it before, after at least 10 attempts. If I see it again, I will be sure to write it up.
Flags: needinfo?(mshuman)
Ok, so it just sounds like bad UX that it's rebooting after cancelling. I'll ping fxosux to ask them if they think they might be able to do something for it for v3.
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 8•9 years ago
|
||
This is a bug. Time zone should be preserved unless it's technically not possible.
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 10•9 years ago
|
||
Hi Kai-Zhen, I can also recreate this issue. User may hit this issue if cancelling the update during uncompressing phase and then upgrade again.
Flags: needinfo?(gchang) → needinfo?(kli)
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(jelee)
Assignee | ||
Comment 11•9 years ago
|
||
If we don't want to auto decompress, it's similar with the bug 1081117. We can add a preference to prevent auto decompress. NI UX team Jenny. Jenny, please comment if we add a preference or provide an option for user to select auto decompress or not?
Comment 12•9 years ago
|
||
Hi Eric, Please see attached spec p.9, it is specified that once "uncompressing" starts, user can no longer tap on the notification and cancel the action. Thanks!
Flags: needinfo?(jelee)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → etsai
Assignee | ||
Comment 14•9 years ago
|
||
I tested 2.0, 2.1 and 2.2, even if click cancel, I think decompress still goes on. From my log: > I/GeckoUpdater( 1703): Progress [ =================== ] > I/Gecko ( 206): UpdatePrompt: Pausing download > I/GeckoUpdater( 1703): Progress [ ==================== ] > I/GeckoUpdater( 1680): Progress [ =============================================== ] From log :Marty attaached: > 02-24 13:37:34.757: E/GonkAutoMounter(2847): Error mounting /system as read-only: Device or resource busy > 02-24 13:37:34.757: E/GonkAutoMounter(2847): Could not remount /system as read-only, forcing a system reboot. I guess root cause of reboot is one updater is decompressing and writing to disk. When you want to resume OTA, the update process will create another updater. The second updater get error then force reboot. I will follow https://bugzilla.mozilla.org/show_bug.cgi?id=1136329#c12 make user can't cancel decompress.
Assignee | ||
Comment 15•9 years ago
|
||
After checking, bug 1079244 solves this issue.
Assignee | ||
Comment 16•9 years ago
|
||
Bug 1079244 already fixed "cancel while uncompressing", set this bug to resolved duplicate
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][COM=OTA]
You need to log in
before you can comment on or make changes to this bug.
Description
•