CFM Devices rebooting and losing the enrollment not wiped |
||||
Issue descriptionChrome Version: 58.0.3029.112 OS: ChromeOS What steps will reproduce the problem? (1) enroll and configure a CfM device (2) after some random time the device will reboot and ask for enrollment What is the expected result? Once enrolled, device should stay enrolled. What happens instead? Device randomly loses enrollment. Timestamp of the issue (as said by the customer): approximately 2017-05-26 02:00 PST re-enrollment: 2017-05-26 09:40 PST the system partition is not wiped, we have old logs so it's not crbug.com/693439 or crbug.com/713343 or crbug.com/711821 and clobber has not been called # cat clobber.log 2016/11/07 07:50:42 UTC (preserve log): /sbin/clobber-state factory 2016/11/07 07:51:19 UTC (restore log): /sbin/clobber-state factory debug log files https://drive.google.com/open?id=0B01ZVp8vDQocS2VIOFhzTTNvNGM it's similar to crbug.com/685370 but I didn't find the message "ERROR:device_cloud_policy_store_chromeos.cc(234)] Device policy read on enrolled device yields no DM token! Status: 1." in the messages I see : 2017-05-26T09:40:18.584112-07:00 INFO session_manager[637]: [INFO:policy_key.cc(53)] No policy key on disk at /var/lib/whitelist/owner.key
,
Jun 1 2017
,
Jun 1 2017
Hi Bernie, can you please help us to triage or assign if needed?
,
Jun 1 2017
This has a message from https://bugs.chromium.org/p/chromium/issues/detail?id=361528 in it [731:731:0526/131048.033628:ERROR:profile_helper.cc(316)] ProfileHelper::GetProfileByUserUnsafe is called when |user|'s profile is not created. It probably means that something is wrong with a calling code. Please report in http://crbug.com/361528 if you see this message. Not sure if that is related. We also see a bunch of TPM messages: ... 2017-05-24T21:14:16.241183-07:00 INFO periodic_scheduler[20565]: crash_sender: running /sbin/crash_sender 2017-05-24T21:14:16.262572-07:00 INFO periodic_scheduler[20578]: crash_sender: job completed 2017-05-24T21:14:18.103417-07:00 INFO periodic_scheduler[20586]: cros-machine-id-regen: running /usr/sbin/cros-machine-id-regen -r periodic -t 21600 2017-05-24T21:14:18.123688-07:00 NOTICE cros-machine-id-regen[20600]: Not regenerating since we did so 11160 seconds ago. 2017-05-24T21:14:18.125984-07:00 INFO periodic_scheduler[20601]: cros-machine-id-regen: job completed 2017-05-24T22:01:25.221578-07:00 INFO kernel: [594505.702509] tpm_tis tpm_tis: command 0x65 (size 20) returned code 0x0 2017-05-24T22:01:25.251555-07:00 INFO kernel: [594505.732414] tpm_tis tpm_tis: command 0x65 (size 22) returned code 0x0 2017-05-24T22:01:25.281574-07:00 INFO kernel: [594505.762702] tpm_tis tpm_tis: command 0x65 (size 22) returned code 0x0 ... I think this may actually be a dupe of https://bugs.chromium.org/p/chromium/issues/detail?id=693439 even though it has logs, the loss of logs is not necessarily related to the root problem here.
,
Jun 1 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by marcore@chromium.org
, Jun 1 2017