1115619 - [FFOS7715 v2.1] after Power off test phone couldn't start up normally and stay at the logo of start-up

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Stability, defect)

Comment 1

[ben.song]

[Blocking Requested - why for this release]:

Comment 2

[ben.song]

Dear Vance,Shawn,

After analysis with problem phone, I found the workaround in v1.4 is not work in v2.1. While profile do change, permissions.sqlite would not be removed and renew.

Could you help me with the written mechanism of permissions.sqlite in it's first time start ?

Comment 3

[Steven Yang [:styang]]

Hi Ben, the statement above is not clear. Could you detail the problem or give us the bug number in 1.4?

Comment 4

[Steven Yang [:styang]]

clear the blocking flag until more details come.

Comment 5

[ben.song]

(In reply to Steven Yang [:styang] from comment #4)
> clear the blocking flag until more details come.

Dear Steven,

The bug number in 1.4 is 1092059. If you have any problem about it, we could communicate with it.

Thanks.

Comment 6

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

I believe we should fix this kind of issue at 2.1S, nominate to 2.1S blocker

Comment 7

[Steven Yang [:styang]]

Blocking partners test. Shawn, could you have someone to look into it? thanks.

Comment 8

[Steven Yang [:styang]]

Hi Rex, just synced with Shawn, please help on this bug. thanks.

Comment 9

[Rex Hung[:rhung]]

Yes, now I am investigating booting flow related to profile for this bug.

Comment 10

[Rex Hung[:rhung]]

Keep NI for follow-up.

Comment 11

[Danny Liang [:dliang]]

Attachment: auto_rebooting_test.sh

Auto script to emulate sprd power off test, the flow as following:
1. erase and reflash userdata, then reboot device
2. reboot at X ms after ADB connected, when X is 20, 40, 60, ...., 170000.
3. check if homescreen exist after 60s after last reboot
  - If yes, go to (1) and repeat test until 8500 tests.
  - If no, stop test and print the delay and round#

Comment 12

[Danny Liang [:dliang]]

Attachment: auto_poweroff_test.sh

Comment 13

[Rex Hung[:rhung]]

Update current observation:
I refer to the questionable permissions.sqlite in bug 1092059 and create a similar one(with 22 records) based on 2.1, and found device cannot boot up with this permissions.sqlite. After pulling permissions.sqlite out of device, I found that the number of records are increased to 108, instead of 22.
Will upload my questionable permissions.sqlite later and keep investigating this bug.

Comment 14

[Rex Hung[:rhung]]

Attachment: permissions.sqlite_after_reboot

Comment 15

[Rex Hung[:rhung]]

Attachment: permissions.sqlite_after_reboot_export

Comment 16

[Rex Hung[:rhung]]

Attachment: permissions.sqlite_modified

Comment 17

[Rex Hung[:rhung]]

Attachment: permissions.sqlite_modified_export

Comment 18

[Rex Hung[:rhung]]

Hi, Ben,

Could you provide us your questionable permissions.sqlite file based on the power off test of v2.1?
I would like to check if my observation matches with your case. Thank you.

Comment 19

[ben.song]

Attachment: permissions.sqlite_problem_v2.1

Dear Rex,

This attachment is the file of permissions.sqlite which you need in poweroff test of v2.1.

Thanks.

Comment 20

[Rex Hung[:rhung]]

Update current analysis as follow:

permission.sqlite files which come from power off test in v1.4 and v2.1 actually have different content as follow:
v1.4 - valid table, but database records are not completed(22 entries).
v2.1 - no valid table available(mos_hosts doesn't exist).
That is the reason why v1.4 patch cannot work for v2.1 case.

Will continue investigating how to re-construct permissions.sqlite or recovery device from a questionable permissions.sqlite during booting.

Comment 21

[Rex Hung[:rhung]]

The following implement in "gecko/dom/apps/Webapps.jsm" results in that App permissions are loaded to permssins.sqlite only at the first boot or reboot after system update. So, if power is cut off when permissions are loading, permission.sqlite would be always incompleted in subsequent reboot.

  let runUpdate = AppsUtils.isFirstRun(Services.prefs);
  if (runUpdate) {
       ...
    // At first run, install preloaded apps and set up their permissions.
    for (let id in this.webapps) {
      let isPreinstalled = this.installPreinstalledApp(id);
      this.removeIfHttpsDuplicate(id);
      if (!this.webapps[id]) {
        continue;
      }
      this.updateOfflineCacheForApp(id);
      this.updatePermissionsForApp(id, isPreinstalled,
                                    true /* isSystemUpdate */); 
    }
      ...
  }   

The following are current ideas of guaranteeing the completion of loading App permission to permissions.sqlite. Will have a local try first and evaluate its side effect also.
1. Create a preference entry to monitor App permission loading.
2. Reset this preference entry for system update case also.
3. Avoid record duplication in permissions.sqlite.

Comment 22

[Steven Yang [:styang]]

Rex, since you're working on this issue, assign it to you.

Comment 23

[Rex Hung[:rhung]]

Correct my commnet in Comment 20 for v2.1 case as follow:
In the v2.1 permissions.sqlite provided by Ben, the file is corrupted actually. I check raw content of permissions.sqlite and the table(moz_hosts) can be found, but not completed. So, it should be that the power is cut off when the table is creating. Currently, there is no error handling or table re-creation for this case. The file(permissions.sqlite) keeps corrupted in the subsequent rebooting, and results in that v1.4 workaround does not work.

Summary two cases and their action as follow:
Case 1: table records not completed
  Will have a patch in this bug to guarantee all app permissions can be loaded to permissions.sqlite successfully.
Case 2: corrupted permissions.sqlite
  Will have a patch in bug 1124126 to handle corrupted permissions.sqlite.

Comment 24

[Rex Hung[:rhung]]

Attachment: Use-a-preference-to-guarantee-app-permission-loading.patch

Create a patch as the attachment to guarantee the completion of app permissions loading to /data/local/permissions.sqlite.

Comment 25

[Rex Hung[:rhung]]

Hi, Ben,

Could you run power-off test again with the ROM images which include my patches(attachment 8554380 [details] [diff] [review] and attachment 8554379 [details] [diff] [review] in bug 1124126)? If testing result is still failed, please pull out the following file and folder from the failed device and share them with us. Thank you.
1. /data/local/permissions.sqlite
2. /data/b2g/mozilla/*

Comment 26

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

ni Song Ben per Comment#25

Comment 27

[ben.song]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #26)
> ni Song Ben per Comment#25

Dear Vance, Rex,

OK, thanks for your patch, we would test and verify the patches you supply, if it success or failed i would give you feedback soon.

Thanks.

Comment 28

[shawn ku [:sku]]

Since Rex is working on this, and provide patch to partner for verification.
clear ni for myself.
Once there is any need, feel free to ni me again.

Comment 29

[ben.song]

(In reply to shawn ku [:sku] from comment #28)
> Since Rex is working on this, and provide patch to partner for verification.
> clear ni for myself.
> Once there is any need, feel free to ni me again.

Dear Shawn,

OK,Thanks a lot.

Comment 30

[ben.song]

Attachment: userdata.tar.gz

Dear Vance, Rex,

After four days verification, the problem reproduced and rate is 5/5.

For after poweroff test, we couldn't connect with problem phones by adb shell, so we get userdata.img through other method.

Comment 31

[Rex Hung[:rhung]]

Hi, Ben,

I got the problem when trying to mount your userdata.img for check. The following are the error messages I got. Could you have any idea of this problem?

$ $ file userdata_1_COM3.bin
userdata_1_COM3.bin: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)
$ mkdir userdata
$ mount -t ext4 userdata_1_COM3.bin userdata
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

$ dmesg | tail
[1213275.810664] EXT4-fs (loop0): bad geometry: block count 366210 exceeds size of device (6334 blocks)

Comment 32

[ben.song]

(In reply to Rex Hung[:rhung] from comment #31)
> Hi, Ben,
> 
> I got the problem when trying to mount your userdata.img for check. The
> following are the error messages I got. Could you have any idea of this
> problem?
> 
> $ $ file userdata_1_COM3.bin
> userdata_1_COM3.bin: Linux rev 1.0 ext4 filesystem data,
> UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents)
> (large files)
> $ mkdir userdata
> $ mount -t ext4 userdata_1_COM3.bin userdata
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> $ dmesg | tail
> [1213275.810664] EXT4-fs (loop0): bad geometry: block count 366210 exceeds
> size of device (6334 blocks)

Dear Rex,

I would find somebody to fix this problem, thanks.

Comment 33

[ben.song]

(In reply to ben.song from comment #32)
> (In reply to Rex Hung[:rhung] from comment #31)
> > Hi, Ben,
> > 
> > I got the problem when trying to mount your userdata.img for check. The
> > following are the error messages I got. Could you have any idea of this
> > problem?
> > 
> > $ $ file userdata_1_COM3.bin
> > userdata_1_COM3.bin: Linux rev 1.0 ext4 filesystem data,
> > UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents)
> > (large files)
> > $ mkdir userdata
> > $ mount -t ext4 userdata_1_COM3.bin userdata
> > mount: wrong fs type, bad option, bad superblock on /dev/loop0,
> >        missing codepage or helper program, or other error
> >        In some cases useful info is found in syslog - try
> >        dmesg | tail  or so
> > 
> > $ dmesg | tail
> > [1213275.810664] EXT4-fs (loop0): bad geometry: block count 366210 exceeds
> > size of device (6334 blocks)
> 
> Dear Rex,
> 
> I would find somebody to fix this problem, thanks.

(In reply to Rex Hung[:rhung] from comment #31)
> Hi, Ben,
> 
> I got the problem when trying to mount your userdata.img for check. The
> following are the error messages I got. Could you have any idea of this
> problem?
> 
> $ $ file userdata_1_COM3.bin
> userdata_1_COM3.bin: Linux rev 1.0 ext4 filesystem data,
> UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents)
> (large files)
> $ mkdir userdata
> $ mount -t ext4 userdata_1_COM3.bin userdata
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> $ dmesg | tail
> [1213275.810664] EXT4-fs (loop0): bad geometry: block count 366210 exceeds
> size of device (6334 blocks)

Dear Rex,

I'm sorry for our RD has failed at getting right userdata files and last reproduced phones have been exhausted.

If you still need reproduced userdata files, we would continue to do poweroff test and reproduce this problem.

Thanks.

Comment 34

[Rex Hung[:rhung]]

Hi, Ben,

Yes, the files which I mentioned in Comment 25 are really necessary to analyze the problem. So, please share these files to us once you reproduce the bug. About adb connection problem, could you have RD to check USB functionality for the failed devices first if possible?

Comment 35

[ben.song]

(In reply to Rex Hung[:rhung] from comment #34)
> Hi, Ben,
> 
> Yes, the files which I mentioned in Comment 25 are really necessary to
> analyze the problem. So, please share these files to us once you reproduce
> the bug. About adb connection problem, could you have RD to check USB
> functionality for the failed devices first if possible?

Dear Rex,

I would do it,and share userdata files once the bug be reproduced.

Thanks.

Comment 36

[ben.song]

Dear Rex,

I have uploaded the userdata.img.

ftp://ftp.spreadtrum.com/7715/1115619/userdata_COM3.img

username:mouzhi
password:mouZHI$$61

Thanks.

Comment 37

[Rex Hung[:rhung]]

Hi, Ben,

The file seems be invalid due to zero size. Could you check it again?

Comment 38

[ben.song]

(In reply to Rex Hung[:rhung] from comment #37)
> Hi, Ben,
> 
> The file seems be invalid due to zero size. Could you check it again?

Dear Rex,

Sorry for last upload happens some problems, I have uploaded again at:

ftp://ftp.spreadtrum.com/7715/1115619/userdata.tar.gz

username:mouzhi
password:mouZHI$$61

Thanks.

Comment 39

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

ni Rex per Comment#38

Comment 40

[Rex Hung[:rhung]]

Hi, Ben,

According to the userdata in Comment#38, corrupted permissions.sqlite seems not be recovered, so app permissions can not be loaded. I have updated patch file in bug 1124126 in order to get more clues. So, please make sure the following two patches are included in your images before restarting the test, since two cases are found and recorded in this bug and bug 1124126, respectively. Thank you.
1. attachment 8554380 [details] [diff] [review]
2. attachment 8563859 [details] [diff] [review] in bug 1124126

Comment 41

[ben.song]

(In reply to Rex Hung[:rhung] from comment #40)
> Hi, Ben,
> 
> According to the userdata in Comment#38, corrupted permissions.sqlite seems
> not be recovered, so app permissions can not be loaded. I have updated patch
> file in bug 1124126 in order to get more clues. So, please make sure the
> following two patches are included in your images before restarting the
> test, since two cases are found and recorded in this bug and bug 1124126,
> respectively. Thank you.
> 1. attachment 8554380 [details] [diff] [review]
> 2. attachment 8563859 [details] [diff] [review] in bug 1124126

Dear Rex,

I have applied the new patch of bug 1124126, sprd QA would reproduce this problem through poweroff test. I would give you feedback and userdata file after Chinese Spring Festival.

I first ni me and after reproduce would remove it.

Thanks.

Comment 42

[siiaceon]

Ben, pls upload new log for the reproducing. thx

Comment 43

[ben.song]

Dear Rex,

I have uploaded a new userdata file at:

ftp://ftp.spreadtrum.com/7715/1115619/userdata_COM3.img

username:mouzhi
password:mouZHI$$61

Thanks.

Comment 44

[Rex Hung[:rhung]]

Hi, Ben,

I am downloading the images now.
Could you also provide us the slog or I can find it in the userdata image?

Comment 45

[ben.song]

(In reply to Rex Hung[:rhung] from comment #44)
> Hi, Ben,
> 
> I am downloading the images now.
> Could you also provide us the slog or I can find it in the userdata image?

Dear Rex,

For adb shell couldn't connect after flash system.img or boot.img, so please get slog in the userdata image.

Thanks.

Comment 46

[Rex Hung[:rhung]]

Hi, Ben,

Could you try the following steps? Thank you.
1. Flash device with the images which includes two patches in Comment#40.
2. Power on the device and wait for seeing homescreen.
3. Provide the corresponding slog for us.

Comment 47

[ben.song]

(In reply to Rex Hung[:rhung] from comment #46)
> Hi, Ben,
> 
> Could you try the following steps? Thank you.
> 1. Flash device with the images which includes two patches in Comment#40.
> 2. Power on the device and wait for seeing homescreen.
> 3. Provide the corresponding slog for us.

Dear Rex,

Which version do you want, user or userdebug? I would supply slogs soon.

Thanks.

Comment 48

[Rex Hung[:rhung]]

Please use the version of running the Power-off test.

Comment 49

[ben.song]

Attachment: slog_of_user_and_userdebug.tar.gz

Dear Rex,

In this attachment, I upload slog of user and userdebug versions. The userdata.img I have supplied is from user version.

Thanks.

Comment 50

[Rex Hung[:rhung]]

Hi, Ben,

Could you double confirm that the patch(attachment 8563859 [details] [diff] [review] [diff] [review] in bug 1124126) is really applied to the images which you used in Comment#49? If applied, we at least see the following information in device logs to indicate that permissions.sqlite is created and connected, and the table inside it is created also for the first boot. However, I cannot find these information in the logs of Comment#49.
===============================================================
02-25 23:09:45.850 I/Power-test(  130): DB connection is ready. 
02-25 23:09:45.870 I/Power-test(  130): DB table is created.

Comment 51

[ben.song]

Attachment: slog_update.tar.gz

Dear Rex,

Sorry for last slog, I have updated the slog in this attachment.

Thanks.

Comment 52

[Rex Hung[:rhung]]

Hi, Ben,

Could you also confirm that the patch(attachment 8563859 [details] [diff] [review] [diff] [review] [diff] [review] in bug 1124126) was really applied to your test in Comment#43? I cannot find the following information in the slog(data/slog/), either.
===============================================================
02-25 23:09:45.850 I/Power-test(  130): DB connection is ready.

Comment 53

[ben.song]

Dear Rex,

Yes, I have supplied the version to the QA after applying the patch in attachment 8563859 [details] [diff] [review] and sprd QA did poweroff test with it.

Thanks.

Comment 54

[Rex Hung[:rhung]]

Hi, Ben,

I just uploaded a new patch(attachment 8571226 [details] [diff] [review] [diff] [review]) in bug 1124126. Please generate images based on this patch and attachment 8554380 [details] [diff] [review] [diff] [review], and then restart the power-off testing.

For adb problem, I found that adb daemon is not running according to snapshot logs. Could you have some related RD to check why adb daemon is not running at the same time? Hope we can collect as many clues as possible to clarify this booting failure.
Thank you.

Comment 55

[ben.song]

(In reply to Rex Hung[:rhung] from comment #54)
> Hi, Ben,
> 
> I just uploaded a new patch(attachment 8571226 [details] [diff] [review]
> [diff] [review]) in bug 1124126. Please generate images based on this patch
> and attachment 8554380 [details] [diff] [review], and then
> restart the power-off testing.
> 
> For adb problem, I found that adb daemon is not running according to
> snapshot logs. Could you have some related RD to check why adb daemon is not
> running at the same time? Hope we can collect as many clues as possible to
> clarify this booting failure.
> Thank you.

Dear Rex,

I have taken that patch and applied it, we would do poweroff test tomorrom.

Thanks.

Comment 56

[siiaceon]

ni ben to feedback result on Monday

Comment 57

[ben.song]

Dear Rex,

Recently we have reproduced this problem, reproduce rate is 3/4. But the appearance is not the same with before.

The three phones could restart normally, but after that icons of homescreen is disappeared and others is OK. 

Now, our QA is continue to reproduce this problem.

Comment 58

[Rex Hung[:rhung]]

Hi, Ben,

Please help me to clarify my understanding as follow:
1. So, you have one device which passed the power-off test?
2. For those three failed devices, does their ADB work normally after restart?
   If yes, could you provide us the following data?
     - slog
     - /data/local/permissions.sqlite
     - /data/b2g/mozilla/XXXXX.default/prefs.js
3. What do you mean for "icons of homescreen is disappeared"? Could you show us the snapshot about it?
   It seems to hit other problems. Please provide us the slog for check.

Comment 59

[ben.song]

(In reply to Rex Hung[:rhung] from comment #58)
> Hi, Ben,
> 
> Please help me to clarify my understanding as follow:
> 1. So, you have one device which passed the power-off test?
> 2. For those three failed devices, does their ADB work normally after
> restart?
>    If yes, could you provide us the following data?
>      - slog
>      - /data/local/permissions.sqlite
>      - /data/b2g/mozilla/XXXXX.default/prefs.js
> 3. What do you mean for "icons of homescreen is disappeared"? Could you show
> us the snapshot about it?
>    It seems to hit other problems. Please provide us the slog for check.

Dear Rex,

1. So, you have one device which passed the power-off test?

ben.song: There is one device failed in the power-off test for connecting line fall off.

2. For those three failed devices, does their ADB work normally after restart?
   If yes, could you provide us the following data?
     - slog
     - /data/local/permissions.sqlite
     - /data/b2g/mozilla/XXXXX.default/prefs.js

ben.song: After restart, ADB works not well, devices still unable to connect through ADB. After make Debugging via USB 'ADB and DevTools' it still not work well. Our RD is working with ADB problem. After it work out I would provide the data you needed.

3. What do you mean for "icons of homescreen is disappeared"? Could you show us the snapshot about it?
   It seems to hit other problems. Please provide us the slog for check.

ben.song: It means FFOS failed to show main menu icons. I would upload slog soon. The slog is not the one power-off test, but the problem reproduced by reboot. 

ftp://ftp.spreadtrum.com/7715/1115619/fail_icon_display_ffos.rar

username:mouzhi
password:mouZHI$$61

Thanks.

Comment 60

[Rex Hung[:rhung]]

Sorry, I am still confused with your comment in the Comment#57.
1. Reproduce rate is 3/4. But, what happened to the remaining 1/4? Stuck at the logo of start-up?
2. For this time, the three failed devices don't stuck at the logo of start-up, but enter in homescreen app without any icons showed. Is that correct?

Comment 61

[ben.song]

(In reply to Rex Hung[:rhung] from comment #60)
> Sorry, I am still confused with your comment in the Comment#57.
> 1. Reproduce rate is 3/4. But, what happened to the remaining 1/4? Stuck at
> the logo of start-up?
> 2. For this time, the three failed devices don't stuck at the logo of
> start-up, but enter in homescreen app without any icons showed. Is that
> correct?

Dear Rex,

1. Reproduce rate is 3/4. But, what happened to the remaining 1/4? Stuck at the logo of start-up?

ben.song: The connecting line between the device and power-off machine been disconnected.

2. For this time, the three failed devices don't stuck at the logo of start-up, but enter in homescreen app without any icons showed. Is that correct?

ben.song: It's right, I think there is probably some problem with database of homescreen for there is likeness problem in v1.4.

Thanks.

Comment 62

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

Hi Ben -

Let me recap again. So after you apply the patch from Comment#54, you CANNOT reproduce the original issue(original issue is device cannot power on successfully after the power drop test). Now with the patch from Comment#54, the device CAN power on after power drop test. But once you enter the idle screen, you find that all icons are gone.

Is the above statement correct? Just want to make sure we did make some progress here

Thanks

Comment 63

[ben.song]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #62)
> Hi Ben -
> 
> Let me recap again. So after you apply the patch from Comment#54, you CANNOT
> reproduce the original issue(original issue is device cannot power on
> successfully after the power drop test). Now with the patch from Comment#54,
> the device CAN power on after power drop test. But once you enter the idle
> screen, you find that all icons are gone.
> 
> Is the above statement correct? Just want to make sure we did make some
> progress here
> 
> Thanks

Dear Vance,

Yes, you are right, but we couldn't confirm the last problem fixed, so our QA is continue to do power-off test again to reproduce the last problem.

Thanks.

Comment 64

[ben.song]

Dear Rex, Vance,

I have uploaded the data.img of last poweroff problem device, which all icons of homescreen are gone.

ftp://ftp.spreadtrum.com/7715/1115619/userdata_COM3_new.img

username:mouzhi
password:mouZHI$$61

Thanks.

Comment 65

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

Thanks Ben, BTW, did you also have the files that Rex mentioned in Comment#58?

     - /data/local/permissions.sqlite
     - /data/b2g/mozilla/XXXXX.default/prefs.js

Thanks

Comment 66

[ben.song]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #65)
> Thanks Ben, BTW, did you also have the files that Rex mentioned in
> Comment#58?
> 
>      - /data/local/permissions.sqlite
>      - /data/b2g/mozilla/XXXXX.default/prefs.js
> 
> Thanks

Dear Vance,

In the file of userdata_COM3_new.img, you would get them.

Thanks.

Comment 67

[Rex Hung[:rhung]]

According to data in Comment#64, Permissions.sqlite are not corrupted and includes necessary app permissions. So the patches provided by this bug and bug#1124126 are effective and the tested devices can boot to homescreen.

About the problem of that all icons are disappeared in homescreen app, I found that homescreen database(/data/local/storage/persistent/9+f+app+++verticalhome.gaiamobile.org/idb) are not completed. It should be the reason why all icons are gone after power-off test. The following are the comparison between this symptom and normal case. Will create new bug to track this symptom independently later.

1. The size of 1444454539veemrothilca.sqlite are different.
2. icon picture files named by number(1~15) are not found in the tested devices.
================================================================================
All icons are gone:
drwxr-x---. 3 root root  4096  3月  6 23:51 ./
drwxr-x---. 3 root root  4096  3月  6 23:51 ../
drwxr-x---. 2 root root  4096  3月  6 23:51 1444454539veemrothilca/
-rw-------. 1 root root 38912  3月  6 23:51 1444454539veemrothilca.sqlite
-rw-------. 1 root root     0  3月  6 23:51 1444454539veemrothilca.sqlite-journal

Normal case:
drwxrwxr-x 2 root root  4096  3月 13 17:47 1444454539veemrothilca
-rw-r--r-- 1 root root 45056  3月 13 17:47 1444454539veemrothilca.sqlite
-rw-r--r-- 1 root root     0  3月 13 17:47 1444454539veemrothilca.sqlite-journal
-rw-r--r-- 1 root root  6465  3月 13 17:47 1444454539veemrothilca/1
-rw-r--r-- 1 root root  6991  3月 13 17:47 1444454539veemrothilca/10
-rw-r--r-- 1 root root  5887  3月 13 17:47 1444454539veemrothilca/11
-rw-r--r-- 1 root root  5410  3月 13 17:47 1444454539veemrothilca/12
-rw-r--r-- 1 root root  7602  3月 13 17:47 1444454539veemrothilca/13
-rw-r--r-- 1 root root  7770  3月 13 17:47 1444454539veemrothilca/14
-rw-r--r-- 1 root root  6531  3月 13 17:47 1444454539veemrothilca/15
-rw-r--r-- 1 root root  6308  3月 13 17:47 1444454539veemrothilca/2
-rw-r--r-- 1 root root  6893  3月 13 17:47 1444454539veemrothilca/3
-rw-r--r-- 1 root root  7492  3月 13 17:47 1444454539veemrothilca/4
-rw-r--r-- 1 root root 30401  3月 13 17:47 1444454539veemrothilca/5
-rw-r--r-- 1 root root  9795  3月 13 17:47 1444454539veemrothilca/6
-rw-r--r-- 1 root root 41429  3月 13 17:47 1444454539veemrothilca/7
-rw-r--r-- 1 root root 41818  3月 13 17:47 1444454539veemrothilca/8
-rw-r--r-- 1 root root 41397  3月 13 17:47 1444454539veemrothilca/9

Hi, Ben,
Could you also try to reboot the tested devices for several times and see if all icons can be displayed?
In my local check, all icons can be showed after rebooting device.

Comment 68

[ben.song]

(In reply to Rex Hung[:rhung] from comment #67)
> According to data in Comment#64, Permissions.sqlite are not corrupted and
> includes necessary app permissions. So the patches provided by this bug and
> bug#1124126 are effective and the tested devices can boot to homescreen.
> 
> About the problem of that all icons are disappeared in homescreen app, I
> found that homescreen
> database(/data/local/storage/persistent/9+f+app+++verticalhome.gaiamobile.
> org/idb) are not completed. It should be the reason why all icons are gone
> after power-off test. The following are the comparison between this symptom
> and normal case. Will create new bug to track this symptom independently
> later.
> 
> 1. The size of 1444454539veemrothilca.sqlite are different.
> 2. icon picture files named by number(1~15) are not found in the tested
> devices.
> =============================================================================
> ===
> All icons are gone:
> drwxr-x---. 3 root root  4096  3月  6 23:51 ./
> drwxr-x---. 3 root root  4096  3月  6 23:51 ../
> drwxr-x---. 2 root root  4096  3月  6 23:51 1444454539veemrothilca/
> -rw-------. 1 root root 38912  3月  6 23:51 1444454539veemrothilca.sqlite
> -rw-------. 1 root root     0  3月  6 23:51
> 1444454539veemrothilca.sqlite-journal
> 
> Normal case:
> drwxrwxr-x 2 root root  4096  3月 13 17:47 1444454539veemrothilca
> -rw-r--r-- 1 root root 45056  3月 13 17:47 1444454539veemrothilca.sqlite
> -rw-r--r-- 1 root root     0  3月 13 17:47
> 1444454539veemrothilca.sqlite-journal
> -rw-r--r-- 1 root root  6465  3月 13 17:47 1444454539veemrothilca/1
> -rw-r--r-- 1 root root  6991  3月 13 17:47 1444454539veemrothilca/10
> -rw-r--r-- 1 root root  5887  3月 13 17:47 1444454539veemrothilca/11
> -rw-r--r-- 1 root root  5410  3月 13 17:47 1444454539veemrothilca/12
> -rw-r--r-- 1 root root  7602  3月 13 17:47 1444454539veemrothilca/13
> -rw-r--r-- 1 root root  7770  3月 13 17:47 1444454539veemrothilca/14
> -rw-r--r-- 1 root root  6531  3月 13 17:47 1444454539veemrothilca/15
> -rw-r--r-- 1 root root  6308  3月 13 17:47 1444454539veemrothilca/2
> -rw-r--r-- 1 root root  6893  3月 13 17:47 1444454539veemrothilca/3
> -rw-r--r-- 1 root root  7492  3月 13 17:47 1444454539veemrothilca/4
> -rw-r--r-- 1 root root 30401  3月 13 17:47 1444454539veemrothilca/5
> -rw-r--r-- 1 root root  9795  3月 13 17:47 1444454539veemrothilca/6
> -rw-r--r-- 1 root root 41429  3月 13 17:47 1444454539veemrothilca/7
> -rw-r--r-- 1 root root 41818  3月 13 17:47 1444454539veemrothilca/8
> -rw-r--r-- 1 root root 41397  3月 13 17:47 1444454539veemrothilca/9
> 
> Hi, Ben,
> Could you also try to reboot the tested devices for several times and see if
> all icons can be displayed?
> In my local check, all icons can be showed after rebooting device.

Dear Rex,

I found all icons won't be showed after rebooting device, and i would know if 1444454539veemrothilca.sqlite is incomplete, the searchbar of homescreen would be gone ?

Thanks.

Comment 69

[ben.song]

Dear Rex,

While I removed all records of 1444454539veemrothilca.sqlite, I found all of icons not displayed but searchbar still displayed.I am confused with this problem, does this problem occur only because of this sqlite file ?

Thanks.

Comment 70

[ben.song]

Dear Rex,

Sorry,please ignore comment68,69, I have got a wrong phone, the problem as you said, should be some sqlite of homescreen has problem, have you got the sqlite file ?

I would raise a new bug for homescreen icons disappear.

Thanks.

Comment 71

[Rex Hung[:rhung]]

Hi, Ben,

Yes, I got the sqlite file of homescreen appp from the userdata image at Comment#64, and provided my observation at Comment#67.

Comment 72

[Steven Yang [:styang]]

The original symptom should be fixed by attachment:8571226 in bug:1124126. clear the blocking flag for this one and track the new power test issue bug:1143526

Comment 73

[Rex Hung[:rhung]]

Attachment: Bug-1115619-Use-a-preference-to-guarantee-app-permis.patch

Hi, Fabrice,

Could you help to review this patch or forward it to proper owners?
Thank you.

Comment 74

[[:fabrice] Fabrice Desré]

Comment on attachment 8579183 [details] [diff] [review]
Bug-1115619-Use-a-preference-to-guarantee-app-permis.patch

Review of attachment 8579183 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/apps/Webapps.jsm
@@ +669,5 @@
>  
>    loadAndUpdateApps: function() {
>      return Task.spawn(function() {
>        let runUpdate = AppsUtils.isFirstRun(Services.prefs);
> +      let loadAppPermission = Services.prefs.getBoolPref("app.permission.load");

rename the pref to dom.apps.reset-permissions

@@ +674,4 @@
>  
>        yield this.loadCurrentRegistry();
>  
> +      if (runUpdate || loadAppPermission != true) {

nit: can be written if (runUpdate || !loadAppPermission)

@@ +678,3 @@
>  
>          // Run migration before uninstall of core apps happens.
>          Services.obs.notifyObservers(null, "webapps-before-update-merge", null);        

not your fault, but if you could kill this trailing whitespace that would be nice ;)

Comment 75

[Rex Hung[:rhung]]

Attachment: Bug-1115619-Use-a-preference-to-guarantee-app-permission_v2.patch

Hi, Fabrice,

I have revised the patch according to your comment at Comment#74.
Could you help to review the patch again? Thank you.

Comment 76

[[:fabrice] Fabrice Desré]

Comment on attachment 8582333 [details] [diff] [review]
Bug-1115619-Use-a-preference-to-guarantee-app-permission_v2.patch

Review of attachment 8582333 [details] [diff] [review]:
-----------------------------------------------------------------

Please upload a patch with the all.js change and I'll push it to the tree. Thanks!

::: dom/apps/Webapps.jsm
@@ +669,5 @@
>  
>    loadAndUpdateApps: function() {
>      return Task.spawn(function() {
>        let runUpdate = AppsUtils.isFirstRun(Services.prefs);
> +      let loadAppPermission = Services.prefs.getBoolPref("dom.apps.reset-permissions");

this will throw if the pref doesn't exist, which can happen. Please add a default `false` value for that at https://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#4269

Comment 77

[Rex Hung[:rhung]]

Attachment: Bug-1115619-Use-a-preference-to-guarantee-app-permission_reviewed.patch

Comment 79

[ben.song]

Dear Rex, Yifan,

Recently we do poweroff test again, and bring up a problem, the appearance is like this bug, but after flash system.img and boot.img the appearance disappear and this device start up normally. In the problem of bug1115619 while we flash system.img and boot.img of debug version, the problem would still display.

So how could we analyse this problem，could you help me ? If or not some code do circulate process, and would not be break ?

In this version we apply two patches of you have given me and a patch yifan given me, in addition i add a patch for risk-averse of bug1143526 like this:

  function ItemStore(onsuccess) {
    var self = this;
    this.applicationSource = new ApplicationSource(this);
-   this.bookmarkSource = new BookmarkSource(this);
-   this.collectionSource = new CollectionSource(this);

-   this.sources = [this.applicationSource, this.bookmarkSource,
-                   this.collectionSource];
+   this.sources = [this.applicationSource];

Thanks.

Comment 80

[ben.song]

Dear Rex, Yifan,

In this reproduced problem, for before flash we couldn't get logs and after flash system.img and boot.img the appearance disappeared so the logs has no useless. So we don't know how to analyse it.

After apply risk-averse patch in comment 79, while flash all imgs normal there isn't no problem, So i think the problem isn't be brought up by this patch.

Thanks.

Comment 81

[yifan [:yifan][:yliao]]

Hi Ben,

After the investigation in bug 1143526, please neglect my patch. Instead, please use the patch Andrea provided in that bug and see if it works. Thanks.

Comment 82

[ben.song]

(In reply to yifan [:yifan][:yliao] from comment #81)
> Hi Ben,
> 
> After the investigation in bug 1143526, please neglect my patch. Instead,
> please use the patch Andrea provided in that bug and see if it works. Thanks.

Dear Yifan,

OK, we have applied the patch Andrea provided, and ready to do poweroff test to verify it.

Thanks.

Comment 83

[Rex Hung[:rhung]]

Hi, Ben,

I think it would be better to restart power-off test based on the problems we have found so far and created the patches for them. So, please run your test based on my two patches and attachment 8585445 [details] [diff] [review] in bug#1143526. If the problem is still reproduced, please provide userdata.img to us for further analysis.

Comment 84

[ben.song]

(In reply to Rex Hung[:rhung] from comment #83)
> Hi, Ben,
> 
> I think it would be better to restart power-off test based on the problems
> we have found so far and created the patches for them. So, please run your
> test based on my two patches and attachment 8585445 [details] [diff] [review]
> [review] in bug#1143526. If the problem is still reproduced, please provide
> userdata.img to us for further analysis.

Dear Rex,

Ok, I would do it today with three patches you said. 

Thanks.

Comment 85

[Rex Hung[:rhung]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4ed4fcb6f8f9

Comment 86

[Rex Hung[:rhung]]

Attachment: Bug-1115619-Use-a-preference-to-guarantee-app-permission_reviewed.patch

Addressed reviewer comment carry r+.

Comment 87

[Rex Hung[:rhung]]

Try result is green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8b68caa8fd52

Comment 88

[Rex Hung[:rhung]]

Attachment: Bug-1115619-Use-a-preference-to-guarantee-app-permission.patch

Addressed reviewer comment carry r+.

Comment 89

[Rex Hung[:rhung]]

Try result is green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=53bb1cdedf3f

Comment 90

[Rex Hung[:rhung]]

Attachment: [v2.1] Bug-1115619-Use-a-preference-to-guarantee-app-permission.patch

Comment 91

[Rex Hung[:rhung]]

Comment on attachment 8589546 [details] [diff] [review]
[v2.1] Bug-1115619-Use-a-preference-to-guarantee-app-permission.patch

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Potential bug.
User impact if declined: Device cannot boot up under some conditions.
Testing completed: Pass monkey test locally with v2.1.
Risk to taking this patch (and alternatives if risky): Low, only add an extra condition check to prevent failure.
String or UUID changes made by this patch: None

Comment 92

[Rex Hung[:rhung]]

Comment on attachment 8589545 [details] [diff] [review]
Bug-1115619-Use-a-preference-to-guarantee-app-permission.patch

As comment 91.

Comment 93

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/5c7899103bb8

Comment 94

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5c7899103bb8

Comment 95

[bhavana bajaj [:bajaj]]

rhung: does this issue also happen on flame?

Comment 96

[Rex Hung[:rhung]]

(In reply to bhavana bajaj [:bajaj] from comment #95)
> rhung: does this issue also happen on flame?

Yes, this is a common issue and I can reproduce the same symptom on flame.

Comment 97

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/12f606a4cddd

Comment 98

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3e3cbe35bce3

Comment 99

[Vincent Liu[:vliu]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/3e3cbe35bce3