for debug-logs_20180313-132234.tgz

Lots of angry log lines in ui.20180313-132100 ending w/

[922:922:0313/132103.658501:ERROR:CONSOLE(10001)] "TypeError: Cannot read property 'ignoreAccelerators' of null
    at Oobe.handleAccelerator (chrome://oobe/login.js:2186:30)
    at Function.Oobe.handleAccelerator (chrome://oobe/login.js:9590:24)
    at <anonymous>:1:12", source: chrome://oobe/login.js (10001)
[922:922:0313/132103.658558:ERROR:CONSOLE(2186)] "Uncaught TypeError: Cannot read property 'ignoreAccelerators' of null", source: chrome://oobe/login.js (2186)
[922:922:0313/132104.290478:ERROR:app_launch_controller.cc(517)] Kiosk launch failed, error=7

and in the previous boot where I believe things worked,

2018-03-13T02:18:06.505346-07:00 ERR chrome[859]: [859:859:0313/021806.505316:ERROR:kiosk_profile_loader.cc(113)] Cryptohome is mounted before launching kiosk app.


Which led me to this bug as a possible dupe crbug.com/773816

Those error should not cause the black screen.

JS error is transient. "error=7" means user cancel that implies the accelerator did get through after the JS error.

The cryptohome error is emitted wrongly caused by a refactorying that accidentally flipped the logic. If the error is true, CfM should not be launched.

I don't see the evidence of black screen from the logs though.
The following lines in powerd.20180313-021801 looks like there is something wrong because user pressed power button:

[0313/130948:INFO:activity_logger.cc(20)] Audio activity stopped
[0313/131957:INFO:daemon.cc(524)] Power button down

But I don't see problems around that timestamp in messages or chrome logs.

looking into the logs, I've found out that this device has KINGSTON RBU-SNS4151S316GG2.
This SSD have some issue, infact there is a known issue, but it's when the device loses power:
https://bugs.chromium.org/p/chromium/issues/detail?id=693439#c65 and 
https://support.google.com/chromedevicesformeetings/answer/6063095?hl=en&ref_topic=3341452&visit_id=1-636577546116132989-1540928712&rd=1
"Chromebox for meetings resets when it loses power"

could it be the same for this one ?

+Gwendal for any known power loss issue w/ Kingston storage.

From the video, it looks like kiosk app is launched but then the screen goes black (looks like the display is powered off). But I don't see how/why this happened in the attached logs.

Katie can you comment on how these types of issues normally get resolved.  Is there an internal team w/ access & expertise to repro

Tove - can you advise?

I don't know.

I was under the impression that CfMs are not supposed to go to sleep at all?

Mats, do you have any insights into what's going on here?

They aren't, but we've had bugs lately where they do....

I looked through all of the powerd logs from https://drive.google.com/open?id=1HHg5ZvRpyJotebPj__C6ACvWTL0yTVa7, and there's only one point where the system suspended (i.e. entered S3):

[0224/022515:INFO:state_controller.cc(89)] Dimming screen after 7m
[0224/022515:INFO:display_power_setter.cc(67)] Asking DisplayService to dim the display in software
[0224/022615:INFO:state_controller.cc(89)] Turning screen off after 8m
[0224/022615:INFO:display_power_setter.cc(81)] Asking DisplayService to turn all displays off
...
[0224/024815:INFO:state_controller.cc(953)] Ready to perform idle action (suspend) after 30m
[0224/024815:INFO:suspender.cc(399)] Starting request 52953089
...
[0224/024815:INFO:suspender.cc(470)] Starting suspend
[0224/024815:INFO:main.cc(237)] Running "/usr/bin/powerd_setuid_helper --action=suspend  --suspend_wakeup_count_valid --suspend_wakeup_count=1"
[0306/140620:INFO:daemon.cc(692)] powerd_suspend returned 0
[0306/140620:INFO:suspender.cc(426)] Finishing request 52953089 successfully

The system had just booted at 02:17:59 in this instance (it looks like there's an automated reboot around then every night), and Chrome never sent a "don't suspend" policy to powerd, suggesting that the CfM app wasn't running.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.