940144 - [Buri]The system can not start up successfully after software updates

Status: RESOLVED WONTFIX

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

Description

[sync-1]

Firefox os  v1.0.1
 Mozilla build ID:20130606070202
 
 Created an attachment (id=564931)
 PR_PIC
 
 DEFECT DESCRIPTION:The system can not start up successfully after software updates and it stays on operators animation like PR_PIC. And we check it may caused by system's indexedDB.
 
  REPRODUCING PROCEDURES:
    You may push the system's indexedDB to your phone, this issue will happen. 
 
 
  EXPECTED BEHAVIOUR:
   The system can start up successfully
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE: 100%
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Attachment: PR_PIC

Clone from brother

Comment 2

[sync-1]

Attachment: System's error indexedDB

Clone from brother

Comment 3

[Ray REN]

Maybe it is ralation with permissions, I will update.

Comment 4

[Ray REN]

Attachment: permissions.sqlite

Comment 5

[Ray REN]

Hi alive,

This issue comes from user, do you have any ideas?

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Don't know this area.

Comment 7

[Ray REN]

Hi Joe,

Who could check this issue, please assignee it to him. Thanks.

Comment 8

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Dear Jack -

Heard that you got similar issue, could you help to check if this one is of the same root cause?

Thanks

Comment 9

[Jack Liu]

Dear Vance, 

We have checked handset returned by end user and dumped user data. When push dumped data into other handset and reboot it, we saw the same behavior as reported here. Because FOTA won't change any thing in user data partition, so I guess this problem caused by code in first boot sequence after FOTA. We found indexedDB for system app and permission are both wrong in this case, please help analyze what caused these errors and how to recover from these errors and furthermore how to avoid these errors. 

Permission indexedDB found broken in several handsets returned by end users, so I hope the mechanism for indexedDB updating can be improved.

Thanks.

Comment 10

[Andrew Overholt [:overholt]]

Fabrice, Ben thinks this could be a bug somewhere in gaia's upgrade functionality.  WDYT?

Comment 11

[Gregor Wagner [:gwagner]]

We need more information here. A DB doesn't help us. We need STRs. Pushing an existing DB to a phone is not supported.
From which to which version did you upgrade?
What's the logcat during the upgrade?
What apps are on the phone before the upgrade?
Did the upgrade complete?

Comment 12

[Ray REN]

Dear Andrew,
This issue happens in a few phones.

Dear Gregor,
We doesn't havre more infomation without data. If the DB has something error, please make the phone works Normally. Maybe you could re-create DB or other ways.

Comment 13

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Ray -

We do need more information, please at least provide the answers to the following questions:

1. From which version did you upgrade? Please provide the build ID if possible
2. Do you still keep that problematic handset? could you power on the handset and get the logcat log? The log might help us to check why it is stuck at firefox logo animation

Thanks

Comment 14

[Ray REN]

(In reply to Vance Chen [:vchen] from comment #13)
> Hi Ray -
> 
> We do need more information, please at least provide the answers to the
> following questions:
> 
> 1. From which version did you upgrade? Please provide the build ID if
> possible
> 2. Do you still keep that problematic handset? could you power on the
> handset and get the logcat log? The log might help us to check why it is
> stuck at firefox logo animation
> 
> Thanks


1.The build ID is 20130606070202. We only fix some bugs on it.
2.We doesn't have problematic handset. We could push the DB into phone to reproduce it. And I will upload the logs.

Comment 15

[Ray REN]

Attachment: log_from_return_phone.txt

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

Cannot find anything related to gaia in the log. Changing component.

Comment 17

[Preeti Raghunath(:Preeti)]

Buri,

We need some very clear step by step STRs here.

How are we reproducing this bug?

Repro rate?

Comment 18

[Ray REN]

(In reply to Preeti Raghunath(:Preeti) from comment #17)
> Buri,
> 
> We need some very clear step by step STRs here.
> 
> How are we reproducing this bug?
> 
> Repro rate?

reproduce step:
1. root your phone.
2. push the attachment DB to phone. The cmd like "adb push 1008+f+app+++system.gaiamobile.org/    /data/local/indexedDB/1008+f+app+++system.gaiamobile.org"
3. reboot the phone, it will be repreoduced and the Repro rate is 100%.

For Step 2, only push system's indexDB or permissions.sqlite, they all can reproduce.

Comment 19

[David Scravaglieri [:scravag]]

ni? Alexandre, could you please take a look at this issue ?

Comment 20

[Gregor Wagner [:gwagner]]

(In reply to Ray REN from comment #18)
> (In reply to Preeti Raghunath(:Preeti) from comment #17)
> > Buri,
> > 
> > We need some very clear step by step STRs here.
> > 
> > How are we reproducing this bug?
> > 
> > Repro rate?
> 
> reproduce step:
> 1. root your phone.
> 2. push the attachment DB to phone. The cmd like "adb push
> 1008+f+app+++system.gaiamobile.org/   
> /data/local/indexedDB/1008+f+app+++system.gaiamobile.org"
> 3. reboot the phone, it will be repreoduced and the Repro rate is 100%.
> 
> For Step 2, only push system's indexDB or permissions.sqlite, they all can
> reproduce.

You can't just push a system DB to a phone. That's not supported. The DB has to be build during first run or during the update.

Comment 21

[:gerard-majax]

(In reply to Ray REN from comment #14)
> (In reply to Vance Chen [:vchen] from comment #13)
> > Hi Ray -
> > 
> > We do need more information, please at least provide the answers to the
> > following questions:
> > 
> > 1. From which version did you upgrade? Please provide the build ID if
> > possible
> > 2. Do you still keep that problematic handset? could you power on the
> > handset and get the logcat log? The log might help us to check why it is
> > stuck at firefox logo animation
> > 
> > Thanks
> 
> 
> 1.The build ID is 20130606070202. We only fix some bugs on it.
> 2.We doesn't have problematic handset. We could push the DB into phone to
> reproduce it. And I will upload the logs.

What is exactly behind 20130606070202 ? v1.0.1 ? v1.1 ? Is it the starting or ending version of the upgrade ?

You said you only fixed bugs in it, but it would help a lot if you could check differences and see if you reproduce with our vanilla code: I've seen too much bugs that was on code we don't even have.

Plus, I suspect pushing the DB is a way to reproduce the issue on a new device. Again, it would help a lot if you documented versions.

Meanwhile, I could have a look at this tomorrow maybe, if I get my hands on a Buri AND nice and clear STRs and versions.

Comment 22

[Ray REN]

(In reply to Gregor Wagner [:gwagner] from comment #20)
> 
> You can't just push a system DB to a phone. That's not supported. The DB has
> to be build during first run or during the update.

Now during the update, the system DB has something error. What could we do to make the phone run normally.

Comment 23

[Gregor Wagner [:gwagner]]

(In reply to Ray REN from comment #22)
> (In reply to Gregor Wagner [:gwagner] from comment #20)
> > 
> > You can't just push a system DB to a phone. That's not supported. The DB has
> > to be build during first run or during the update.
> 
> Now during the update, the system DB has something error. What could we do
> to make the phone run normally.

Ok so what we have so far: something goes wrong during the update and causes a bricked phone. Your guess is that the systemDB might be corrupt after the upgrade failed.
First we have to find the root cause why the upgrade failed and then we might be able to provide some code that deals with bricked phones.

Are you sure the log is from a phone where the upgrade is currently failing or is it from a phone that got restarted after the upgrade failed?
We need a reproducible case here that shows the failing upgrade. A broken DB caused by a failed upgrade doesn't help us.

Can you provide us a build from before the upgrade and a mechanism to trigger the upgrade with our upgrade code?

Comment 24

[Ray REN]

(In reply to Gregor Wagner [:gwagner] from comment #23)
> Ok so what we have so far: something goes wrong during the update and causes
> a bricked phone. Your guess is that the systemDB might be corrupt after the
> upgrade failed.
> First we have to find the root cause why the upgrade failed and then we
> might be able to provide some code that deals with bricked phones.
> 
> Are you sure the log is from a phone where the upgrade is currently failing
> or is it from a phone that got restarted after the upgrade failed?
> We need a reproducible case here that shows the failing upgrade. A broken DB
> caused by a failed upgrade doesn't help us.
> 
> Can you provide us a build from before the upgrade and a mechanism to
> trigger the upgrade with our upgrade code?

Hi Gregor,
This is low probability events, we can't provide reproducible case to find the root cause.

Now we have some ideas for this issue, hope it is help for you.
1. if read DB error, you could re-create DB by default value.
2. before upgrade DB, you may backup the old DB, if read new DB failed, please read form old DB.
3. When upgrade DB, after upgrade DB, you may read for test to make sure the DB is OK.

Comment 25

[Preeti Raghunath(:Preeti)]

This seems not reproducible internally. Please re-nom if the issue can be reproduced.

Comment 26

[Gregor Wagner [:gwagner]]

(In reply to Ray REN from comment #24)
> (In reply to Gregor Wagner [:gwagner] from comment #23)
> > Ok so what we have so far: something goes wrong during the update and causes
> > a bricked phone. Your guess is that the systemDB might be corrupt after the
> > upgrade failed.
> > First we have to find the root cause why the upgrade failed and then we
> > might be able to provide some code that deals with bricked phones.
> > 
> > Are you sure the log is from a phone where the upgrade is currently failing
> > or is it from a phone that got restarted after the upgrade failed?
> > We need a reproducible case here that shows the failing upgrade. A broken DB
> > caused by a failed upgrade doesn't help us.
> > 
> > Can you provide us a build from before the upgrade and a mechanism to
> > trigger the upgrade with our upgrade code?
> 
> Hi Gregor,
> This is low probability events, we can't provide reproducible case to find
> the root cause.
> 
> Now we have some ideas for this issue, hope it is help for you.
> 1. if read DB error, you could re-create DB by default value.
> 2. before upgrade DB, you may backup the old DB, if read new DB failed,
> please read form old DB.
> 3. When upgrade DB, after upgrade DB, you may read for test to make sure the
> DB is OK.

I dont think the actual DB is corrupted but I can't load it in our indexedDB browser.
Bent, can you take a quick look if the DBs are alright?
More likely is that the upgrade didn't finish and now we have old values in the DB.

Comment 27

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I can't get the file to open in sqlite, I get: "database disk image is malformed"

Comment 28

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Ok, I looked at this more closely with a SQLite developer today and basically it looks like the two pages that define the database schema have been zero'd out. Apparently this can happen for a number of reasons but usually it involves an fsync() returning before data has actually been written to storage.

Comment 29

[BMO Automation]

Firefox OS is not being worked on