| Summary: | dev-libs/glib-2.40.2: fails to prepare with armv7a-hardfp-hardened qemu-arm chroot (bash glob misses existing directory/file) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Jones <gentoo> |
| Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | base-system, qemu+disabled, zmedico |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Michael Jones
2015-03-11 07:11:43 UTC
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. |
