Enrollment doesn't work |
|||||||||||
Issue descriptionVersion: 54.0.2792.0 8582 (veyron-minnie-cheets) OS:ChromeOS What steps will reproduce the problem? (1) Download recovery image https://cros-goldeneye.corp.google.com/chromeos/console/listBuild?boards=veyron-minnie-cheets&milestone&chromeOsVersion&chromeVersion&startTimeFrom&startTimeTo#/ (I used dev version 54.0.2792.0 8582) (2) Recovery the device (Esc-F3-Power, etc.). (3) Try to enroll the device. What is the expected output? Error message: "Oops, The system failed to establish the device installation-time attributes lock." What do you see instead? Enrolled device The enrollment works for 52.0.2743.64 beta. Please use labels and text to provide additional information.
,
Jul 13 2016
The earliest broken image is 8564.0.0 54.0.2791.0
,
Jul 13 2016
,
Jul 13 2016
According to peletskyi@, 8530.13.0 53.0.2785.15 is known-good.
,
Jul 13 2016
Candy 8564 is also broken.
,
Jul 13 2016
For Candy 8561 works, but 8562 doesn't.
,
Jul 13 2016
Steve, from looking at the bisect [1], could that be related to your change [2]? [1] https://crosland.corp.google.com/log/8561.0.0..8562.0.0 [2] https://chromium-review.googlesource.com/#/c/357971/ Sasha will add log output in a few minutes.
,
Jul 13 2016
Issue 627336 has been merged into this issue.
,
Jul 13 2016
Yes, it appears I botched the new lockbox index.
,
Jul 13 2016
We really should have an autotest to catch something this basic.
,
Jul 13 2016
That's exactly how this issue was caught over the weekend and report couple days back. See the original comment in https://bugs.chromium.org/p/chromium/issues/detail?id=627336 Here is the test results page for CFM enrollment test: https://wmatrix.googleplex.com/matrix/unfiltered?hide_missing=True&tests=enterprise_RemoraRequisitionServer&days_back=30 Similar test is there for regular enterprise enrollment as well. The enterprise_LongevityTracker test started failing because of the enrollment issue https://wmatrix.googleplex.com/matrix/unfiltered?hide_missing=True&tests=enterprise_LongevityTrackerServer&days_back=30&releases=54
,
Jul 14 2016
Yup, we should consider running 1 CFM and 1 enterprise enrollment test in bvt-cq so we can catch this during the PFQ roll.
,
Jul 14 2016
Steve, please consider reverting to fix this issue asap.
,
Jul 14 2016
If anyone is blocked by this, consider testing in a VM (which emulates install attributes in software, so should work) or nuking /dev/tpm and restarting cryptohomed (which should force fallback to the software emulation).
,
Jul 14 2016
I had a fix early yesterday but it hasn't gone in yet due to CQ flakiness. I'll chump it because it doesn't look like it's going through the CQ anytime soon. https://chromium-review.googlesource.com/#/c/359986/
,
Jul 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/7c30b74f89cad68c52bf27f98a627b1490728b3c commit 7c30b74f89cad68c52bf27f98a627b1490728b3c Author: Stephen Barber <smbarber@chromium.org> Date: Wed Jul 13 18:26:18 2016 cryptohome: fix lockbox index initialization The correct kLockboxIndex is in the cryptohome namespace... I have no idea what was being referenced before. BUG= chromium:627832 TEST=printing out lockbox index shows correct value Change-Id: Ibc8e5f6795897a6f9462d4e122f051cb86903490 Reviewed-on: https://chromium-review.googlesource.com/359986 Tested-by: Stephen Barber <smbarber@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Commit-Queue: Stephen Barber <smbarber@chromium.org> [modify] https://crrev.com/7c30b74f89cad68c52bf27f98a627b1490728b3c/cryptohome/tpm.cc
,
Jul 14 2016
Thanks a lot!
,
Jul 14 2016
Verify in 8587.0.0
,
Aug 1 2016
Could successfully enroll Candy Device.No error encountered. M ChromeOS Chrome ARC Type Channel 54 8659.0.0 54.0.2813.0 3108265 release dev
,
Feb 28 2017
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by pelets...@chromium.org
, Jul 13 2016