$Summary says it all, mock ... foo.src.rpm fails if foo.src.rpm is on nfs filesytem, seems to have started with mock-1.1.28-1.el6 landing, see also https://bugzilla.redhat.com/show_bug.cgi?id=649192#c20 In short, mock ... foo.src.rpm ERROR: [Errno 2] No such file or directory: 'foo.src.rpm' Seems specific to relative paths, if given fully-qualified path /bar/baz/foo.src.rpm , all is well.
And... same problem when using --resultdir=<relative_path_on_nfs>
*** Bug 916647 has been marked as a duplicate of this bug. ***
About the "--resultdir=${nfs_path}" : I had the same problems and investigated a bit. This happens because most NFS exports are configured with "root_squash" (they don't allow root privilege). The first hook of the "package_state" plugin, the one which creates "available_pkgs", doesn't create this file as the uid who started mock, but creates this file using elevated privileges (while being root). On a local file system, this works, because root is allowed to write almost everywhere. On an nfs file system, this fails, because root is ignored by the server and instead the file is attempted to be written as UID=nobody (who usually doesn't have write rights on the directory). Current "quick fix solutions": - Either, as mentioned in bug 916647, disable the plugin - Or, change the gid and chmod of the result dir to make it writeable (the mock process seems to heave "mock" group-rights. Thus with gid=mock and "g+ws", the result dir is writeable by package_state, and the process doesn't fail). Needed fix in mock: - "available_pkgs" is written in the result-dir, not in the root. Thus it needs to be written using the calling user's privileges, not using the elevated privilege (as are all the other files created by mock in the result-dir).
I'll look at dropping/restoring privs during the call to repoquery
Created attachment 794431 [details] Patch to temporarily drop privileges when writing available_packages file Tried this on my test suite and the available_packages file ended up being owned by me (which should avoid the root squash issue on NFS). Would you try this patch and let me know if it fixes your problem?
queued for 1.34 release
mock-1.1.34-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mock-1.1.34-1.fc18
mock-1.1.34-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.34-1.el6
mock-1.1.34-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.1.34-1.fc20
mock-1.1.34-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.34-1.fc19
Package mock-1.1.34-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mock-1.1.34-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20329/mock-1.1.34-1.fc20 then log in and leave karma (feedback).
mock-1.1.35-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.35-1.fc19
mock-1.1.35-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mock-1.1.35-1.fc18
mock-1.1.35-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.35-1.el6
mock-1.1.35-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.1.35-1.fc20
mock-1.1.35-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.36-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.36-1.fc19
mock-1.1.36-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.1.36-1.fc20
mock-1.1.36-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.36-1.el6
mock-1.1.36-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.37-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.37-1.fc19
mock-1.1.37-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.1.37-1.fc20
mock-1.1.37-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.37-1.el6
mock-1.1.37-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.1.37-2.fc20
mock-1.1.37-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.37-2.fc19
mock-1.1.37-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.37-2.el6
mock-1.1.38-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.38-1.fc19
mock-1.1.38-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.38-1.el6
mock-1.1.38-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.1.38-1.fc20
I'm not sure why this bug is being referenced in every single mock update since 1.34, I assume it's some kind of mistake in a script somewhere?
Yeah, it's being picked up in the update from previous releases. Not sure why but I'll make sure it's not there in the next release.
mock-1.1.38-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.38-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.38-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
I don't think this bug is fully fixed... The problem with --resultdir might be fixed (I'm not using --resultdir on NFS and I have package_state_enable=False so I wasn't hitting that problem). But the original problem in comment 0 still exists, namely mock fails when the SRPM is given as a relative path on an NFS filesystem. It works if I use an absolute path instead. Here is the full stack trace with mock 1.1.38: Traceback (most recent call last): File "/usr/sbin/mock", line 696, in <module> main(retParams) File "/usr/sbin/mock", line 630, in main do_rebuild(config_opts, chroot, args) File "<peak.util.decorators.rewrap wrapping __main__.do_rebuild at 0x0191A848>", line 3, in do_rebuild def do_rebuild(config_opts, chroot, srpms): return __decorated(config_opts, chroot, srpms) File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/sbin/mock", line 278, in do_rebuild chroot.build(srpm, timeout=config_opts['rpmbuild_timeout'], check=config_opts['check']) File "<peak.util.decorators.rewrap wrapping mockbuild.backend.build at 0x01916320>", line 3, in build def build(self, srpm, timeout, check): return __decorated(self, srpm, timeout, check) File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.6/site-packages/mockbuild/backend.py", line 689, in build srpmChrootFilename = self._copySrpmIntoChroot(srpm) File "<peak.util.decorators.rewrap wrapping mockbuild.backend._copySrpmIntoChroot at 0x0191CC80>", line 3, in _copySrpmIntoChroot def _copySrpmIntoChroot(self, srpm): return __decorated(self, srpm) File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.6/site-packages/mockbuild/backend.py", line 1092, in _copySrpmIntoChroot shutil.copy2(srpm, dest) File "/usr/lib64/python2.6/shutil.py", line 95, in copy2 copyfile(src, dst) File "/usr/lib64/python2.6/shutil.py", line 50, in copyfile with open(src, 'rb') as fsrc: IOError: [Errno 2] No such file or directory: 'rpmbuild-output/beaker-0.16.3-0.git.35.da5088a.el6.src.rpm'
As stated in comment 35 the original bug report for this issue still stands. When calling "mock rebuild" against an SRPM located on an NFS mount (on EL6) the build fails with "no such file or directory" (see comment 35 for details). Specifying the full path to the SRPM instead of a relative path works as expected. Please advise what, if any, additional information is required.
I tried build src.rpm which was stored on nfs with (rw,sync,root_squash) and it succeeded. Tested with mock-1.2.2-1.fc21.noarch Please reopen if you hit it again and provide reproducer.