Bug 916685 - mock ... foo.src.rpm fails if foo.src.rpm is on nfs filesytem
Summary: mock ... foo.src.rpm fails if foo.src.rpm is on nfs filesytem
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: mock
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
: 916647 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-28 16:33 UTC by Rex Dieter
Modified: 2014-11-20 13:31 UTC (History)
8 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-11-20 13:31:01 UTC


Attachments (Terms of Use)
Patch to temporarily drop privileges when writing available_packages file (1.70 KB, patch)
2013-09-05 18:27 UTC, Clark Williams
no flags Details | Diff

Description Rex Dieter 2013-02-28 16:33:21 UTC
$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.

Comment 1 Rex Dieter 2013-02-28 16:45:04 UTC
And... same problem when using
--resultdir=<relative_path_on_nfs>

Comment 2 Rex Dieter 2013-02-28 16:46:25 UTC
*** Bug 916647 has been marked as a duplicate of this bug. ***

Comment 3 Ivan Topolsky 2013-08-30 11:46:39 UTC
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).

Comment 4 Clark Williams 2013-09-04 21:00:14 UTC
I'll look at dropping/restoring privs during the call to repoquery

Comment 5 Clark Williams 2013-09-05 18:27:48 UTC
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?

Comment 6 Clark Williams 2013-10-23 15:15:32 UTC
queued for 1.34 release

Comment 7 Fedora Update System 2013-10-30 14:57:32 UTC
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

Comment 8 Fedora Update System 2013-10-30 14:59:28 UTC
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

Comment 9 Fedora Update System 2013-10-30 15:01:40 UTC
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

Comment 10 Fedora Update System 2013-10-30 15:04:02 UTC
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

Comment 11 Fedora Update System 2013-10-30 17:12:03 UTC
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).

Comment 12 Fedora Update System 2013-11-05 05:31:59 UTC
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

Comment 13 Fedora Update System 2013-11-05 05:33:55 UTC
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

Comment 14 Fedora Update System 2013-11-05 05:35:14 UTC
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

Comment 15 Fedora Update System 2013-11-05 05:36:31 UTC
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

Comment 16 Fedora Update System 2013-11-10 06:36:38 UTC
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.

Comment 17 Fedora Update System 2014-02-06 02:09:22 UTC
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

Comment 18 Fedora Update System 2014-02-06 02:11:04 UTC
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

Comment 19 Fedora Update System 2014-02-06 02:12:33 UTC
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

Comment 20 Fedora Update System 2014-02-08 05:03:05 UTC
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.

Comment 21 Fedora Update System 2014-03-25 20:25:18 UTC
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

Comment 22 Fedora Update System 2014-03-25 20:27:42 UTC
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

Comment 23 Fedora Update System 2014-03-25 20:29:42 UTC
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

Comment 24 Fedora Update System 2014-03-27 17:48:18 UTC
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

Comment 25 Fedora Update System 2014-03-27 17:50:12 UTC
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

Comment 26 Fedora Update System 2014-03-27 17:52:03 UTC
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

Comment 27 Fedora Update System 2014-03-31 19:04:59 UTC
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

Comment 28 Fedora Update System 2014-03-31 19:07:14 UTC
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

Comment 29 Fedora Update System 2014-03-31 19:09:13 UTC
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

Comment 30 Dan Callaghan 2014-03-31 23:18:34 UTC
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?

Comment 31 Clark Williams 2014-04-03 15:08:44 UTC
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.

Comment 32 Fedora Update System 2014-04-09 13:19:16 UTC
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.

Comment 33 Fedora Update System 2014-04-18 15:38:10 UTC
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.

Comment 34 Fedora Update System 2014-04-19 09:20:27 UTC
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.

Comment 35 Dan Callaghan 2014-04-28 23:24:14 UTC
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'

Comment 36 Jason Bradley Nance 2014-05-15 19:52:28 UTC
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.

Comment 37 Miroslav Suchý 2014-11-20 13:31:01 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.