861107 - Device locked after FOTA upgrade

Status: RESOLVED DUPLICATE of bug 861959

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

Description

[Juan Perez-Bedmar [:juanpbf]]

Attachment: "Boot" screen appeared during FOTA update

The DuT is locked after a FOTA upgrade.
During the FOTA upgrade, a strange "boot" screen with different options is displayed (see screenshot attached). If you select the "Reboot now" option the handset reboots, but it is locked in the "Firefox" screen.   

Steps to reproduce the issue    
1 -Try to update the handset by selecting the proper option in the following route: Setting -> Phone Information -> software update.
2 -Download the firmware available.
3 -When the DuT ask about the install, select "Now" option.
4 -The package is uncompressed and the installation process begins.    

Current    
During the FOTA upgrade, a strange boot screen with different options is displayed [1]. If you select "Reboot now" option, the handset reboots, but it is locked in the "Firefox" screen.    

Expected result  
The handset should be upgraded correctly. The boot screen with options [1] should not be displayed.    
    
[1] See attached file

Marked as P1, nominating to tef?

Comment 1

[Juan Perez-Bedmar [:juanpbf]]

Dependency added.

Comment 2

[Dave Hylands [:dhylands]]

That looks like the recovery ROM, which is the code which actually applies the FOTA update.

Although different people use the word FOTA to mean different things. To me, the FOTA update is the one that can update anything, including the kernel and other firmware stuff. This type of update is applied by the recovery ROM, and involves an update.zip file (although I think we still wrap it up as an update.mar).

The system updates can only update gecko/gaia. These updates do not involve the recovery ROM.

Comment 3

[Johnny Stenback (:jst)]

Dave, can you dig in here? If you can't get to this bug this week, please let me know!

Comment 4

[Dave Hylands [:dhylands]]

jst - I have a feeling that this is a problem caused by software outside our control (i.e. it's the vendor software that needs to be fixed).

I'm cc'ing marshall, since he's alot more familiar with this than I am. But I will see if I can figure out what's going on.

Comment 5

[Firefox_Mozilla]

Juan 

Which version was the device running before upgrading?
The build id?

Comment 6

[Firefox_Mozilla]

Have you update the boot image(may be for tp issue?) before trying system upgrade? 
Thanks

Comment 7

[Juan Perez-Bedmar [:juanpbf]]

(In reply to Firefox_Mozilla from comment #5)
> Juan 
> 
> Which version was the device running before upgrading?
> The build id?

The handset was running our official SW delivered (Our buildid is : 20130328100224), which is based on Buildid "20130321070205".

(In reply to Firefox_Mozilla from comment #6)
> Have you update the boot image(may be for tp issue?) before trying system
> upgrade? 
> Thanks
The tester just followed the normal procedure, the steps prompted by the handset. Maybe this issue is related to getting corrupted one of the files during the OTA download or similar

Comment 8

[Marshall Culpepper [:marshall_law]]

A few follow up questions:
- Where / how was this FOTA update generated?
- Did the device have an sdcard installed when the FOTA update was downloaded? We allow fallback to /data/local (which is what your screen capture shows), but it would be good to confirm why this happened.
- Can you also attach the recovery log from /cache/recovery/log (or /cache/recovery/last_log)?

Comment 9

[Dave Hylands [:dhylands]]

Also, since the recovery ROM is saying that /data/local/updates/fota/update.zip is bad, it would be good to pull the update.zip file from the phone and see if the zip looks good.

Ideally we could compare it with the update.zip contained in the update.

The update.zip file shouldn't be corrupted during the download, since we do a hash check to verify the integrity.

Can you provide the URL for downloading the update.mar file?

Comment 10

[Firefox_Mozilla]

To Juan 

Can you help me to confirm with the tester about:
1) Will other deivces have the same issue when upgrading system?
2) Have they changes the boot image? I guess this is caused by boot image mismatching from the message of the screen capture 
3) Help me to tey to get the log(maybe needs to load the images by nand download tool, and enable remote debug when the system start up) via the below command

----------
adb pull /cache/recovery/log .
adb pull /cache/recovery/last_log .
----------
And I don't think the update.zip is corrupted, since the update process will not start before it have verified the update.zip

To Dave
The URL for downloading the update.mar should be
http://firefox.ztems.com/prerelease/packages/roamer2/18.0/20130328100224/update.mar

Comment 11

[Juan Perez-Bedmar [:juanpbf]]

(In reply to Firefox_Mozilla from comment #10)
> To Juan 
> 
> Can you help me to confirm with the tester about:
> 1) Will other deivces have the same issue when upgrading system?
It happened in only one sample
> 2) Have they changes the boot image? I guess this is caused by boot image
> mismatching from the message of the screen capture 
I don't fully understand what you mean. If you are asking if the tester made any change on the files after downloading them via OTA, the answer is NO. He just clicked in "update now".
> 3) Help me to tey to get the log(maybe needs to load the images by nand
> download tool, and enable remote debug when the system start up) via the
> below command
I will request it to the tester.

Comment 12

[Firefox_Mozilla]

I mean whether they are using the boot image in the B02.zip package or load other boot image such as provided by Huang Jinyu with tp patch. 
or can you connect the phone to pc and run the below command and give me the output? Thanks.

adb shell busybox uname -a

Comment 13

[Marshall Culpepper [:marshall_law]]

So I ran the linked FOTA mar with my test-update script on the device pictured, and it looks like the signature of the update.zip doesn't match the signature on my device.

Juan, do you know which key this update.mar was built with? It needs to match the key on the device. test-update.py by default uses the test keys here:

build/target/product/security/testkey.pk8
build/target/product/security/testkey.x509.pem

Comment 14

[Juan Perez-Bedmar [:juanpbf]]

(In reply to Marshall Culpepper [:marshall_law] from comment #13)
> So I ran the linked FOTA mar with my test-update script on the device
> pictured, and it looks like the signature of the update.zip doesn't match
> the signature on my device.
> 
> Juan, do you know which key this update.mar was built with? It needs to
> match the key on the device. test-update.py by default uses the test keys
> here:
> 
> build/target/product/security/testkey.pk8
> build/target/product/security/testkey.x509.pem

Hi, Shenyang, could you please provide this info to Marshall?

thanks

Comment 15

[Dietrich Ayala (:dietrich)]

Hi Marshall, can you provide a ballpark ETA for this?

Comment 16

[Kai-Chih Hu [:khu]]

Need info from [e-mail] because Shenyang might use this account.

Comment 17

[Marshall Culpepper [:marshall_law]]

Ballpark ETA for the end of next week, since we haven't been able to confirm if this is a platform bug or a configuration problem yet.

Comment 18

[Firefox_Mozilla]

(In reply to Juan Perez-Bedmar [:juanpbf] from comment #14)
> (In reply to Marshall Culpepper [:marshall_law] from comment #13)
> > So I ran the linked FOTA mar with my test-update script on the device
> > pictured, and it looks like the signature of the update.zip doesn't match
> > the signature on my device.
> > 
> > Juan, do you know which key this update.mar was built with? It needs to
> > match the key on the device. test-update.py by default uses the test keys
> > here:
> > 
> > build/target/product/security/testkey.pk8
> > build/target/product/security/testkey.x509.pem
> 
> Hi, Shenyang, could you please provide this info to Marshall?
> 
> thanks

We use zte private key to make update.zip
Thanks

Comment 19

[Marshall Culpepper [:marshall_law]]

David and Juan showed me this FOTA update on an ikura, but unfortunately it was successful. I'm still waiting for a /cache/recovery/log that has more info about what might have actually failed with the update..

Comment 20

[songsy]

may be with the same reason of bug 861959

Comment 21

[songsy]

Seems it can not be reproduced with bug 861959 fix. 

I think we can close it now, and reopen if needed.

Comment 22

[Andrew Overholt [:overholt]]

Thanks, marking as a dupe of bug 861959 since it seems to be the same issue.