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

Issue 714254 link

Starred by 1 user

Issue metadata

Status: Fixed
Merged: issue 712283
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 700808



Sign in to add a comment

peppy-chrome-pfq failed in provision

Project Member Reported by x...@chromium.org, Apr 21 2017

Issue description

See the latest peppy-chrome-pfq: https://uberchromegw.corp.google.com/i/chromeos/builders/peppy-chrome-pfq/builds/3401

Selected error messages:
  provision                                 FAIL: Unhandled DevServerException: CrOS auto-update failed for host chromeos4-row6-rack13-host3: RootfsUpdateError: Failed to perform rootfs update: DevServerStartupError('Timeout (30) waiting for remote devserver port_file',)

@@@STEP_FAILURE@@@
13:07:18: ERROR: ** HWTest did not complete due to infrastructure issues (code 3) **

 
This looks like  issue 696820 ?

Components: Infra>Client>ChromeOS
Owner: xixuan@chromium.org
Status: Available (was: Untriaged)
No, this is a different bug.  I searched for this symptom, but
it looks like there's no open bug for it.

xixuan@ can you add a bug reference?

Comment 3 by nxia@chromium.org, Apr 21 2017

Mergedinto: 712283
Status: Duplicate (was: Available)

Comment 4 by nxia@chromium.org, Apr 21 2017

Status: Available (was: Duplicate)
sorry, mistaken operation.

Comment 5 by xixuan@chromium.org, Apr 21 2017

I will put a fix for that. The problem comes from the co-working of many issues:

1. The dut is very unstable (or the shard chromeos-server14.mtv). It loses connection sometimes in devserver package transferring (https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/hosts/chromeos4-row6-rack13-host3/3172074-provision/20172104144608/autoupdate_logs/FCrOS_update_chromeos4-row6-rack13-host3_12791.log), sometimes in stateful update (https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/113695284-chromeos-test/chromeos4-row6-rack13-host3/debug/autoserv.DEBUG), maybe sometimes in other cases but I haven't checked.

2. When it's left an old package and then being provisioned, and is provisioned with a new version of stateful.tgz, errors like "ImportError: /lib64/libc.so.6: version `GLIBC_2.16' not found" will happen.

3. We add a new feature to provision with old stateful.tgz, and it works. The GLIBC error is gone. But the code limits to only transfer third-party packages like 'cherrypy' to a dut whose python version is < 2.7, which is not the case. So it failed again due to error 'ImportError: No module named cherrypy'.
Blocking: 700808
xixuan@ peppy-pfq-bot has been failing today with the same error. See issue 700808 for comment#104. Is that caused by the same root cause?
Basically yes, working on the fix.
Status: Started (was: Available)
Project Member

Comment 10 by bugdroid1@chromium.org, May 8 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/2b0fa97b40941247a35a6866cb4a19eaff99bd5b

commit 2b0fa97b40941247a35a6866cb4a19eaff99bd5b
Author: xixuan <xixuan@chromium.org>
Date: Mon May 08 04:00:57 2017

chromite: Don't skip transferring packages even if Python 2.7 is
installed

This CL removes the assumption of 'detecting python2.7'. If ori_payload
is specified, just transfer the third-party package.

BUG= chromium:714254 
TEST=Call ds.auto_update('100.107.151.251', 'link-release/R56-8883.0.0',
original_board='link', original_release_version='3428.210.0',
force_update=True) to check.

Change-Id: Ic68f216ed38ab65cfac4a3a26e7ce13da6103612
Reviewed-on: https://chromium-review.googlesource.com/495651
Commit-Ready: Xixuan Wu <xixuan@chromium.org>
Tested-by: Xixuan Wu <xixuan@chromium.org>
Reviewed-by: Allen Li <ayatane@chromium.org>

[modify] https://crrev.com/2b0fa97b40941247a35a6866cb4a19eaff99bd5b/lib/auto_updater.py

Status: Fixed (was: Started)

Sign in to add a comment