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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)

RESOLVED DUPLICATE of bug 1079244
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- affected

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)
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)
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)
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)
Flags: needinfo?(gchang)
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)
This is a bug. Time zone should be preserved unless it's technically not possible.
Flags: needinfo?(firefoxos-ux-bugzilla)
Gerry, is this bug valid for 2.2 or 3.0?
Flags: needinfo?(gchang)
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)
Flags: needinfo?(jelee)
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?
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)
Eric, Thanks for look into this.
Flags: needinfo?(kli)
Assignee: nobody → etsai
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.
After checking, bug 1079244 solves this issue.
Depends on: 1079244
Bug 1079244 already fixed "cancel while uncompressing", set this bug to resolved duplicate
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][COM=OTA]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: