This is happening on an armv7a-hardfp-hardened qemu-arm chroot. For the life of me I can't figure out what's causing the error. The files are all where they are supposed to be, as far as I can tell.... I've cleared out /var/tmp/portage, and /usr/portage/distfiles to ensure a completely clean environment. Any suggestions on how to diagnose this further? armv7a-hardfp-hardened / # ls -lah /var/tmp/portage ; ls -lah /usr/portage/distfiles/ ; ebuild /usr/portage/dev-libs/glib/glib-2.40.2.ebuild prepare total 0 drwxrwxr-x 1 portage portage 0 Mar 11 02:05 . drwxrwxrwt 1 root root 24 Mar 10 22:24 .. total 0 drwxrwxr-x 1 root portage 0 Mar 11 02:04 . drwxr-xr-x 1 root root 3.4K Feb 8 20:11 .. >>> Downloading 'http://mirrors.rit.edu/gentoo/distfiles/glib-2.40.2.tar.xz' --2015-03-11 02:05:35-- http://mirrors.rit.edu/gentoo/distfiles/glib-2.40.2.tar.xz Resolving mirrors.rit.edu... 129.21.171.98 Connecting to mirrors.rit.edu|129.21.171.98|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7001344 (6.7M) [application/octet-stream] Saving to: '/usr/portage/distfiles/glib-2.40.2.tar.xz' /usr/portage/distfiles/glib-2.40.2.tar.xz 100%[=========================================================================================================>] 6.68M 3.55MB/s in 1.9s 2015-03-11 02:05:37 (3.55 MB/s) - '/usr/portage/distfiles/glib-2.40.2.tar.xz' saved [7001344/7001344] * glib-2.40.2.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Downloading 'http://mirrors.rit.edu/gentoo/distfiles/pkg-config-0.28.tar.gz' --2015-03-11 02:05:39-- http://mirrors.rit.edu/gentoo/distfiles/pkg-config-0.28.tar.gz Resolving mirrors.rit.edu... 129.21.171.98 Connecting to mirrors.rit.edu|129.21.171.98|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1931203 (1.8M) [application/x-gzip] Saving to: '/usr/portage/distfiles/pkg-config-0.28.tar.gz' /usr/portage/distfiles/pkg-config-0.28.tar.gz 100%[=========================================================================================================>] 1.84M 1.73MB/s in 1.1s 2015-03-11 02:05:41 (1.73 MB/s) - '/usr/portage/distfiles/pkg-config-0.28.tar.gz' saved [1931203/1931203] * pkg-config-0.28.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 3.18.7 * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking glib-2.40.2.tar.xz to /var/tmp/portage/dev-libs/glib-2.40.2/work >>> Unpacking pkg-config-0.28.tar.gz to /var/tmp/portage/dev-libs/glib-2.40.2/work >>> Source unpacked in /var/tmp/portage/dev-libs/glib-2.40.2/work >>> Preparing source in /var/tmp/portage/dev-libs/glib-2.40.2/work/glib-2.40.2 ... /bin/mv: cannot stat '/var/tmp/portage/dev-libs/glib-2.40.2/work/pkg-config-*/pkg.m4': No such file or directory * ERROR: dev-libs/glib-2.40.2::gentoo failed (prepare phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_prepare * environment, line 5940: Called die * The specific snippet of code: * mv -f "${WORKDIR}"/pkg-config-*/pkg.m4 "${S}"/m4macros/ || die; * * If you need support, post the output of `emerge --info '=dev-libs/glib-2.40.2::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-libs/glib-2.40.2::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-libs/glib-2.40.2/temp/build.log.gz'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/glib-2.40.2/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/glib-2.40.2/work/glib-2.40.2' * S: '/var/tmp/portage/dev-libs/glib-2.40.2/work/glib-2.40.2' armv7a-hardfp-hardened / # armv7a-hardfp-hardened pkg-config-0.28 # pwd ; ls -lah /var/tmp/portage/dev-libs/glib-2.40.2/work/pkg-config-0.28 total 1.6M drwxr-xr-x 1 portage portage 498 Jan 24 2013 . drwx------ 1 portage portage 52 Mar 11 02:06 .. -rw-r--r-- 1 portage portage 359 Feb 18 2010 AUTHORS -rw-r--r-- 1 portage portage 18K Mar 23 2010 COPYING -rw-r--r-- 1 portage portage 47K May 24 2010 ChangeLog -rw-r--r-- 1 portage portage 16K Oct 1 2012 INSTALL -rw-r--r-- 1 portage portage 1.8K Jan 23 2013 Makefile.am -rw-r--r-- 1 portage portage 38K Jan 23 2013 Makefile.in -rw-r--r-- 1 portage portage 9.1K Jan 23 2013 NEWS -rw-r--r-- 1 portage portage 2.6K Oct 13 2012 README -rw-r--r-- 1 portage portage 1.4K Jan 22 2013 README.win32 -rw-r--r-- 1 portage portage 338K Jan 23 2013 aclocal.m4 drwxr-xr-x 1 portage portage 1.8K Jan 24 2013 check -rwxr-xr-x 1 portage portage 44K Oct 1 2012 config.guess -rw-r--r-- 1 portage portage 2.0K Jan 23 2013 config.h.in -rwxr-xr-x 1 portage portage 35K Oct 1 2012 config.sub -rwxr-xr-x 1 portage portage 489K Jan 23 2013 configure -rw-r--r-- 1 portage portage 6.7K Jan 23 2013 configure.ac -rwxr-xr-x 1 portage portage 21K Oct 1 2012 depcomp drwxr-xr-x 1 portage portage 436 Jan 24 2013 glib -rwxr-xr-x 1 portage portage 14K Oct 1 2012 install-sh -rw-r--r-- 1 portage portage 277K Jan 22 2013 ltmain.sh -rw-r--r-- 1 portage portage 24K Jan 22 2013 main.c -rwxr-xr-x 1 portage portage 11K Oct 1 2012 missing -rw-r--r-- 1 portage portage 26K Jan 22 2013 parse.c -rw-r--r-- 1 portage portage 1.1K Dec 11 2012 parse.h -rw-r--r-- 1 portage portage 18K May 24 2010 pkg-config-guide.html -rw-r--r-- 1 portage portage 19K Jan 22 2013 pkg-config.1 -rw-r--r-- 1 portage portage 34K Jan 22 2013 pkg.c -rw-r--r-- 1 portage portage 4.4K Jan 22 2013 pkg.h -rw-r--r-- 1 portage portage 7.7K Jan 22 2013 pkg.m4 Reproducible: Always
The only thing that comes to mind is that the order of operations to the filesystem is not being preserved: mv is trying to stat pkg.m4 when the unpacker's mkdir call for the pkg-config-0.28 directory has not yet completed. Where does qemu's /var/tmp/portage live, and how is it mounted - both from the point of view inside qemu and inside the host system? Are you using any sort of weird alternative to app-arch/tar which might report that the untar operation has succeeded while in fact it's still in progress?
> The only thing that comes to mind is that the order of operations to the > filesystem is not being preserved: mv is trying to stat pkg.m4 when the > unpacker's mkdir call for the pkg-config-0.28 directory has not yet completed. Hrmm, that's an interesting possibility. > Where does qemu's /var/tmp/portage live, and how is it mounted - both from the > point of view inside qemu and inside the host system? The qemu chroot lives at /var/lib/container/armv7a-hardened Which is a mount of my btrfs subvolume /@arm7a-hardfp-hardened Which is also mounted at /mnt/@arm7a-hardfp-hardened Which itself is a btrfs subvolume under my root btrfs subvolume (I use the strategy where my root FS is the @ subvolume, so that I can more easily take snapshots. Similar to what the Ubuntu installer sets up). I launch the chroot using systemd-nspawn, so I suppose it's more accurate to call it a qemu-arm LXC than a chroot. (I use systemd to boot the host machine, in case that's relevant, with systemd-networkd and systemd-timesyncd for networking and time sync, in case the filesystem timestamp has something weird to do with it). /var/tmp/portage is just part of the chroot's root filesystem. So on the host, it would be either /var/lib/container/armv7a-hardfp-hardened/var/tmp/portage or /mnt/@armv7a-hardfp-hardened/var/tmp/portage Depending on which mountpoint you were looking at. > Are you using any sort of weird alternative to app-arch/tar which might > report that the untar operation has succeeded while in fact it's still in > progress? I'm not aware of using anything like that. I don't have any overlays configured in Layman, and eix reports I have app-arch/tar-1.27.1-r2 installed with these useflags acl nls xattr -minimal -selinux -static USERLAND="GNU"
Could you try mounting /var/tmp/portage on an ext4 partition? I wonder if this is a btrfs issue.
Sure thing. I'll try to do that tomorrow.
Sorry for the delay. Have /var/tmp/portage mounted on an ext4 volume. I also upgraded qemu to 2.2.0 (it was stabilized today, I think). And I also moved the container/chroot to a different machine (rsynced the filesystem). Any other thoughts on how I can diagnose what's going on?
Pressed submit without proofreading. Problem is still happening, seemingly exactly as before, even after doing those steps.
@dev-portage, any ideas why this may be happening and how to debug it?
(In reply to Michael Jones from comment #0) > armv7a-hardfp-hardened pkg-config-0.28 # pwd ; ls -lah You should also try this to see if bash fails to expand the glob again: echo /var/tmp/portage/dev-libs/glib-2.40.2/work/pkg-config-*/pkg.m4
Not working: In the armv7a-hardfp-hardened chroot: armv7a-hardfp-hardened ~ # echo /var/tmp/portage/dev-libs/glib-2.40.2/work/pkg-config-*/pkg.m4 /var/tmp/portage/dev-libs/glib-2.40.2/work/pkg-config-*/pkg.m4 armv7a-hardfp-hardened ~ # echo /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-*/pkg.m4 /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-*/pkg.m4 All working: On the base system: jellyfish glib # echo /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-*/pkg.m4 /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-0.28/pkg.m4 armv6j-hardfp chroot: armv6j-hardfp glib # echo /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-*/pkg.m4 /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-0.28/pkg.m4 armv7a-hardfp, non-hardened: armv7a-hardfp glib # echo /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-*/pkg.m4 /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-0.28/pkg.m4 armv7a-hardfp-hardened-musl: armv7a-hardfp-musl-hardened glib # echo /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-*/pkg.m4 /var/tmp/portage/dev-libs/glib-2.42.2/work/pkg-config-0.28/pkg.m4 Ok, we've got a difference in globbing behavior. Why would this fail?
(In reply to Michael Jones from comment #9) > Ok, we've got a difference in globbing behavior. Why would this fail? You should create an strace log of one that succeeds and one that fails, and compare them. strace -o strace.log bash -c 'echo /var/tmp/portage/dev-libs/glib-2.40.2/work/pkg-config-*/pkg.m4'
*** This bug has been marked as a duplicate of bug 518598 ***
Ah. Cool. Thanks for finding the duplicate.