Updating fails at "Downloading updates..." part

RESOLVED DUPLICATE of bug 830462

Status

Firefox OS
General
--
blocker
RESOLVED DUPLICATE of bug 830462
5 years ago
5 years ago

People

(Reporter: gcp, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-basecamp:-, b2g18+)

Details

(Reporter)

Description

5 years ago
I'm on build 20120104etc. I was notified there's an update available, clicking shows it to be 40-ish MB. If I tap to download the update, it hangs forever in "Downloading updates..." 0.00 bytes downloaded

I can use the browser to surf the internet while it's stuck like that.

Because this prevents updating, putting as a blocker.
I think you meant to nom.
blocking-basecamp: --- → ?
gcp, can you provide a logcat of this happening on your device? We suspect this is a dupe of a bug that's already been fixed.
Flags: needinfo?(gpascutto)
(Reporter)

Comment 3

5 years ago
I guess this is the relevant part:

I/Gecko   (  110): UpdatePrompt: Pausing download
I/GeckoDump(  110): XXX FIXME : Got a mozContentEvent: update-download-cancel
...
I/Gecko   (  110): UpdatePrompt: No active update found to download
I/GeckoDump(  110): XXX FIXME : Got a mozContentEvent: update-available-result

Most of the other stuff is IdleService log spam. (For which, ironically, *I* am to blame)
Flags: needinfo?(gpascutto)
This is something we should definitely investigate more, but without a reliable STR we can't block basecamp.
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Keywords: qawanted
(Reporter)

Comment 5

5 years ago
I went into settings and forced a re-check. This caused the download to start, but it got stuck at about 24Mb similarly as before at 0.00.

This morning, the phone was stuck at "Decompressing", implying the download eventually finished during the night, but unpacking somehow failed or got stuck. 

After canceling and forcing a redownload, the update proceeded normally.
Can you make sure to attach a logcat please when you run into this issue again?  I found a different bug with the hash codes not matching and thus not updating (1/17 build)... I'm not sure if the hash is wrong on the server or client end.  It was stuck at 0.0 as well. I reported it as a separate bug because I'm not sure that this is the same.  Bug 832205
Note to self/QA: we probably need some test cases around old versions skipping some updates as well.  Not sure if we have that in our moztrap.  Setting flag to have that added.
Flags: in-moztrap?(nhirata.bugzilla)
(In reply to Gian-Carlo Pascutto (:gcp) from comment #5)
> I went into settings and forced a re-check. This caused the download to
> start, but it got stuck at about 24Mb similarly as before at 0.00.
> 
> This morning, the phone was stuck at "Decompressing", implying the download
> eventually finished during the night, but unpacking somehow failed or got
> stuck. 
> 
> After canceling and forcing a redownload, the update proceeded normally.

The getting stuck at 24 Mb should be solved by bug 825598.
Getting an invalid hash in the first place, is typically due to bug 831701 and/or bug 830462.
In any event, you should be able to recover by doing:
adb shell rm /sdcard/updates/0/update.mar
reboot
Do a "Check now" for updates

Comment 10

5 years ago
This issue did not repro. Was able to update OTA to build 20130208070201 Dec 5th Kernel with no known issues.  Did this on current providers network.  Also tested on two other devices and did it with WiFI and it worked correctly.
Keywords: qawanted
I'm going to close this as a dup
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 830462
test case https://moztrap.mozilla.org/manage/caseversion/41383/ created
Flags: in-moztrap?(nhirata.bugzilla) → in-moztrap+
You need to log in before you can comment on or make changes to this bug.