968250 - Keon boots to black screen

Status: RESOLVED DUPLICATE of bug 967967

(Firefox OS Graveyard :: General, defect)

Description

[Dale Harvey (:daleharvey)]

Vivien suggested that disabing MOZ_NUWA_PROCESS=1 fixes this

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Dale Harvey (:daleharvey) from comment #0)
> Vivien suggested that disabing MOZ_NUWA_PROCESS=1 fixes this

Is that a guess, or did it fix the problem?

So what's special about the Keon?  Nuwa works on several other devices.

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #1)
> (In reply to Dale Harvey (:daleharvey) from comment #0)
> > Vivien suggested that disabing MOZ_NUWA_PROCESS=1 fixes this
> 
> Is that a guess, or did it fix the problem?

It solves the issue for me and a few others.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Ok.  I'm not convinced we should back Nuwa out for this because the Keon is not a tier 1 platform, but it's fabrice's call.

Comment 4

[Dale Harvey (:daleharvey)]

So flashing current gecko + gaia, I dont get a black homescreen, I get the wallpaper and status bar but no homescreen

Comment 5

[Dale Harvey (:daleharvey)]

the keon and the peak are what virtually all devs are using, they are my only option (my hamachi is bricked)

Comment 6

[Francesco Lodolo [:flod]]

(In reply to Dale Harvey (:daleharvey) from comment #5)
> the keon and the peak are what virtually all devs are using, they are my
> only option (my hamachi is bricked)

Add all l10n people to the list (only Keons) ;-)

Comment 7

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #3)
> Ok.  I'm not convinced we should back Nuwa out for this because the Keon is
> not a tier 1 platform, but it's fabrice's call.

We can't introduce development workflow blockers here. That's going to cause us more problems to resolving blockers, not help resolve them.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Francesco Lodolo [:flod] from comment #6)
> (In reply to Dale Harvey (:daleharvey) from comment #5)
> > the keon and the peak are what virtually all devs are using, they are my
> > only option (my hamachi is bricked)
> 
> Add all l10n people to the list (only Keons) ;-)

I'm blocking this then. That's a development blocker + localization tester blocker here.

Comment 9

[Dale Harvey (:daleharvey)]

Attachment: Backout NUWA

Fixes keon booting to the homescreen for me

Comment 10

[[:fabrice] Fabrice Desré]

Certainly not a release blocker. I'll write a patch to enable nuwa on a pref instead of a build flag - that will unblock people until someone figures out what's wrong on these devices.

And I'm still puzzled by hearing that some can't test/dev on production hardware. How hard is that to flash a pvt eng build and go from there?

Comment 11

[[:fabrice] Fabrice Desré]

Comment on attachment 8370850 [details] [diff] [review]
Backout NUWA

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

Sorry, but no. (and you would need to disable tests also to do it properly).

Comment 12

[Tony Chung [:tchung]]

(In reply to Jason Smith [:jsmith] from comment #8)
> (In reply to Francesco Lodolo [:flod] from comment #6)
> > (In reply to Dale Harvey (:daleharvey) from comment #5)
> > > the keon and the peak are what virtually all devs are using, they are my
> > > only option (my hamachi is bricked)
> > 
> > Add all l10n people to the list (only Keons) ;-)
> 
> I'm blocking this then. That's a development blocker + localization tester
> blocker here.

This must be device dependent?   We have multiple reports that the latest gaia/gecko flash on a Buri device is working just fine.   (well, minus the missing keyboard - bug 967587).   But the build launches and is usable.

My environment:
Device    TCL Buri device, master branch
Gaia      ac94739a01d64e86890f54f1795ff8e82b8e7939
Gecko     https://hg.mozilla.org/mozilla-central/rev/1f170f9fead0
BuildID   20140205040203
Version   30.0a1
ro.build.version.incremental=324

Comment 13

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #10)
> Certainly not a release blocker. I'll write a patch to enable nuwa on a pref
> instead of a build flag - that will unblock people until someone figures out
> what's wrong on these devices.

No. People not being able to do their job is deemed as a workflow blocker, which is treated as a blocker for the release.

> 
> And I'm still puzzled by hearing that some can't test/dev on production
> hardware. How hard is that to flash a pvt eng build and go from there?

That's not new news. l10n testers don't use pvt builds. Many devs here utilize a keon for development.

Comment 14

[Tony Chung [:tchung]]

(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to Fabrice Desré [:fabrice] from comment #10)
> > Certainly not a release blocker. I'll write a patch to enable nuwa on a pref
> > instead of a build flag - that will unblock people until someone figures out
> > what's wrong on these devices.
> 
> No. People not being able to do their job is deemed as a workflow blocker,
> which is treated as a blocker for the release.
> 
> > 
> > And I'm still puzzled by hearing that some can't test/dev on production
> > hardware. How hard is that to flash a pvt eng build and go from there?
> 
> That's not new news. l10n testers don't use pvt builds. Many devs here
> utilize a keon for development.

After talking to fabrice, the right plan at this time is to checkin the patch to flip a pref as recommended.   backing out nuwa will cause our partners to go awry.  meanwhile, i believe someone will need to investigate they regression and apply a patch in parallel to this patch.

this also isnt affecting every device out there, but more investigation is needed. 

l10n testers (and others that dont use pvt or build their own builds), will already need to reflash their device to fix this.   A dev pref in this case wont matter since they cant see it on the screen.   Once this pref patch lands, someone will need to tell GP to pick up the fix and apply it to their 1.4 nightlies.

Those affected on the Keon, stay posted on this bug and reflash when a patch has been submitted.

Comment 15

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I think this might be a duplicate of bug 967967 — there's a one-line patch on that bug that should fix this (without disabling Nuwa or seccomp), if I'm right.

Also, the patch from bug 945498 will change this from “black screen” to an endless sequence of crash notifications (again, if I'm right that it's bug 967967).

Comment 16

[[:fabrice] Fabrice Desré]

(In reply to Jed Davis [:jld] from comment #15)
> I think this might be a duplicate of bug 967967 — there's a one-line patch
> on that bug that should fix this (without disabling Nuwa or seccomp), if I'm
> right.
> 
> Also, the patch from bug 945498 will change this from “black screen” to an
> endless sequence of crash notifications (again, if I'm right that it's bug
> 967967).

Oh, because keons are the only ones that have seccomp... makes sense!

Anyone with a keon that can test the patch in bug 967967 ?

Comment 17

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Also, if it's bug 967967, there should be evidence in logcat, like this:

E/Sandbox (  600): seccomp sandbox violation: pid 600, syscall 214, args 10600 0 32768 1 600 10584.  Killing process.
E/Sandbox (  610): seccomp sandbox violation: pid 610, syscall 214, args 10610 0 32768 1 610 10594.  Killing process.
E/Sandbox (  620): seccomp sandbox violation: pid 620, syscall 214, args 10620 0 32768 1 620 10604.  Killing process.
E/Sandbox (  630): seccomp sandbox violation: pid 630, syscall 214, args 10630 0 32768 1 630 10614.  Killing process.
E/Sandbox (  640): seccomp sandbox violation: pid 640, syscall 214, args 10640 0 32768 1 640 10624.  Killing process.
E/Sandbox (  650): seccomp sandbox violation: pid 650, syscall 214, args 10650 0 32768 1 650 10634.  Killing process.

(With a bunch of other stuff between each Sandbox line; grepping for "Sand" may help.)

Comment 18

[Jason Smith [:jsmith]]

Unblocking this as the dependent bug is tracking the developer workflow issue.

Comment 19

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Fabrice Desré [:fabrice] from comment #16)
> Oh, because keons are the only ones that have seccomp... makes sense!

Eventually, the emulator will get seccomp (meaning that TBPL will test it), but it's currently blocked by some problems with WebRTC; see bug 932104 and its dependencies.

> Anyone with a keon that can test the patch in bug 967967 ?

Confirmed.