Closed Bug 1075401 Opened 11 years ago Closed 10 years ago

[Flame] Device is stuck on fox logo after flashing my own Gaia build

Categories

(Firefox OS Graveyard :: Gaia, defect)

Product:
Firefox OS Graveyard
Component:
Gaia
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: flod, Unassigned)

Details

Attachments

(3 files)

Logcat with v123
95.54 KB, text/plain
Details
Logcat with v180
117.20 KB, text/plain
Details
Logcat with v184
162.83 KB, text/plain
Details
Attached file Logcat with v123 —
It all started with v180: OTA failed because of missing space, so I had to reinstall v180 and shallow flash Gaia+Gecko with B2G-flash-tools (build from 20140929). From that moment I haven't been able to flash my own Gaia on the device. This is the command I'm using make clean && PRODUCTION=1 make install-gaia MAKECMDGOALS=production MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,it LOCALES_FILE=locales/languages_all.json LOCALE_BASEDIR=locales/ DEVICE_DEBUG=1 So I tried to go back to v123 since it all worked fine: installed, shallow flash of Gaia+Gecko, tried to install my own build of Gaia and I'm stuck again on a frozen fox. Gaia-Rev a23d2c490b39c4699c9375e25c4acdf396a2fa85 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/2ae57957e4bb Build-ID 20140930160207 Version 35.0a1 Device-Name flame FW-Release 4.3 FW-Incremental 110 FW-Date Fri Jun 27 15:57:58 CST 2014 Bootloader L1TC00011230 Attached Logcat with v123. Now I'll try to install v180 again and attach its logcat.
Attached file Logcat with v180 —
And here's the logcat with v180. Completely different, but same result (stuck on frozen fox). Gaia-Rev a23d2c490b39c4699c9375e25c4acdf396a2fa85 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/2ae57957e4bb Build-ID 20140930160207 Version 35.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental 27 FW-Date Thu Sep 4 14:59:02 CST 2014 Bootloader L1TC10011800
> E/QCOMKeyMaster( 1028): Loading keymaster app failied > E/keystore( 1028): could not open keymaster device in keystore (Operation not permitted) This looks a bit suspect, and I am also seeing this when in my logcat. I don't really know who to ask here, but going to needinfo? a few people from the dev-b2g thread. This seems pretty serious as multiple people now have useless flames, so we should get someone looking into this asap.
Flags: needinfo?(tchung)
Flags: needinfo?(kchen)
Flags: needinfo?(asa)
Adding that the make command in comment 0 doesn't work anymore even on a Keon. Makes we wonder what we changed. Gaia-Rev 1bdf7c01628fced0eaccf9e9b4f8a562cf4369f8 Gecko-Rev e1a3c6bb17c7f69fcc08934aa20674f0d421403e Build-ID 20140925223104 Version 35.0a1 Device-Name keon FW-Release 4.0.4.0.4.0.4 FW-Incremental 120 FW-Date Thu Sep 25 22:11:23 CEST 2014
Some more data with Flame v180 make clean && PRODUCTION=1 make install-gaia MAKECMDGOALS=production MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,it LOCALES_FILE=locales/languages_all.json LOCALE_BASEDIR=locales/ DEVICE_DEBUG=1 https://github.com/mozilla-b2g/gaia/commit/188d26b7b0aec03d7695e08da38baddfe43f6da9 doesn't work https://github.com/mozilla-b2g/gaia/commit/9df5a4972915e6804efbfd2078c51d35c69c04f0 works (as other changesets before that) So this specific issue seems to be related to bug 1056194. Does it make any sense? pvt builds in my case are working fine
Flags: needinfo?(mdas)
I cannot reproduce this, using today's build and Sept 29th's build. Which build are you using? Have you used make really-clean to get rid of your older b2g sdk? After shallow flashing the gaia/gecko using this build from the 29th: ttps://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-eng/2014/09/2014-09-29-16-02-03/, and using the commit you say works (https://github.com/mozilla-b2g/gaia/commit/9df5a4972915e6804efbfd2078c51d35c69c04f0 works, my flame goes into a non-working state. After I run: make clean && PRODUCTION=1 make install-gaia MAKECMDGOALS=production MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,it LOCALES_FILE=locales/languages_all.json LOCALE_BASEDIR=locales/ DEVICE_DEBUG=1 It goes black and is nonresponsive. After rebooting, it gets stuck on the "Thundersoft" screen. I get the same results if I shallow gecko/gaia flash today's m-c build. I don't think my commit is the one that broke it, since the previous commit doesn't leave my phone in a good state either. One thing I noticed was if I ran "make really-clean && PRODUCTION=1 make install-gaia" instead of using your flags, then both these commits produce normal, working states. Perhaps something changed relative to the flags you're using? Also, I started seeing this ominous chunk of logcat after running make install-gaia with those flags: I/Gecko ( 292): ************************* I/Gecko ( 292): A coding exception was thrown and uncaught in a Task. I/Gecko ( 292): I/Gecko ( 292): Full message: TypeError: invalid 'in' operand aManifest I/Gecko ( 292): Full stack: this.DOMApplicationRegistry.updateDataStore@resource://gre/modules/Webapps.jsm:701:1 I/Gecko ( 292): this.DOMApplicationRegistry.updateDataStoreForApp<@resource://gre/modules/Webapps.jsm:381:1 I/Gecko ( 292): TaskImpl_run@resource://gre/modules/Task.jsm:314:40 I/Gecko ( 292): Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:865:23 I/Gecko ( 292): this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:7 I/Gecko ( 292): this.DOMApplicationRegistry.doGetList@resource://gre/modules/Webapps.jsm:1382:7 I/Gecko ( 292): this.DOMApplicationRegistry.receiveMessage@resource://gre/modules/Webapps.jsm:1199:1 I/Gecko ( 292): I/Gecko ( 292): ************************* I/Gecko ( 292): ************************* I/Gecko ( 292): A coding exception was thrown and uncaught in a Task. I/Gecko ( 292): I/Gecko ( 292): Full message: TypeError: invalid 'in' operand aManifest I/Gecko ( 292): Full stack: this.DOMApplicationRegistry.updateDataStore@resource://gre/modules/Webapps.jsm:701:1 I/Gecko ( 292): this.DOMApplicationRegistry.updateDataStoreForApp<@resource://gre/modules/Webapps.jsm:381:1 I/Gecko ( 292): TaskImpl_run@resource://gre/modules/Task.jsm:314:40 I/Gecko ( 292): Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:865:23 I/Gecko ( 292): this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:7 I/Gecko ( 292): this.DOMApplicationRegistry.doGetList@resource://gre/modules/Webapps.jsm:1382:7 I/Gecko ( 292): this.DOMApplicationRegistry.receiveMessage@resource://gre/modules/Webapps.jsm:1199:1 I/Gecko ( 292): I/Gecko ( 292): ************************* W/GeckoConsole( 292): [JavaScript Error: "invalid 'in' operand aManifest" {file: "resource://gre/modules/Webapps.jsm" line: 701}] I/VolumeManager( 292): SetUnmountRequested for volume sdcard to 0 CanBeMounted = 1 I/VolumeManager( 292): SetMountRequested for volume sdcard to 0 CanBeMounted = 1 maybe that helps
Flags: needinfo?(mdas)
(In reply to Malini Das [:mdas] from comment #5) > I cannot reproduce this, using today's build and Sept 29th's build. Which > build are you using? Have you used make really-clean to get rid of your > older b2g sdk? I'm using today's build from pvt. Gaia-Rev 77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/2ae57957e4bb Build-ID 20140930160207 Version 35.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental 27 FW-Date Thu Sep 4 14:59:02 CST 2014 Bootloader L1TC10011800 For me: * pvt build works fine (it seems stuck for 5 seconds on the fox, but then it goes past it and reaches home screen) * flash with the command always breaks the phone on the fox logo with the moving tail (tail remains frozen and doesn't move past that). Never got stuck on the ThunderSoft splash screen. This morning I tried at least 5 or 6 flashes before reaching your commit. All commits before that worked, it stopped working with yours. Now I tried "make really-clean" but it doesn't change: * flash master, stuck on the fox * git checkout 9df5a4972915e6804efbfd2078c51d35c69c04f0 and then flash, works just fine
Tried again with current master in this order > make clean && PRODUCTION=1 make install-gaia MAKECMDGOALS=production frozen screen > make really-clean && PRODUCTION=1 make install-gaia stuck on the ThunderSoft logo for about 10 seconds, then frozen screen > git checkout 9df5a4972915e6804efbfd2078c51d35c69c04f0 > make clean && PRODUCTION=1 make install-gaia MAKECMDGOALS=production MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,it LOCALES_FILE=locales/languages_all.json LOCALE_BASEDIR=locales/ DEVICE_DEBUG=1 phone boots properly > git checkout master > make clean && make reset-gaia phone boots properly, wiped > make clean && PRODUCTION=1 make install-gaia MAKECMDGOALS=production MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,it LOCALES_FILE=locales/languages_all.json LOCALE_BASEDIR=locales/ DEVICE_DEBUG=1 and this time it worked I'll try more tests to see if it sticks. Did it need a reset-gaia after make really-clean?
Does it help to retrigger app registration by using "./edit-prefs.sh" to edit the gecko.mstone pref (just change it to anything you want and then let the phone reboot). ("gecko.mstone" is the poorly named pref that really means "if the Gecko milestone is not this, we'll rerun app registration".)
Interestingly enough, after comment 7 I couldn't block my phone anymore when flashing my Gaia build. So I flashed from pvt and removed my profile (phone booted correctly), then flashed again my build of Gaia, and now I'm stuck again. With "adb shell df" I don't see anything strange (like running out of space). (In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #8) > Does it help to retrigger app registration by using "./edit-prefs.sh" to > edit the gecko.mstone pref (just change it to anything you want and then let > the phone reboot). ("gecko.mstone" is the poorly named pref that really > means "if the Gecko milestone is not this, we'll rerun app registration".) edit-prefs.sh I downloaded it from mozilla-b2g/B2G, I only have Gaia local. Changed gecko.mstone from "35.0a1" to "30", phone doesn't boot. What I noticed is that the fox remains frozen for like a minute, then starts again, then frozen, and keep looping like that. So I run again > make clean && make reset-gaia This time the phone doesn't start and it's not even visible to adb, so I'm back to flashing v180 with fastboot.
I am seeing the exact same thing on my Flame and this is hampering my productivity big time. I'm adding Francis/Wesley to the ni? party to see if they know about this issue or could connect us with someone to help us debug this.
Flags: needinfo?(wehuang)
Flags: needinfo?(frlee)
not sure if this is obvious, but you guys are doing ./config.sh flame-kk right? v180 is kk, so if you're just ./config.sh flame, it will break since that was for jB. If yes, then i'm out of ideas right now.
Flags: needinfo?(tchung)
I'm not building Gecko at all. I'm using B2G-flash-tools to install from pvt Gecko and Gaia, then I'm only building and flashing Gaia to the device.
Flags: needinfo?(kchen)
the similar issue was reported due to some people flashed JB gaia/gecko (from pvt server) on KK base image (v180 or above). at the time, there's no KK gaia/gecko on our pvt server. Since last week, we finally have KK gaia/gecko exists on pvt. https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-flame-kk-eng/ Francesco, would you mind to try v184 as base image and flash kk gaia/gecko from pvt again?
Flags: needinfo?(frlee)
Is v184 a typo? Note that I'm already flashing master (not aurora) flame-kk builds, and I don't have issues with that (I think Kevin has, or at least had). For me issue comes when I try to flash my own Gaia after a shallow-flash of pvt builds.
no, v184 is the latest kk v2.0 base image we received from T2M. Wesly has shared to b2g-internal last week. this v184 includes QC's v2.0 CS, that's the main reason i suggest to use it as base image from now on.
(In reply to Francis Lee [:frlee] from comment #15) > no, v184 is the latest kk v2.0 base image we received from T2M. Wesly has > shared to b2g-internal last week. > this v184 includes QC's v2.0 CS, that's the main reason i suggest to use it > as base image from now on. No access to b2g-internals (actually, no clue of what it is), so I wasn't even aware of a v184 version.
Flashed v184, then flashed mozilla-central-flame-kk with B2G-flash-tool and without keeping user profile Gaia-Rev 83f495a1c12687970f7f2840c2729795c4b88177 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/0ed32d9a42d6 Build-ID 20141005160202 Version 35.0a1 Device-Name flame-kk FW-Release 4.4.2 FW-Incremental 34 FW-Date Tue Sep 30 14:06:36 CST 2014 Bootloader L1TC00011840 Phone works. Flashed my own Gaia, and stuck again on the logo. Tried to run > make really-clean && make reset-gaia Stuck on the logo and not even visible in adb, so I need to start in fastboot mode and start it all over again.
Attached file Logcat with v184 —
Ditched completely with Gaia clone, started from scratch (v184, shallow flash, my Gaia build) and this is the logcat.
I finally managed to flash Gaia on the device (running v184). At some point while fighting with my flame I created a minimal json file, with only 2 locales, to use as LOCALES_FILE. So I was recalling from history that flash command instead of using locales_all.json Apparently make creates the build but it dies during boot, without giving any clue in the logcat (or at least any clue that I could understand). So my problem was probably fixed by moving to v184 and running "make really-clean && make reset-gaia", the error I was seeing after that was due to the missing LOCALES_FILE. That doesn't completely explain why the phone was stuck in comment 17 though.
FYI, there is v188 released to b2g-internal last Friday.
Flags: needinfo?(wehuang)
I haven't seen this recently, clearing the ni? I asked for previously.
Flags: needinfo?(asa)
Haven't seen this in a while, marking as WORKSFORME.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: