Closed Bug 1009746 Opened 6 years ago Closed 6 years ago

[B2G][Browser][OTA][Flame] OTA updates do not indicate if / when they are completed.

Categories

(Firefox OS Graveyard :: Runtime, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.4+, b2g-v1.4 affected)

RESOLVED DUPLICATE of bug 1012214
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- affected

People

(Reporter: lmauritson, Unassigned)

Details

(Whiteboard: [flame-1.4-exploratory])

Attachments

(2 files)

Description:
When updating using OTA the update appears to install but does not inform the user if/when it is finished.
The "Uncompressing..." notification persists indefinitely.

Repro Steps:
1) Update a Flame to BuildID: 20140513000208 (Not the latest)
2) Download and extract Naoki’s recoverytest.zip (Attached)
3) CD to the “bug 976450” folder within the extracted recoverytest folder. (For example: “cd home/flash/scripts/recoverytest/bug 976450”)
4) Enter “./flash.sh” in the terminal. 
>>The device should restart when this process is finished.
5) Download and extract the B2G flash tools from: https://github.com/Mozilla-TWQA/B2G-flash-tool
6) CD to the folder you extracted the B2G flash tools to. (For example: “cd home/flash/scripts/B2G_Flash_Tools”)
7) Enter  “./change_ota_channel_pref.sh -d flame -v 1.4.0” in the terminal.
8) Go to Settings > Device Information and check for updates. (Wifi must be enabled)
9) When the update notification appears select it and wait for it to finish downloading.
10) Once the update prompt appears accept it.
11) Wait 10+ minutes and observe the status of the update.

Actual:
The notification says "Uncompressing..." and the update never appears to finish. Restarting the device after a time will show the latest build on the device info page.

Expected:
The update process shows a progress indicator and informs the user when the update is complete.
The update process completes successfully.

1.4F Environmental Variables:
Device: Flame 1.4F MOZ
BuildID: 20140513000208
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: c140bcd02b9b
Version: 30.0
Firmware Version: v10F-3


Keywords: notification screen, OTA, Update, 


Notes: Unable to attach logcat due to bug 1007697


Repro frequency: 100%
See attached: http://youtu.be/9VnSmALz9PM
Attached file recoverytest.zip
This librecovery.so is for the buri.  I'm not sure if the librecovery.so is interchangable between devices...

If it's not, I don't think this bug is valid.
Attached file librecovery.so
Use this file instead of the one provided with flash.sh
I haven't changed my librecovery.so, and am seeing this error.
Correction: logcat issue is bug 1008003
Hi Chris, I think they were doing a shallow flash; in which case you would have to replace the librecovery.so ( see bug 1004312 ).

A fullflash would be using the same librecovery.so in the second zip file and you would see the same issue.
I'm not too sure what you would see with the buri librecovery.so on a flame device.  That was the confusion that I was trying to clear up in comment 2.
Confused where the root cause of the problem here is.

Is this a problem with how we're testing this? If not, what could be the problem here?
Component: Gaia::Browser → General
Flags: needinfo?(nhirata.bugzilla)
We tried with a full flash and then tried to do a OTA; what ended up happening was that it didn't reboot after downloading and installing the update.  it ended up cycling back to uncompressing afterwards.  Forcing a reboot did show the updated version numbers in the settings.
Flags: needinfo?(nhirata.bugzilla)
Talking to dhylands, I made a mistake.  
librecovery.so isn't used in OTA; only FOTA.
So is this bug invalid then?
Flags: needinfo?(nhirata.bugzilla)
It's still valid in that the steps are as simple as
1) full flash yesterday's build on flame
2) connect to wifi 
3) go to settings -> device info -> check now
4) bring down the drop down notification
5) download the update
6) wait for the download to finish
7) apply the install

Expected: device should reboot
Actual: device does not reboot, even though it states in the log that it is restarting the device to apply it.

Note:
05-14 13:10:59.623: I/Gecko(1039): UpdatePrompt: Update downloaded, restarting to apply it
05-14 13:10:59.623: I/GeckoDump(1039): XXX FIXME : Got a mozContentEvent: update-prompt-apply-result
05-14 13:10:59.643: I/Gecko(1039): UpdatePrompt: Set previous_os to: 2.0.0.0-prerelease
Flags: needinfo?(nhirata.bugzilla)
This seems to be caused by a bug/change in the way that settings works.

In this code:
http://dxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js#378

UP_restartProcess is being called, but the callbackAfterSet (which is what actually restarts the phone) never gets called.
Does this reproduce if you test this on Open C?
Keywords: qawanted
The result on the Open_C is bug 1009851
Keywords: qawanted
Needed to do data migration testing for 1.4 --> 2.0, so we need this fixed for 1.4.
blocking-b2g: --- → 1.4?
Component: General → Runtime
Depends on: 1012214
This code was added with bug 968215 and it's in 1.4. I thought I broke it with bug 999572 but i think it never worked in certain use-cases. I will fix the settingsService with bug 1012214.
blocking-b2g: 1.4? → 1.4+
The workaround for now is to manually reboot the phone when its stuck in the uncompressing state.   It will apply the OTA update correctly.  QA can still do data migration testing with this workaround.  

My results Before update: 
Gaia      101c500903a2477f9de1ea5ce523b9e0be4d45d0
Gecko     https://hg.mozilla.org/mozilla-central/rev/41a54c8add09
BuildID   20140519040204
Version   32.0a1
ro.build.version.incremental=87
ro.build.date=Mon May  5 20:19:07 CST 2014

After rebooting:
Gaia      8a2352d5b7be27ec4b1ea18c680ebcd0b6d34348
Gecko     https://hg.mozilla.org/mozilla-central/rev/cb9f34f73ebe
BuildID   20140520040203
Version   32.0a1
ro.build.version.incremental=87
I've confirmed that with the patch in bug 1012214 applied that b2g restarts properly after the user requests to apply the update.
(In reply to Dave Hylands [:dhylands] (away - back May 16) from comment #18)
> I've confirmed that with the patch in bug 1012214 applied that b2g restarts
> properly after the user requests to apply the update.

Duping this bug to 1012214.   marking verifyme on 1012214 when that lands, using the steps in this bug to verify.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1012214
No longer blocks: 1009851
No longer depends on: 1012214
You need to log in before you can comment on or make changes to this bug.