865764 - [FOTA] Crash when new system version download is interrupted and resumed

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect, P1)

Description

[Juan Perez-Bedmar [:juanpbf]]

Buildid "20130321070205", device: ikura
gecko commit: b5183c99228bdc5be33340e359efd1b4f0859e92 
gaia commit: 577d13088ebdbd353d13910d3317e713a140415b

We are reproducing a crash while updating via FOTA. The bug is quite similar to Bug 861959 but since that bug is already closed and the issue now, only happens after following some very specific steps, I preferred to file a new bug:
1 - Look for new updates 
2 - Start downloading the mandatory one (system update - 17.11 MB)
3 - When the download is about to finish (around 16 - 17MB), cancel the download
4 - Then click into the notifications bar to download the update again

Actual result:
 - At this point, instead of resuming the download, the notification bar will directly show "uncompressing" (instead of downloading), 
 - If you follow the steps prompted to update the handset, it will try to install the update but and error occurs, and the Android boot image is shown. 
 - If then you just reboot the handset, it will turn on at the original SW, it  hasn't been updated 

Expected result: 
Download must resume and installation process must be done without problems.


Additional info
- My colleagues will provide logs about this issue and may add some extra information
- If you need the original build used to reproduced this issue, please email me, and I'll send you a Box link to get it

Comment 1

[Marshall Culpepper [:marshall_law]]

Does this happen if you try to cancel the update any time before 16-17MB (i.e when not so near the end of the download?)

I mainly ask because it's possible the system has actually downloaded the whole update even though you cancelled it when the UI showed only a "partial" download.

In any case, there shouldn't be any problems applying an update that was successfully extracted, so there is probably _something_ going on here, I just want to make sure we find the right repro steps :)

Comment 2

[Juan Perez-Bedmar [:juanpbf]]

(In reply to Marshall Culpepper [:marshall_law] from comment #1)
> Does this happen if you try to cancel the update any time before 16-17MB
> (i.e when not so near the end of the download?)
We have tried to reproduce this issue by cancelling the update earlier, and we cannot reproduce it

> I mainly ask because it's possible the system has actually downloaded the
> whole update even though you cancelled it when the UI showed only a
> "partial" download.
We have the same guess. It looks like that the update has been actually downloaded

Comment 3

[Kai-Chih Hu [:khu]]

As far as I know, it's holidays in China. May I know when we could get logs? Thanks!

Comment 4

[Juan Perez-Bedmar [:juanpbf]]

(In reply to khu from comment #3)
> As far as I know, it's holidays in China. May I know when we could get logs?
> Thanks!

Fang Chen, please, give us feedback here. Thanks

Comment 5

[Alex Keybl [:akeybl]]

Let's unassign once this ends up not being a problem in Gecko (I know I know, guilty until proven innocent).

Comment 6

[FangChen]

Attachment: fota log

this log was caught after the phone restart and flash a new boot.img to catch the log

Comment 7

[Andrew Overholt [:overholt]]

Marshall, does the log from comment #6 contain the information you need to proceed here?

Comment 8

[Kai-Chih Hu [:khu]]

ni from Marshall.

Comment 9

[Marshall Culpepper [:marshall_law]]

(In reply to Andrew Overholt [:overholt] from comment #7)
> Marshall, does the log from comment #6 contain the information you need to
> proceed here?

This is just the Gecko update log, which doesn't have much info. Preferably we could get the recovery log which should live at /cache/recovery/log

Comment 10

[FangChen]

Attachment: new log

new log attached

Comment 11

[Marshall Culpepper [:marshall_law]]

So this is the relevant part of the recovery log (near the bottom):

Verifying update package...
I:verify_file returned 1
E:signature verification failed

This means that the update package was signed with a different public/private key pair than the one that is stored on the device in /res/keys. (This is also the same error I saw when I tried to update my device using an earlier FOTA update)

Comment 12

[Andrew Overholt [:overholt]]

(In reply to Marshall Culpepper [:marshall_law] from comment #11)
> So this is the relevant part of the recovery log (near the bottom):
> 
> Verifying update package...
> I:verify_file returned 1
> E:signature verification failed
> 
> This means that the update package was signed with a different
> public/private key pair than the one that is stored on the device in
> /res/keys. (This is also the same error I saw when I tried to update my
> device using an earlier FOTA update)

So is this an OEM issue (I'm putting NPOTB in the whiteboard because I think so)?  I think for v1.0.1 we can probably accept the current situation of just not updating properly so I'm tef+ -> tef?.

Comment 13

[BMO Automation]

Firefox OS is not being worked on