+++ This bug was initially created as a clone of Bug #1670191 +++ Description of problem: Libguestfs "make" fails with when building inside a docker with "supermin: error: rename: Directory not empty: supermin.d.ibactpan" Version-Release number of selected component (if applicable): libguestfs-1.38.6 supermin-5.1.20 How reproducible: Happens 100% on my MacOS setup Happens 10% on my Ubuntu setup Steps to Reproduce: 1. MacOS High Sierra 2. Docker version 18.09.0, build 4d60db4 Actual results: "supermin: error: rename: Directory not empty: supermin.d.ibactpan" Expected results: Build succeeds Additional info: After debugging supermin (building it from source and changing some lines) the actual problem is not here: if debug >= 1 then printf "supermin: renaming %s to %s\n%!" new_outputdir outputdir; rename new_outputdir outputdir; But actually in the previous rename: let old_outputdir = try let old_outputdir = outputdir ^ "." ^ string_random8 () in rename outputdir old_outputdir; Some old_outputdir with Unix_error _ -> None in It fails with Unix_error: supermin: error: rename: Invalid cross-device link: supermin.d But it is not propagated. According to docker with OverlayFS: https://docs.docker.com/storage/storagedriver/overlayfs-driver/ Renaming directories: Calling rename(2) for a directory is allowed only when both the source and the destination path are on the top layer. Otherwise, it returns EXDEV error (“cross-device link not permitted”). Your application needs to be designed to handle EXDEV and fall back to a “copy and unlink” strategy. Should we handle this to support building libguestfs inside a docker? --- Additional comment from Richard W.M. Jones on 2019-01-28 22:23 UTC --- Yes we should handle EXDEV as it suggests. Could you see if the attached patch fixes it? I only compile tested it, and I'm just guessing that 'mv' works on Docker. --- Additional comment from Sam on 2019-01-28 22:35:38 UTC --- That was fast. Yes, it works perfectly! --- Additional comment from Richard W.M. Jones on 2019-01-28 22:44:13 UTC --- Thanks for testing, it's upstream in git now and will appear in supermin >= 5.1.21.
Upstream fix is: https://github.com/libguestfs/supermin/commit/6579cf5f72d5de345ae1cc97d0344dfa1771460a
Hi rjones, I have no MacOS env. I installed docker（18.09.1）and updated the OverlayFS storage driver on rhel7.6 host. Then I built the supermin from the tarball（supermin-5.1.19.tar.gz）in a container. There was no error during the building. So I cannot reproduce this bug on rhel7 env. Is there any other method to reproduce it?
It only happened to me once on my Ubuntu 14.04 Server - and only when I logged into the docker manually and tried to make libguestfs from sources (docker build script worked fine) On my MacOS it happens every time. Extended information 1. MacOS High Sierra 10.13.6 (17G65) 2. Docker version 18.09.0, build 4d60db4 3. Docker image of OL 7.6 (Oracle Linux) Dockerfile: FROM oraclelinux:7.6 RUN yum-config-manager --add-repo http://yum.oracle.com/repo/OracleLinux/OL7/kvm/utils/x86_64 RUN yum install -y qemu-kvm RUN yum install -y qemu-img RUN ln /usr/bin/qemu-system-x86_64 /usr/libexec/qemu-kvm # Configuration for libguestfs RUN yum-config-manager --add-repo http://yum.oracle.com/repo/OracleLinux/OL7/optional/latest/x86_64 RUN yum-config-manager --add-repo http://yum.oracle.com/repo/OracleLinux/OL7/optional/developer/x86_64 RUN yum-config-manager --add-repo https://yum.oracle.com/repo/OracleLinux/OL7/developer_EPEL/x86_64 RUN yum install -y python36-devel ADD get-pip.py get-pip.py RUN python36 get-pip.py RUN python36 -m pip install --upgrade pip RUN yum install -y libguestfs-winsupport RUN yum install -y *ntfs* # python-libguestfs has errors with python3 # Waiting for fix: https://bugzilla.redhat.com/show_bug.cgi?id=1627964 # In the meanwhile, we have to compile libguestfs and its python3 bindings from source. ENV LIBGUESTFS_PARENT_DIR=1.38-stable ENV LIBGUESTFS_DIR=libguestfs-1.38.6 RUN yum install -y wget RUN yum install -y kernel RUN yum install -y gcc RUN yum install -y make RUN yum install -y gperf RUN yum install -y genisoimage RUN yum install -y flex RUN yum install -y bison RUN yum install -y ncurses-devel RUN yum install -y pcre-devel RUN yum install -y augeas-devel RUN yum install -y file-devel RUN yum install -y yajl-devel RUN yum install -y hivex-devel RUN yum install -y supermin5 RUN ln /usr/bin/supermin5 /usr/bin/supermin RUN yum install -y ocaml RUN yum install -y ocaml-findlib RUN yum install -y ocaml-hivex-devel RUN yum install -y fuse-devel RUN wget http://download.libguestfs.org/$LIBGUESTFS_PARENT_DIR/$LIBGUESTFS_DIR.tar.gz >/dev/null 2>&1 RUN tar xf $LIBGUESTFS_DIR.tar.gz ENV PYTHON=python36 # Another bug in the python3 bindings in libguestfs. # https://bugzilla.redhat.com/show_bug.cgi?id=1627964#c18 # Changing to support g.read_file(path) on binary files - hope this doesn't destroy other calls. RUN sed -i 's/PyUnicode_FromStringAndSize/PyBytes_FromStringAndSize/g' $LIBGUESTFS_DIR/python/handle.c # --with-distro=REDHAT is very important - do not omit. RUN cd $LIBGUESTFS_DIR && ./autogen.sh --with-distro=REDHAT RUN yum install -y automake RUN yum install -y git RUN git clone https://github.com/libguestfs/supermin RUN yum-builddep -y supermin RUN cd supermin && ./autogen.sh RUN cd supermin && ./configure --prefix /usr RUN cd supermin && make RUN cd supermin && make install RUN cd $LIBGUESTFS_DIR && make -j8 RUN cd $LIBGUESTFS_DIR && make install REALLY_INSTALL=yes ENV LIBGUESTFS_BACKEND=direct ENV LIBGUESTFS_PATH=/usr/local/lib/guestfs RUN mkdir -p /usr/local/share/oracle/appliance RUN libguestfs-make-fixed-appliance /usr/local/share/oracle/appliance ENV LIBGUESTFS_PATH=/usr/local/share/oracle/appliance RUN python36 -m pip install pexpect
(In reply to YongkuiGuo from comment #3) > Hi rjones, > I have no MacOS env. I installed docker（18.09.1）and updated the OverlayFS > storage driver on rhel7.6 host. Then I built the supermin from the > tarball（supermin-5.1.19.tar.gz）in a container. There was no error during the > building. So I cannot reproduce this bug on rhel7 env. Is there any other > method to reproduce it? You would not see an error during building. However it would fail if you did 'make check' assuming that the filesystem containing /tmp was using overlayfs (and isn't a regular filesystem, tmpfs, etc.) If /tmp is not overlayfs then try setting TMPDIR to point to an overlayfs filesystem before running the tests.
(In reply to Richard W.M. Jones from comment #5) > (In reply to YongkuiGuo from comment #3) > > Hi rjones, > > I have no MacOS env. I installed docker（18.09.1）and updated the OverlayFS > > storage driver on rhel7.6 host. Then I built the supermin from the > > tarball（supermin-5.1.19.tar.gz）in a container. There was no error during the > > building. So I cannot reproduce this bug on rhel7 env. Is there any other > > method to reproduce it? > > You would not see an error during building. However it would fail if you > did 'make check' assuming that the filesystem containing /tmp was using > overlayfs (and isn't a regular filesystem, tmpfs, etc.) If /tmp is not > overlayfs then try setting TMPDIR to point to an overlayfs filesystem > before running the tests. The 'make check' command run successfully in the container(docker image of rhel7.6). The filesystem of /tmp is overlay. # make check ... PASS: test-basic.sh PASS: test-execstack.sh PASS: test-build-bash.sh PASS: test-binaries-exist.sh PASS: test-harder.sh PASS: test-build-bash-network.sh PASS: test-binaries-exist-network.sh PASS: test-harder-network.sh ============================================================================ Testsuite summary for supermin 5.1.19 ============================================================================ # TOTAL: 8 # PASS: 8 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ # df -T -h Filesystem Type Size Used Avail Use% Mounted on overlay overlay 50G 45G 5.0G 90% / tmpfs tmpfs 64M 0 64M 0% /dev tmpfs tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup /dev/mapper/rhel_rhel7libguestfs-root xfs 50G 45G 5.0G 90% /etc/hosts shm tmpfs 64M 0 64M 0% /dev/shm tmpfs tmpfs 3.8G 0 3.8G 0% /proc/asound tmpfs tmpfs 3.8G 0 3.8G 0% /proc/acpi tmpfs tmpfs 3.8G 0 3.8G 0% /proc/scsi tmpfs tmpfs 3.8G 0 3.8G 0% /sys/firmware
Thanks Sam for providing the Dockerfile. I tried but I still could not reproduce this bug without the MacOS env.
No problem, As I mentioned, I could not reproduce it on my Ubuntu environment either. Only happens on my MacOS. Do you need any more information on my MacOS environment? I think I can still reproduce this (before the fix) if needed. Sam
(In reply to Sam from comment #8) > No problem, > > As I mentioned, I could not reproduce it on my Ubuntu environment either. > Only happens on my MacOS. > > Do you need any more information on my MacOS environment? I think I can > still reproduce this (before the fix) if needed. Thanks a lot. In fact, I don't know the difference between MacOS and RHEL on the docker side.
Hi Sam, Could you help verify this bug when the fixed supermin version is built by dev?
(In reply to YongkuiGuo from comment #10) > Hi Sam, > Could you help verify this bug when the fixed supermin version is built by > dev? What do you mean? I already verified this when building supermin from sources. After the fix by RwJ in commit https://github.com/libguestfs/supermin/commit/6579cf5f72d5de345ae1cc97d0344dfa1771460a it works great. Sam
(In reply to Sam from comment #11) > (In reply to YongkuiGuo from comment #10) > > Hi Sam, > > Could you help verify this bug when the fixed supermin version is built by > > dev? > > What do you mean? I already verified this when building supermin from > sources. > After the fix by RwJ in commit > https://github.com/libguestfs/supermin/commit/ > 6579cf5f72d5de345ae1cc97d0344dfa1771460a it works great. > Sorry, you are right. Thanks.
I'm closing this as the bug does not affect any Red Hat supported products and RHEL 7 is going into phase 3. It is fixed upstream already.