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

Issue 775787 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

emerging some started cros-workon packages fails when subdirs are deep

Project Member Reported by apronin@chromium.org, Oct 18 2017

Issue description

After a recent 'repo sync', if I cros_workon start cryptohome, emerging it fails with:
cryptohome-9999:  * Copying sources from /mnt/host/source/src/platform2
cryptohome-9999: rsync: mkdir "/build/link/tmp/portage/chromeos-base/cryptohome-9999/work/cryptohome-9999/platform2" failed: No such file or directory (2)
cryptohome-9999: rsync error: error in file IO (code 11) at main.c(657) [Receiver=3.1.2]
cryptohome-9999:  * ERROR: chromeos-base/cryptohome-9999::chromiumos failed (unpack phase):
cryptohome-9999:  *   rsync -a --exclude= --exclude=*.pyc /mnt/host/source/src/platform2/// /build/link/tmp/portage/chromeos-base/cryptohome-9999/work/cryptohome-9999/platform2///
cryptohome-9999:  * 
cryptohome-9999:  * Call stack:
cryptohome-9999:  *     ebuild.sh, line   93:  Called src_unpack
cryptohome-9999:  *   environment, line 4068:  Called platform_src_unpack
cryptohome-9999:  *   environment, line 3633:  Called cros-workon_src_unpack
cryptohome-9999:  *   environment, line 1138:  Called local_copy '/mnt/host/source/src/platform2' '/build/link/tmp/portage/chromeos-base/cryptohome-9999/work/cryptohome-9999/platform2'
cryptohome-9999:  *   environment, line 2927:  Called local_copy_cp '/mnt/host/source/src/platform2' '/build/link/tmp/portage/chromeos-base/cryptohome-9999/work/cryptohome-9999/platform2'
cryptohome-9999:  *   environment, line 2941:  Called die
cryptohome-9999:  * The specific snippet of code:
cryptohome-9999:  *               rsync -a --safe-links "${blacklist[@]}" "${src}/${sl}/" "${dst}/${sl}/" || die "rsync -a ${blacklist[*]} ${src}/${sl}/ ${dst}/${sl}/";
cryptohome-9999:  * 
cryptohome-9999:  * If you need support, post the output of `emerge --info '=chromeos-base/cryptohome-9999::chromiumos'`,
cryptohome-9999:  * the complete build log and the output of `emerge -pqv '=chromeos-base/cryptohome-9999::chromiumos'`.
cryptohome-9999:  * The complete build log is located at '/build/link/tmp/portage/logs/chromeos-base:cryptohome-9999:20171018-014351.log'.
cryptohome-9999:  * For convenience, a symlink to the build log is located at '/build/link/tmp/portage/chromeos-base/cryptohome-9999/temp/build.log'.
cryptohome-9999:  * The ebuild environment file is located at '/build/link/tmp/portage/chromeos-base/cryptohome-9999/temp/environment'.
cryptohome-9999:  * Working directory: '/build/link/tmp/portage/chromeos-base/cryptohome-9999/work'
cryptohome-9999:  * S: '/build/link/tmp/portage/chromeos-base/cryptohome-9999/work/cryptohome-9999'


If I don't work on it, emerging works fine.
Same for other packages:
mkdir "/build/link/tmp/portage/chromeos-base/<package>-9999/work<package>-9999/<etc>" failed: No such file or directory

I checked. There is an empty 
/build/$BOARD/tmp/portage/chromeos-base/<package>-9999/work
but there is no
/build/$BOARD/tmp/portage/chromeos-base/<package>-9999/work/<package>-9999/

Looks like either some change dropped '-p' from mkdir here, or we add an extra <package>-9999 to the path, which we were not adding  before..
 
rm /build/$board and ./setup_board again doesn't help.
Cc: groeck@chromium.org nxia@chromium.org xiaochu@chromium.org
Adding sheriffs and deputy
Cc: jintao@chromium.org
Attached are logs for cryptohome on link: successful build w/o cros_workon start cryptohome, and failure with it.
success
5.9 KB View Download
failure
4.8 KB View Download

Comment 5 by jintao@google.com, Oct 18 2017

recreating chroot doesn't help either
Cc: vapier@chromium.org
I can reproduce this on ToT with imageloader-9999 on kefka.

Comment 7 by vapier@chromium.org, Oct 18 2017

Components: Build
Owner: vapier@chromium.org
Summary: emerging some started cros-workon packages fails when subdirs are deep (was: build_packages.sh failed on started ebuild package)
this should fix it:
  https://chromium-review.googlesource.com/724943

Comment 8 by vapier@chromium.org, Oct 18 2017

Status: Fixed (was: Untriaged)
Project Member

Comment 9 by bugdroid1@chromium.org, Oct 18 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/39860bd79c90546a3485c9b9a8b37a9d7bcae9a1

commit 39860bd79c90546a3485c9b9a8b37a9d7bcae9a1
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Oct 18 17:30:42 2017

cros-workon: restore dest dir creation

In the previous commit here, the mkdir was dropped because I thought
rsync would create the destination dirs on demand.  While that's true
for the final dir, parent dirs are not created automatically.  Re-add
the mkdir call in case the ebuild checks things out to subdirs that
don't yet exist.

BUG= chromium:775787 
TEST=`emerge-gale ap-daemons` works again

Change-Id: I710d20c4115cd47091c4e57f3c11893d4253fd90
Reviewed-on: https://chromium-review.googlesource.com/724943
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>

[modify] https://crrev.com/39860bd79c90546a3485c9b9a8b37a9d7bcae9a1/eclass/cros-workon.eclass

Comment 10 by dchan@chromium.org, Jan 22 2018

Status: archived (was: Fixed)

Comment 11 by dchan@chromium.org, Jan 23 2018

Status: Fixed (was: Archived)

Sign in to add a comment