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

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.

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?

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.

Talking to dhylands, I made a mistake. librecovery.so isn't used in OTA; only FOTA.

So is this bug invalid then?

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

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?

The result on the Open_C is bug 1009851

Needed to do data migration testing for 1.4 --> 2.0, so we need this fixed for 1.4.

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.

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.