No enrollment screen |
||||||||||||
Issue descriptionChrome Version: (copy from chrome://version) 56.0.2924.110 (64-bit) OS: (e.g. Win7, OSX 10.9.5, etc...) Chrome OS What steps will reproduce the problem? Wiped one of our chromebooks (both powerwash and the esc-refresh-power button method). When the chromebook starts back up it goes through the normal, expected screens--connect to the wifi, accept TOS, checks for updates. When I get to the login screen and try to enroll it with ctrl-alt-e nothing happens. No enrollment screen. Literally nothing happens when pressing the keys. What is the expected result? The enrollment screen should appear What happens instead? No enrollment screen The keys all work, verified by logging in and using them, so I know the keyboard is good. I wiped it again, still nothing. I then deprovisioned the device and removed it from my google domain and tried again, same thing. I cannot get the enrollment screen to come up.
,
Mar 27 2017
,
Mar 27 2017
Please let us know about the Chrome OS version on the device, and attach the logs that can be taken from chrome://net-internals -> Chrome OS -> Store Debug Logs. Thank you,
,
Mar 27 2017
Log attached as requested. OS version is: 56.0.2924.110 (64-bit)
,
Mar 27 2017
Thank you Edward, I will take a look at the logs. Could you please also attach a screenshot after you press ctrl+alt+e for me to check what the screen looks like?
,
Mar 27 2017
Unable to get a screen shot at that point (it doesn't save the file since no one is logged in), so I've attached a photo of the screen. What you see is the screen where I press ctrl-alt-E and should get an enrollment, but literally nothing happens when pressing the keys.
,
Mar 27 2017
Yes, the screen is not for forced re-enrollment and this is consistent with what I see in the logs. If the device would be still enrolled, you could force re-enrollment from admin and then the device would ask to be enrolled back after powerwash/recovery. But if I understood correctly it's deprovisioned already. I will try to check more in the logs, to see if I can find some suspect candidate for a bug here.
,
Mar 27 2017
,
Mar 27 2017
Looks like this is in CrOS, please add other applicable OS if needed.
,
Jul 5 2017
,
Jul 26 2017
I've managed to get a similar behavior by the following actions: - Enroll the device - Delete install_attributes files - Boot, and get normal sign in window. Ctrl+Alt+E has no effect. The install attributes are not corrupted on the device described in the ticket, according to the logs but for now I will add logs for the scenario that can be reproduced. I think the device described in the ticket falls in the same code path, where it considers that the owner tries to re-enroll an enrolled device. Specifically function ExistingUserController::OnEnrollmentOwnershipCheckCompleted receives status == DeviceSettingsService::OWNERSHIP_TAKEN and trusted_status is TRUSTED.
,
Jul 27 2017
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by igorcov@chromium.org
, Mar 27 2017