New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 764050 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

ChromeOS issue: Chromebook unexpectedly resetted itself

Project Member Reported by ykrychala@google.com, Sep 11 2017

Issue description

ChromeOS version: 60.0.3112.80
ChromeOS device model: ASUS Chromebook C300
Case#: 13595597

Description: 
When customer has started Chromebooks this morning, 20 - 30 of them had resetted (wiped) themselves and the customer had to setup the network and re-enroll the devices once again. 
For the devices that has been re-enrolled, the OS version were downgraded to v53. 


Steps to reproduce: 
1. Start a Chromebook 
2. Find that it has been wiped (wiped itself randomly) 

Current Behavior / Reproduction: 
Chromebooks were wiped and customer had to re-enroll them once again. 

Expected Behavior: 
Chromebooks to not wipe itself all of a sudden. 


Drive link to logs: 
https://drive.google.com/open?id=0B9JNylCOuXiuVXdVbjBESlhtMWc


 
Cc: vkasatkin@google.com
Labels: M-60
Owner: keta...@chromium.org
Hi ketakid@, could you please help to triage this issue?
Customer provided debug logs from another device affected by the issue:

https://drive.google.com/open?id=0B9JNylCOuXiuTWxyY2tKOU9rWnM
Owner: josa...@chromium.org
josafat@, can you please look into this issue? Customer is asking for update
Components: Enterprise
josafat@, ketakid@ - any updates for the customer?
Cc: ketakid@google.com
Cc: keta...@chromium.org
Cc: xiy...@chromium.org
Owner: ----
I see issues finding the policy in the logs 

2017-09-11T12:28:49.311947+09:00 INFO session_manager[12921]: [INFO:policy_key.cc(54)] No policy key on disk at /home/root/b5927968578872ab043dc1457e2b077b7ea479f7/session_manager/policy/key

There were few fixes for enrollment in M61 (e.g. issue 756191)

Can you check if customer is still having this issue with new M61 Stable?

Adding Xiyuan to comment too

Comment 9 by xiy...@chromium.org, Oct 19 2017

Similar to issue 693439 where stateful partition is wiped due to unclean shutdown although I am not sure how a device with battery could get power failure. Not sure why the device rolled back to M53 though.

For the log in the original report, from events.log and clobber.log, the wipe happened on 8/26 between boot 1789 and 1790, due to corrupted stateful partition.

10 | 2017-08-26 13:59:25 | System boot | 1789
11 | 2017-08-26 13:59:25 | SUS Power Fail
12 | 2017-08-26 13:59:25 | Wake Source | Power Button | 0
13 | 2017-08-26 13:59:39 | Kernel Event | Clean Shutdown
14 | 2017-08-26 13:59:39 | ACPI Enter | S5

clobber.log:
2017/08/26 16:59:30 UTC (repair): /dev/mmcblk0p1 Self-repair corrupted stateful partition

15 | 2017-08-27 01:59:25 | System boot | 1790
16 | 2017-08-27 01:59:25 | SUS Power Fail
17 | 2017-08-27 01:59:25 | Wake Source | Power Button | 0


For the log in #2, clobber.log show the wipe happened at 

2017/08/27 01:58:03 UTC (repair): /dev/mmcblk0p1 Self-repair corrupted stateful partition

But events.log does not have the relevant boot info.

I'm checking with customer if devices are working fine on M61
Labels: Enterprise-Triaged
Customer closed the case, nothing is needed at the moment. Closing the bug
Status: WontFix (was: Unconfirmed)

Sign in to add a comment