Bug 12065

Summary: [morty-next] nightly-mips64 Publishing Layer Tarballs/
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Armin Kuster <akuster>
Component: coreAssignee: Michael Halstead <mhalstead>
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: Undecided CC: meta.mr.watcher, meta.watcher, mhalstead
Version: 2.2.2   
Target Milestone: ---   
Hardware: x86   
OS: Multiple   
URL: https://autobuilder.yocto.io/builders/nightly-mips64/builds/455/steps/Publishing%20Layer%20Tarballs/logs/stdio
Whiteboard:
OS type for building Yocto: --- Type of Regression: Unknown (Hard to categorize)
Verified: Documentation change: Don't know
Attachments:
Description Flags
CreateAutoConf_2 none

Description Armin Kuster 2017-09-07 23:38:40 UTC
Created attachment 3995 [details]
CreateAutoConf_2

using PTY: False
/bin/sh: line 0: cd: poky: No such file or directory
sending incremental file list
poky-60402978fe3648bf560b3386c6e9dd661cdf2083.tar.bz2
poky-60402978fe3648bf560b3386c6e9dd661cdf2083.tar.bz2.md5sum
rsync: chgrp "/srv/autobuilder/autobuilder.yoctoproject.org/pub/releases/yocto-2.2.2.rc2/.poky-60402978fe3648bf560b3386c6e9dd661cdf2083.tar.bz2.UdE7m5" failed: Operation not permitted (1)
rsync: chgrp "/srv/autobuilder/autobuilder.yoctoproject.org/pub/releases/yocto-2.2.2.rc2/.poky-60402978fe3648bf560b3386c6e9dd661cdf2083.tar.bz2.md5sum.Vy1vM1" failed: Operation not permitted (1)

sent 20,143,922 bytes  received 445 bytes  13,429,578.00 bytes/sec
total size is 20,138,795  speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.0]
Comment 1 Armin Kuster 2017-09-07 23:39:28 UTC
not sure if this is AB issue or burp
Comment 2 Michael Halstead 2017-09-08 00:01:16 UTC
Appears to be an NFS issue with that worker only. idmapd.conf has reverted to a default config. I can fix it after the current selftest completes.
Comment 3 Michael Halstead 2017-09-08 18:39:33 UTC
idmapd.conf domain = yocto.io resolved the problem.
Comment 4 Armin Kuster 2017-09-08 18:58:24 UTC
I have a dumb question. can any of these system level issues be checked via a build test script?
Comment 5 Michael Halstead 2017-09-08 19:37:11 UTC
A test for this would be very specific to this cluster. Probably better to check in configuration management and troubleshoot the rare failure.

If we did want to test something generic that would find this, as well as other things, before the build started we could write to the destination directory in an early step of each build and then delete the test file.