Issue metadata
Sign in to add a comment
|
Cyan/setzer/reks and cyan-cheets recovery fails on TOT build |
||||||||||||||||||||||
Issue descriptionChrome Version: 8419.0.0/53.0.2759.0.0 cyan-cheets Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1) Try install TOT build (2) (3) Expected Result: Should be able to recover the device Actual Result: Recovery fails How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) What is the impact to the user, and is there a workaround? If so, what is it? Please provide any additional information below. Attach a screen shot or log if possible.
,
Jun 6 2016
How does it fail? What is the last you see on screen? Can we have the recovery log from the USB stick?
,
Jun 6 2016
Autoupdate Works fine. Attaching recovery logs
,
Jun 6 2016
Also peppy TOT recovery worked
,
Jun 6 2016
Error info from recovery log: -------------------------- flashrom v0.9.4 : 467b825 : Jun 03 2016 10:00:12 UTC on Linux 3.18.0-12390-g860bb18 (x86_64), built with libpci 3.1.10, GCC 4.9.x 20150123 (prerelease), little endian disable_power_management: Failed to open /var/lock/flashrom_powerd.lock for writing: No such file or directory Mapping BYT IBASE at 0xfed08000, unaligned size 0x200. Mapping BYT SBASE at 0xfed01000, unaligned size 0x200. Missing Chromium EC memory map. Error: Programmer initialization failed. ERROR: Execution FAILED. ERROR: Execution failed: ./updater4.sh (error code = 1) Finished after 29 seconds. Failed Command: /tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate --mode=recovery - Exit Code 1 Firmware update failed (error code: 1). Rolling back update due to failure installing required firmware. Successfully updated GPT with all settings to rollback. PostInstall Failed -------------------------------
,
Jun 6 2016
,
Jun 22 2016
Issue again repro'd on build 8486.0.0 cyan-cheets
,
Jun 22 2016
We need this addressed.
,
Jun 22 2016
what is the FW on the dut now ? and what is the FW on the shellball (chromeos-firmwareupdate -V) We need more log from the failed --mode=recovery
,
Jun 22 2016
looks like cyan cheet 8486.0.0 has the same version of FW as non-cheet. The log shows Starting firmware updater (/tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate --mode=recovery) Command: /tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate --mode=recovery Starting Google_Cyan firmware updater v4 (recovery)... - Updater package: [Google_Cyan.7287.57.64 / EC:cyan_v1.1.3499-2565067] - Current system: [RO:Google_Cyan.7287.57.64 , ACT:Google_Cyan.7287.57.64] - Write protection: Hardware: off, Software: Main=off EC=off One-time RO+RW update from unstable EC firmware. Try to update with recovery mode... mode_recovery: update RO+RW * invoke: flashrom -p host --fast-verify -w bios.bin mode_recovery: update ec/RO+RW * invoke: flashrom -p ec --fast-verify -w ec.bin Execution failed (1): flashrom -p ec --fast-verify -w ec.bin Messages: flashrom v0.9.4 : b389abb : Jun 21 2016 03:10:50 UTC on Linux 3.18.0-12499-gebf1be81 (x86_64), built with libpci 3.1.10, GCC 4.9.x 20150123 (prerelease), little endian disable_power_management: Failed to open /var/lock/flashrom_powerd.lock for writing: No such file or directory Mapping BYT IBASE at 0xfed08000, unaligned size 0x200. Mapping BYT SBASE at 0xfed01000, unaligned size 0x200. Missing Chromium EC memory map. Error: Programmer initialization failed. ERROR: Execution FAILED. ERROR: Execution failed: ./updater4.sh (error code = 1) Finished after 28 seconds.
,
Jun 22 2016
Not sure if https://b.corp.google.com/u/0/issues/27849483 might have broken it ?
,
Jun 22 2016
+gwendal the latest recovery image error out while trying to flashrom (see reovery log in c#3) The error is Mapping BYT IBASE at 0xfed08000, unaligned size 0x200. Mapping BYT SBASE at 0xfed01000, unaligned size 0x200. Missing Chromium EC memory map. Error: Programmer initialization failed.
,
Jun 22 2016
So, for now we have builds 8419.0.0 and 8486.0.0 failing recovery. It is confirmed with 8481.0.0 now, and others in past week, that builds in between are just fine. After the issue is reproduced, device boots to recovery screen. Then recovery with 8481.0.0 works and fixes the device.
,
Jun 24 2016
I saw the error when recovery installing cyan cheets to 8493.0.0. Attached recovery logs of the machine
,
Jun 27 2016
Have we seen this on any of the latest builds? 8500+?
,
Jun 27 2016
Saw the same error when trying to recovery install to 8508.0.0. Attached recovery logs.
,
Jun 28 2016
+bhthompson. Bernie, who should the right owner be for this recovery issue?
,
Jun 28 2016
we are still seeing this issue on M-53( 8513.0.0/53.0.2773.0)
,
Jun 29 2016
bhthompson@ do we know who should look at this issue?
,
Jun 30 2016
observed the issue when trying to update Reks 14 to 8517.0.0.
,
Jul 1 2016
On cyan cheets, recovery install with a USB to 8530.0.0 fails but the auto update to 8530.0.0 works.
,
Jul 2 2016
+david, can you take a look at c#10 and see if this is flashrom issue ?
,
Jul 2 2016
Still able to reproduce this issue on M53 build 8530.0.0
,
Jul 2 2016
#23 was tested on a cyan (non cheets). sontis@ also checked samus and minnie - both do *not* encounter this failure. kalin@ mentioned that recovery on prod is done mainly on stable channel, as Chrome Recovery tool app is providing recovery images on stable channel only. Hence, changing label to RB-Stable.
,
Jul 12 2016
Still broken on non-cheets cyan on 8530.11.0
,
Jul 12 2016
,
Jul 12 2016
Shawn, could you take a look at this? Or is this something dhendrix should be digging into? This is pretty nasty if it is happening reliably, I thought we had all these ToT flashrom issues resolved?
,
Jul 12 2016
Re #27: This is pretty similar to issue #616620 , but it affects a different lockfile that is used by powerd. The fixes are here, though unfortunately it took a long time for them to wind thru the CQ: https://chromium-review.googlesource.com/#/c/351360/ https://chromium-review.googlesource.com/#/c/351360/ https://chromium-review.googlesource.com/#/c/351271/ https://chromium-review.googlesource.com/#/c/351318/ It seemed to occur less than #616620 (as per #13, #24), so I was reluctant to push for getting them cherry-picked into release branches. The issue in #12 is unrelated and we should look for similar failures.
,
Jul 12 2016
I think Shawn is on vacation this week. can someone else look at this ?
,
Jul 12 2016
If these are landed on ToT, does ToT recovery work? If so, and we are confident in it, I recommend we merge these to R53 soon.
,
Jul 12 2016
+sontis will try ToT (M54) on cyan and report back.
,
Jul 12 2016
TOT is working fine. Able to install cyan M54 build 8578.0.0
,
Jul 12 2016
BTW, it looks like I failed at copy+paste. One of the CLs listed in #28 should be https://chromium-review.googlesource.com/#/c/351345/ . Anyway, I tried to cherry-pick into R53-8530.B, but gerrit gave me an "Identical tree" error. So I guess they're already there? What about R52?
,
Jul 12 2016
It does seem these are all in R53 already, are there any other patches we could be missing that would cause this failure in R53?
,
Jul 12 2016
see https://code.google.com/p/chrome-os-partner/issues/detail?id=55206 8530.10.0 seems to failed on setzer and the diff from 10 to 12 https://crosland.corp.google.com/log/8530.10.0..8530.12.0 They appear to include dhendrix's fix.
,
Jul 12 2016
Still able to reproduce this issue on cyan M53 build 8530.12.0
,
Jul 13 2016
,
Jul 13 2016
Given Shawn is out, can you debug why this is breaking on the branch Dave?
,
Jul 13 2016
Setzer has the same issue too: https://code.google.com/p/chrome-os-partner/issues/detail?id=55206
,
Jul 13 2016
,
Jul 14 2016
The "Missing Chromium EC memory map." error in #12 is caused by chrome-os-partner:54762. So with that committed as well as the powerd lockfile fixes, we should be good.
,
Jul 14 2016
Thanks! Sridhar will test with 8530.13.0
,
Jul 14 2016
Recovery is working fine for Cyan, Setzer and Reks on M53 build 8530.13.0
,
Jul 14 2016
verified by sontis@ |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by abod...@chromium.org
, Jun 6 2016Labels: -Type-Bug Type-Bug-Regression