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

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Oct 2017
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug

Blocked on:
issue 777643

Sign in to add a comment

Issue 776919: lakitu-* failed at build_packages

Reported by, Oct 20 2017 Project Member

Issue description

lakitu-kernel-4_4-4.4.92-r1120: >>> Unpacking source...
lakitu-kernel-4_4-4.4.92-r1120: fatal: destination path '/build/lakitu/tmp/portage/sys-kernel/lakitu-kernel-4_4-4.4.92-r1120/work/lakitu-kernel-4_4-4.4.92' already exists and is not an empty directory.
lakitu-kernel-4_4-4.4.92-r1120:  * ERROR: sys-kernel/lakitu-kernel-4_4-4.4.92-r1120::lakitu failed (unpack phase):
lakitu-kernel-4_4-4.4.92-r1120:  *   Can't clone /mnt/host/source/src/third_party/kernel/v4.4.

Comment 1 by, Oct 20 2017

Running ./build_packages --board=lakitu on ToT on my local machine is OK.

Comment 2 by, Oct 20 2017

lakitu-st-paladin now passed, so either this was a flake or it was after all caused by one of the pending patches (and wasn't applied this time around).

Comment 4 by, Oct 20 2017

Labels: OS-Chrome
Several kernel CLs were among the two RED runs but they look innocent...

Comment 5 by, Oct 20 2017

common CLs are set([717451, 717452, 717453, 717454])

Comment 6 by, Oct 20 2017

FYI, this is independently tracked in b/68053870.

Comment 8 by, Oct 23 2017


Comment 10 by, Oct 23 2017


Comment 11 by, Oct 23 2017


Comment 12 by, Oct 23 2017

Issue 777277 has been merged into this issue.

Comment 13 by, Oct 23 2017

In bug #777277 I was asserting that the build machine was behaving very strangely.  Can anyone check if maybe it just has a bad disk or something?

It's certainly possible that the kernel build cache could cause weird issues, but it's strange that kevin and other kernel 4.4 users aren't seeing that.  I'd also note that the kernel has passed on some of the future runs, but that we saw different totally weird error messages...

Comment 14 by, Oct 23 2017

Blockedon: 777643
I think build185-m2 does indeed have some disk issues.
That said, the other lakitu builders are still failing to build kernel, and on other build slaves. So that's a separate issue.

Comment 15 by, Oct 23 2017

If you indeed seeing messages as per the original report then it's plausible that CLs Guenter pointed at (those for bug #767073) are related.  It doesn't explain why the kevin builder isn't seeing this, but I could sorta believe that somehow we're creating a cache file too early and it's confusing the builder.

Can folks repro this locally?  Can you figure out what exactly is in the directory that is not empty?

Comment 16 by, Oct 24 2017

I reproduced it locally. When I install dbus package, the owner of the temp folder is root/root, instead of my account.

Reproduce step:

1. Enter chroot
2. $ ./setup_board --board lakitu
3. $ ./build_packages --board lakitu
4. $ emerge-lakitu sys-apps/dbus 
Same error messsage here

$ ls -la /build/lakitu/tmp/portage/sys-apps/dbus-1.10.12-r5/work                              
total 12
drwxr-xr-x 3 root     root    4096 10月 24 14:01 .
drwxrwxr-x 6 akahuang portage 4096 10月 24 14:01 ..
drwxr-xr-x 2 root     root    4096 10月 24 14:01 dbus-1.10.12

I tried other board and the permission is:
$ ls -la /build/poppy/tmp/portage/sys-apps/dbus-1.10.12-r5/work
total 16
drwxr-xr-x  4 akahuang portage 4096 10月 24 14:02 .
drwxrwxr-x  7 akahuang portage 4096 10月 24 14:02 ..
drwxr-xr-x 11 akahuang portage 4096 10月 24 14:02 dbus-1.10.12
drwxr-xr-x  2 akahuang portage 4096 10月 24 14:03 dbus-1.10.12-abi_x86_64.amd64

Comment 17 by, Oct 24 2017

Comment 18 by, Oct 24 2017

Re #17,

Thanks vapier!! I successfully emerge dbus after cherry-pick your CL. But sys-fs/lvm2 still failed to emerge.

============== Log =================
$ emerge-lakitu sys-fs/lvm2
Calculating dependencies... done!

>>> Emerging (1 of 1) sys-fs/lvm2-2.02.97-r4::portage-stable for /build/lakitu/
 * LVM2.2.02.97.tgz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                               [ ok ]
 * Running stacked hooks for pre_pkg_setup
 *    sysroot_build_bin_dir ...                                                                [ ok ]
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /build/lakitu/usr/src/linux
 * Found sources for kernel version:
 *     4.4.92
 * Unable to check for the following kernel config options due
 * to absence of any configured kernel sources or compiled
 * config:
 *  - SYSVIPC - CONFIG_SYSVIPC: is not set (required for udev sync)
 * You're on your own to make sure they are set if needed.
 * Running stacked hooks for post_pkg_setup
 *    python_eclass_hack ...                                                                   [ ok ]
 * Running stacked hooks for pre_src_unpack
 *    python_multilib_setup ...                                                                [ ok ]
>>> Unpacking source...
>>> Unpacking LVM2.2.02.97.tgz to /build/lakitu/tmp/portage/sys-fs/lvm2-2.02.97-r4/work
tar: LVM2.2.02.97/README: Cannot open: Permission denied

Comment 19 by, Oct 24 2017

Hmm it's ok after I run "./setup_board --board lakitu --force" again. False alarm :p

Comment 20 by, Oct 24 2017

yeah you prob would need to `sudo rm -rf /build/lakitu/tmp/portage/*` first

Comment 21 by, Oct 24 2017

Re #17: Any idea why only lakitu is hitting this, and why only since last weekend?

Comment 22 by, Oct 24 2017

lakitu has a custom kernel, and i think they just upgraded it, so i suspect it's related to that.  i didn't check any commit timelines to double check.

Comment 23 by, Oct 24 2017

> lakitu has a custom kernel, and i think they just upgraded it, so i suspect it's related to that.  i didn't check any commit timelines to double check.

Its not upgraded yet. We are still on the 4.4 kernel. Just that the kernel config is different. But that hasn't changed recently either.

FWIW, we ran various lakitu trybots with which is supposed to be potential fix.


both failed at BuildPackages stage. This can be fixed by clobbering the builders.

But lakitu-release:
which does a clean build, still fails with at script


>>> Unpacking source...
fatal: destination path '/build/lakitu/tmp/portage/sys-kernel/lakitu-kernel-4_4-4.4.92-r1122/work/lakitu-kernel-4_4-4.4.92' already exists and is not an empty directory.

Comment 24 by, Oct 24 2017

The change has not been merged but our paladin suddenly becomes green ( ). Strange...

Comment 25 by, Oct 25 2017

Project Member
The following revision refers to this bug:

commit 41461f50e12cf5fa005a428f567fb6fd42de7bc3
Author: Mike Frysinger <>
Date: Wed Oct 25 00:36:35 2017

linux-info: pull in latest version

This fixes kernel version checks in early pkg_setup phases.

BUG= chromium:776919 
TEST=lakitu builds again

Change-Id: Iada30f7f10af5737db5d8c058c84f4665b838b7b
Commit-Ready: Mike Frysinger <>
Tested-by: Mike Frysinger <>
Reviewed-by: Chih-Yu Huang <>


Comment 26 by, Oct 25 2017

After vapier's CL is merged, sys-apps/dbus package can be built, but go/gloud and sys-fs/lvm2 still failed to build. vapier do you have any clue about it ?

Comment 27 by, Oct 25 2017

Looks like gocloud issue will be resolved when is merged.

lvm2 issue still seems related to linux-info.eclass.

Comment 28 by, Oct 25 2017

Regarding sys-fs/lvm2 problem, lvm2-2.02.97-r4.ebuild's pkg_setup() calls check_extra_config() which is in linux-info.eclass. And that eventually invokes getfilevar() in linux-info.eclass.

In that function, ${EBUILD_PHASE_FUNC} is empty. Is that because lvm2-2.02.97-r4.ebuild has EAPI=4 ?

Comment 29 by, Oct 25 2017

most likely. let me have a look.

Comment 30 by, Oct 25 2017

Labels: -Pri-1 Pri-0
Upping priority. I see that this is making consistent progress, but we _really_ need those paladins back in the important set. Priority to reflect that.

Comment 31 by, Oct 25 2017

For me failure mode for sys-fs/lvm2 is same as #16 i.e permission denied (may bcoz lvm2 is EAPI=4 as mentioned above). I cross-checked commit mentioned in #25 is present. I locally upgraded to EAPI=5 and was able to build lakitu image

Comment 32 by, Oct 26 2017

The simplest might to upgrade lvm2. Upgrading it to gentoo stable fixed the build failure for me and lakitu-paladin passed. Uploaded

Comment 33 by, Oct 26 2017

lets do the EAPI bump for low risk.  last time i tried lvm2 upgrade it did not go well.  but maybe things have improved since.  plus, we can still do the upgrade after the EAPI bump.

Comment 34 by, Oct 26 2017

Now chromeos-base/metrics failed to build in lakitu* board. Should be caused by this CL:

Adding "libsession_manager-client" dependency should fix this.

Comment 35 by, Oct 26 2017

Status: Started (was: Untriaged)
Re #34: The latest lakitu*paladins have passed. I didn't see any failures due to the CL you mentioned, nor do I see a fix / revert. Did you do anything for this?

My plan is to wait for the current CQ to finish. Whether or not is merged, we will have confidence that this doesn't break any boards.

At that point, I'm going to chump that CL if needed and mark lakitu boards important again.

Comment 36 by, Oct 26 2017

Project Member
The following revision refers to this bug:

commit 48e32bb8e1a75a58465da5df001aaae4169b77a8
Author: Pradeep Sawlani <>
Date: Thu Oct 26 16:43:00 2017

sys-fs/lvm2: Bump EAPI version to 5.

BUG= chromium:776919 
TEST=emerge-lakitu sys-fs/lvm2
TEST=build lakitu board image with and without this patch

Change-Id: I5d9a960b6a2bb686e086b5f9c1a062204a0ae13f
Signed-off-by: Pradeep Sawlani <>
Reviewed-by: Mike Frysinger <>


Comment 37 by, Oct 26 2017

Labels: -Pri-0 Pri-1
lakitu is important in the CQ again. Lowering to P1.
Please continue to drive the rest / wait for the fix to make it to release builders and let me know if you need anything from me. Removing from my attention set.

Comment 38 by, Oct 27 2017

Re #35, I created a CL for it:

Now the lakitu CQ has passed, I think we can close this issue after this CL is merged.

Comment 39 by, Oct 27 2017

Can't close yet. kernel builds are still broken on lakitu paladins.

Comment 40 by, Oct 30 2017

Status: Fixed (was: Started)
That bug was closed this morning.  The last comment there was:

Closing this, since builders were all green over the weekend. Today morning one build failed which seems to be different issue (b/68494029)

...presumably we don't need this bug open any more?

Comment 41 by, Oct 30 2017

Yeah all of our builders are back to green. Thanks to everyone who helped triage and fixing the issue.

Comment 42 by, Oct 31 2017

Project Member
The following revision refers to this bug:

commit c0c9ae0c5e4dc8cc48f53f22e88287910bbb0ff5
Author: Chih-Yu Huang <>
Date: Tue Oct 31 03:51:30 2017

metrics: add session_manager-client dependency.

In CL:731364 metrics added session_manager-client dependency. This CL
added the dependency at ebuild file as well.

BUG= chromium:776919 , chromium:774036
TEST=emerge-lakitu chromeos-base/metrics

Change-Id: I119df265a2cb35a979e63797a7f802fdcd91a87b
Tested-by: Chih-Yu Huang <>
Reviewed-by: Mike Frysinger <>
Reviewed-by: Sergey Poromov <>
Commit-Queue: Chih-Yu Huang <>


Comment 43 by, Jan 22 2018

Status: archived (was: Fixed)

Comment 44 by, Jan 23 2018

Status: Fixed (was: Archived)

Sign in to add a comment