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

Issue 877232 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Aug 28
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 0
Type: Bug-Regression



Sign in to add a comment

Cryptohome failures: can't sign in post-OOBE, can't enter public sessions

Project Member Reported by michae...@chromium.org, Aug 23

Issue description

CrOS: 10994.0.0
Chrome: 70.0.3530.0
ARC: 4971789

Cryptohome mounting fails and user session fails to start after OOBE. Public sessions can never be started.

FWIW, I've only tested on one device, which has been used in a number of enrollment scenarios including attestation-based Demo Mode enrollment. However, these repro steps are consistent after various methods of wiping the device and unlocking the TPM.

================================================================================

1. Starting at Welcome screen, progress through OOBE by selecting a network, accepting TOS, etc.
2. Sign in with a regular Google account
3. Click "Accept and continue" at sync confirmation screen
4. Accept ARC++ TOS

Expected: White screen with "Please wait" spinner appears very briefly, then user session starts and ARC++ apps begin installing. No cryptohome errors in logs.

Actual: White screen with "Please wait" spinner appears for a long time. ARC++ begins installing apps (according to notifications) but still at the the "Please wait" screen. The system tray has a "lock" button, but doesn't indicate an active user. 6/6 ARC++ apps finish installing. After 5 minutes, still at "Please wait" screen.

Clicking the system tray's "lock" button crashes Chrome. At that point, the sign-in screen comes up, and you can sign in normally.

Logs are attached. The interesting bits are displayed at the end.

================================================================================

If enrolling into a domain that enforces Public Sessions, the behavior is different. After enrollment, the sign-in screen shows the Public Session pod. However, trying to enter the Public Session has no effect other than adding the ARC++ Google Play notification to the system tray.

After rebooting, the "Sign in" dialog shows over the Public Session pod. Signing in doesn't work (because it's disabled for that domain), but the dialog can be dismissed to reveal the Public Session pod. Entering a Public Session still doesn't work, although I've gotten it to work very rarely by rebooting and trying repeatedly.

================================================================================

Everything works normally in the previous build on goldeneye:
CrOS: 10993.0.0
Chrome: 70.0.3524.2
ARC: 4966926

so the regression happened in that range.



From /var/log/chrome/chrome:

[1723:1723:0823/140315.637171:VERBOSE1:login_performer.cc(287)] Online login completion started.
[1723:1723:0823/140315.637325:VERBOSE1:cryptohome_authenticator.cc(811)] Resolved state to: 0
[1723:1723:0823/140315.638153:ERROR:device_event_log_impl.cc(159)] [14:03:15.638] Login: cryptohome_util.cc:131 GetKeyDataEx failed with no GetKeyDataReply extension in reply.
[1723:1723:0823/140315.641002:ERROR:device_event_log_impl.cc(159)] [14:03:15.640] Login: cryptohome_authenticator.cc:147 MountEx failed. Error: 32
[1723:1723:0823/140315.641040:ERROR:device_event_log_impl.cc(159)] [14:03:15.641] Login: cryptohome_authenticator.cc:971 Cryptohome failure: state(AuthState)=1, code(cryptohome::MountError)=32
[1723:1723:0823/140315.641059:VERBOSE1:cryptohome_authenticator.cc(811)] Resolved state to: 6
[1723:1723:0823/140318.197138:VERBOSE1:cryptohome_authenticator.cc(811)] Resolved state to: 13
[1723:1723:0823/140318.197197:VERBOSE1:cryptohome_authenticator.cc(701)] Login success
[1723:1723:0823/140318.197410:VERBOSE1:login_performer.cc(87)] LoginSuccess hash: 91ef7b46398eb6878c471fb52825972c5fc7e179
[1723:1723:0823/140318.197457:VERBOSE1:user_session_manager.cc(585)] Starting user session.


From /var/log/messages

2018-08-23T21:03:05.004515+00:00 WARNING cryptohomed[1516]: Could not load the device policy file.
...
2018-08-23T21:03:17.740841+00:00 WARNING cryptohomed[1516]: Could not load the device policy file.
2018-08-23T21:03:18.253259+00:00 INFO session_manager[1680]: [INFO:policy_key.cc(51)] No policy key on disk at /home/root/91ef7b46398eb6878c471fb52825972c5fc7e179/session_manager/policy/key
2018-08-23T21:03:18.268665+00:00 INFO cryptohomed[1516]: Putting a Pkcs11_Initialize on the mount thread.
2018-08-23T21:03:18.273725+00:00 INFO chapsd[1490]: Opening database in: /home/root/91ef7b46398eb6878c471fb52825972c5fc7e179/chaps
2018-08-23T21:03:18.304459+00:00 ERR session_manager[1680]: [ERROR:nss_util.cc(145)] Not checking key because size is 0
2018-08-23T21:03:18.323184+00:00 INFO chapsd[1490]: Importing opencryptoki objects.
2018-08-23T21:03:18.323237+00:00 WARNING chapsd[1490]: Did not find any opencryptoki objects to import.
2018-08-23T21:03:18.324236+00:00 WARNING session_manager[1680]: [WARNING:device_policy_service.cc(506)] Could not verify that owner key belongs to this user.
2018-08-23T21:03:18.324257+00:00 ERR session_manager[1680]: [ERROR:dbus_util.cc(13)] CreateError(...): Domain=dbus, Code=org.chromium.SessionManagerInterface.PubkeySetIllegal, Message=Could not verify that owner key belongs to this user.

 
logs.zip
182 KB Download
Temporarily assigning to alemate to help triage. Do these cryptohome messages tell you anything?

Forgot to mention, device is a caroline.
Cc: wzang@chromium.org
Able to repro on an eve. Seeing the same errors in /var/log/chrome/chrome.

Only difference is, the screen is stuck at Sync Consent (clicking the button does not work), instead of "Please wait" screen in the bug description (see video).

https://photos.app.goo.gl/SuphrqutXGfZJ7Lr8
Labels: -Pri-1 -Type-Bug Pri-0 Type-Bug-Regression
Thanks, Colin. Bumping to Pri-0.

Feedback report: https://listnr.corp.google.com/product/208/report/85617781501
I was not able to repro on nocturne. I an sign-in and I see Assistant dialog after accepting ARC++ ToS as a part of sign-in flow.
Status: Fixed (was: Untriaged)
It works after https://chromium-review.googlesource.com/1184542. Guess I assigned this bug to the right person!
I was able to repro this on Wolf (10994.0.0, 70.0.3530.0). The user sign-in flow got stuck at "You're signed in!" screen (same like c#2).

In case of enterprise enrollment, Public Session got stuck at ToS, Add user - same problem at "You're signed in!" screen.

Debug-logs attached.
debug-logs_20180823-153657.tgz
200 KB Download

Comment 7 Deleted

Status: Assigned (was: Fixed)
Google Chrome: 70.0.3530.0 Platform : 11005.0.0 Sona
Chrome stuck during user login and able to login again after reboot.

Attached logs and screenshot.
Screenshot 2018-08-27 at 2.55.23 PM.png
106 KB View Download
debug-logs_20180827-145257.tgz
506 KB Download
Please confirm if this needs a new bug. Thanks.!
 70.0.3530.0 is broken. The fix  https://chromium-review.googlesource.com/1184542  should be in 3532.

Do you have any problems with latest canary?
Status: Fixed (was: Assigned)
Status: Verified (was: Fixed)
Google Chrome: 70.0.3532.0 Platform: 11012.0.0 sona

Able to Sign-In as new user and can also enter the public session without any interruption.




Sign in to add a comment