TPM firmware update fails to start |
||||||
Issue descriptionReported by alberto@ via email, corresponding feedback at https://listnr.corp.google.com/product/208/report/85267263827 (feedback logs also attached) Version: 10323.62.0 (Official Build) stable-channel buddy Repro steps: 1. Go to chrome://chrome 2. Click the option to install security update 3. Confirm the dialog 4. Device reboots 5. You're seeing the powerwash dialog during OOBE with the security update checkbox checked and grayed out 6. You click "Powerwash" 7. Confirmation dialog comes up 8. You click "Continue" and nothing happens The logs on the Chrome side contain these lines: [1058:1058:0403/071318.724060:VERBOSE1:reset_screen.cc(210)] Starting TPM firmware update [1058:1058:0403/071324.580264:VERBOSE1:reset_screen.cc(210)] Starting TPM firmware update [1058:1058:0403/071324.585663:ERROR:object_proxy.cc(626)] Failed to call method: org.chromium.SessionManagerInterface.StartTPMFirmwareUpdate: object_path= /org/chromium/SessionManager: org.freedesktop.DBus.Error.Failed: error occurred in StartTPMFirmwareUpdate [1058:1058:0403/071332.117114:ERROR:object_proxy.cc(626)] Failed to call method: org.chromium.SessionManagerInterface.StartTPMFirmwareUpdate: object_path= /org/chromium/SessionManager: org.freedesktop.DBus.Error.Failed: error occurred in StartTPMFirmwareUpdate There are no corresponding error messages on the session_manager side. It's interesting to note though that the "Starting TPM firmware update" log line and the corresponding error have a few seconds between them. Delays are typically caused by slow access to VPD, which suggests that session_manager does receive the command and blocks. I've double-checked the return paths for VPD errors and can't find one that wouldn't print an error and return a proper error response... Maybe we're timing out? Unlikely, the timeout is 15 seconds IIRC and would generate a different error message. Pretty dubious at this point.
,
Apr 4 2018
,
Apr 4 2018
I've tried to repro with 10323.62.0 on cyan (don't have a buddy), but it all worked as expected. The firmware update process does start, although there's a notable delay (that's issue 768342 which is fixed in M66). Alberto, I don't know what else to do to make progress on this other than taking a look at your device. Andrey, would you be willing to poke at it? I'd put it in dev mode, verify that VPD is working and writes to RW_VPD succeed, then fake the dbus call with dbus-send and check whether session_manager performs the VPD update.
,
Apr 6 2018
I went for the repro and have initiated the update on that device from guest mode. Went through the same sequence, nothing happened. Pressed Powerwash then Continue again. Nothing happened. Started browsing around (pressed on the More Info link, closed the help page), and the device rebooted at this point. The firmware update completed successfully, went from 4.32 to 4.34. Unfortunately, the logs are lost due to the powerwash, so hard to reconstruct what exactly happened with session_manager. But, quite probably, that notable delay from issue 768342. It's on M65-10323.62.0 at the moment. Just in case, submitted a post-update feedback report: https://listnr.corp.google.com/report/85280336074
,
Apr 6 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by mnissler@chromium.org
, Apr 4 2018