Bug 1447627 - mock --installdeps or --install can't find rpm to install with --bootstrap-chroot
Summary: mock --installdeps or --install can't find rpm to install with --bootstrap-ch...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1452902 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-03 11:04 UTC by Marius Vollmer
Modified: 2019-11-17 04:26 UTC (History)
13 users (show)

Fixed In Version: mock-1.4.21-1.fc31 mock-1.4.21-1.fc30 mock-1.4.21-1.fc29 mock-1.4.21-1.el8 mock-1.4.21-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 04:15:12 UTC
Type: Bug


Attachments (Terms of Use)
Full log (30.04 KB, text/plain)
2017-05-03 11:04 UTC, Marius Vollmer
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1118719 'low' 'CLOSED' '[RFE] Use of different version of RPM than the system one' 2019-11-25 07:06:15 UTC

Internal Links: 1118719 1578942

Description Marius Vollmer 2017-05-03 11:04:22 UTC
Created attachment 1275873 [details]
Full log

Description of problem:

# rpmquery -p ./cockpit-138.x-1.wip.fc25.src.rpm
cockpit-138.x-1.wip.fc25.x86_64

# mock --clean
# mock --verbose --installdeps ./cockpit-138.x-1.wip.fc25.src.rpm
[...]
[Errno 2] No such file or directory: './cockpit-138.x-1.wip.fc25.src.rpm'

Version-Release number of selected component (if applicable):
mock-1.4.1-1.fc26.noarch

Comment 1 Vít Ondruch 2017-05-03 15:51:21 UTC
I've got similar issue. Trying to install the build result into the buildroot:

~~~
$ mock -r fedora-rawhide-x86_64 --offline -i /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm

... snip ...

Can not load RPM file: /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm.
Could not open: /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm
ERROR: Command failed: 
 # /usr/bin/systemd-nspawn -q -M 00eb4933abce482f881ca683351bd53b -D /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root -a --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$  --setenv=LANG=cs_CZ.utf8 --setenv=LC_MESSAGES=C --setenv=LD_PRELOAD=/var/tmp/tmp.mock.qoq2oou5/$LIB/nosync.so /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 27 -C --disableplugin=local --setopt=deltarpm=false install /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm
~~~

Obviously the boostrap buildroot doesn't have access to the outer world, so this fails.

Comment 2 Marius Vollmer 2017-05-04 07:12:00 UTC
Switching off systemd-nspawn doesn't seem to make any difference, although I had expected it to...

Comment 3 Marius Vollmer 2017-05-04 07:14:16 UTC
This workaround seems to work:

srpm=cockpit-138.x-1.wip.fc25.src.rpm

mock --clean
mock --init

root=/var/lib/mock/fedora-26-x86_64-bootstrap/root
mkdir -p "$root/$PWD"
cp "$srpm" "$root/$PWD/"

mock --installdeps "$PWD/$srpm"

Comment 4 Vít Ondruch 2017-05-04 07:22:18 UTC
Actually, you can disable the "bootstrap" thingy either by `--no-bootstrap-chroot` command line option or set:

```
    config_opts['use_bootstrap_container'] = False
``` 

in your mock config.

Comment 5 Marius Vollmer 2017-05-04 11:39:22 UTC
(In reply to Vít Ondruch from comment #4)
> Actually, you can disable the "bootstrap" thingy either by
> `--no-bootstrap-chroot` command line option or set:
> 
> ```
>     config_opts['use_bootstrap_container'] = False
> ``` 
> 
> in your mock config.

Thanks, that works as well and is of course much cleaner as a workaround.

Would it make sense to disable the bootstrap chroot by default, until it works?

Comment 6 James Hogarth 2017-05-12 21:17:07 UTC
Urgh I wondered why my mockchain and mock -i attempts were failing on trying to build a package with dependencies ...

Downgraded to 1.3.4 and it was fine ...

This was causing me pain in doing a review too ...

I've manually put that in all my mock configuration files for now.

I agree that really the bootstrap chroot needs to be set to False until it works to install packages in the mock chroot.

I've updated the subject to make it clear it affects --install as well so it's easier for the next person to find :)

Comment 7 Vít Ondruch 2017-05-22 10:57:47 UTC
*** Bug 1452902 has been marked as a duplicate of this bug. ***

Comment 8 Vít Ondruch 2017-09-05 07:17:08 UTC
BTW I have this repo configured to be able to consume the build output immediately into the mock:

~~~
... snip ...

config_opts['plugin_conf']['sign_enable'] = True
config_opts['plugin_conf']['sign_opts'] = {}
config_opts['plugin_conf']['sign_opts']['cmd'] = 'createrepo_c'
config_opts['plugin_conf']['sign_opts']['opts'] = '-o %(resultdir)s %(resultdir)s'

... snip ...

[result]
name=result
baseurl=file:///var/lib/mock/ruby/result
enabled=1
skip_if_unavailable=1
metadata_expire=0
cost=1

... snip ...
~~~

and obviously neither this works ...

Comment 9 Miroslav Suchý 2018-02-22 15:39:26 UTC
Duplicate on github with some more info:
https://github.com/rpm-software-management/mock/issues/72

Comment 10 Fedora End Of Life 2018-05-03 08:29:20 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 11 Vít Ondruch 2018-05-03 08:53:25 UTC
I don't think this has been addressed.

Comment 12 Klaus Wenninger 2018-05-11 09:27:28 UTC
Most of these 'access to local rpm'-issues should be able to be addressed via the bind_mount-plugin.
Of course it would be favorable not to have to create these mounts manually but having them setup automatically at least in some situations where it is obvious for mock what has to be done.

Anyway there is still an issue that stays:

If you want to install local rpms during bootstrapping that will still fail as the bind-mounts are not gonna be setup then.
https://github.com/rpm-software-management/mock/pull/184
tries to address this issue.

Unfortunately the workaround mentioned - disabling the container - isn't applicable in situations when building on a yum-based release/distribution for a more modern dnf-based release/distribution that has rpms that aren't compatible with yum anymore.

Comment 13 Orion Poplawski 2018-06-20 04:41:59 UTC
I'm running into this as well.

Comment 14 Klaus Wenninger 2018-06-20 05:58:35 UTC
(In reply to Orion Poplawski from comment #13)
> I'm running into this as well.

Meanwhile this bz has a list of similar issues that all have to do with the lack of being able to access the local filesystem from inside the systemd-container.
Which one are you running into?
Are you in a situation where disabling the container-build is applicable (and solves the issue)?

Comment 15 Orion Poplawski 2018-06-20 15:51:55 UTC
I cannot install local rpms into the buildroot.  I need bootstrap-chroot because I'm building for Rawhide on EL7.

Comment 16 Klaus Wenninger 2018-06-20 16:11:16 UTC
(In reply to Orion Poplawski from comment #15)
> I cannot install local rpms into the buildroot.  I need bootstrap-chroot
> because I'm building for Rawhide on EL7.

Yep that is my scenario as well.
My pull-request referenced above should work for you and it would of course be cool if you find the time to make it recognize the file:// references automatically so that you don't have to manually create the bind-mount specifications.
But I personally would still keep the possibility to specify bind-mounts that are effective in the bootstrap as well manually. In my case for instance all the local repos are in one subtree so that it is sufficient to bindmount the top-level directory into the container.

Comment 17 Jan Kurik 2018-08-14 10:19:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 18 Orion Poplawski 2018-10-07 19:29:18 UTC
My current workaround is to copy the rpms first to the boostrap root builddir, e.g.: /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/builddir/ and then use the /builddir/ patch to the rpms.

Comment 19 Laszlo Ersek 2019-02-13 17:39:52 UTC
I'm affected too. I have the exact same use case as described in comments 12 through 15. I need to build in a Fedora 28 mock environment on RHEL 7, and that doesn't work without a bootstrap chroot (see bug 1578942 comment 0). I'll try to use the "manually copy the SRPM into the bootstrap chroot" workaround.

Comment 20 Klaus Wenninger 2019-02-13 17:53:01 UTC
(In reply to Laszlo Ersek from comment #19)
> I'm affected too. I have the exact same use case as described in comments 12
> through 15. I need to build in a Fedora 28 mock environment on RHEL 7, and
> that doesn't work without a bootstrap chroot (see bug 1578942 comment 0).
> I'll try to use the "manually copy the SRPM into the bootstrap chroot"
> workaround.

As an alternative you can give this a try:
https://github.com/rpm-software-management/mock/pull/184

Didn't have the time to make it more user-friendly but maybe still better
than other solutions.

Comment 21 Laszlo Ersek 2019-02-13 18:05:37 UTC
The workaround in comment 3 doesn't function for me. Even though I run both the mkdir and cp commands, and make sure the file is referenced by the correct pathname in the bootstrap chroot, the "dnf builddep" command, launched by systemd-nspawn, cannot find the file, when invoked from "mock --installdeps".

Comment 22 Laszlo Ersek 2019-02-13 18:08:19 UTC
Klaus, re: comment 20, thanks for the suggestion, but for this use case I can't consume anything that's not in EPEL7 or RHEL7.

My next approach will be:
- disable the bootstrap container again
- replace the "mock --installdeps" command with "mock --chroot", and in
  the normal (build) chroot environment, install dnf, plus run "dnf
  builddep", manually

Comment 23 Laszlo Ersek 2019-02-13 18:27:07 UTC
Nah, doesn't work; without the bootstrap container, the process breaks almost immediately due to bug 1578942.

Comment 24 Laszlo Ersek 2019-02-13 20:11:19 UTC
The following *does* work however:

MOCK_CONF=fedora-28-x86_64
MOCK="mock -r $MOCK_CONF"
MOCK="$MOCK --config-opts=use_bootstrap_container=True"
MOCK="$MOCK --config-opts=rpmbuild_networking=True"

$MOCK --copyin -- "$SRPM_DIR/$SRPM_NAME" /
$MOCK --install dnf dnf-plugins-core
$MOCK --chroot -- dnf builddep "/$SRPM_NAME"
$MOCK --chroot -- rpm -i -v -h "/$SRPM_NAME"
$MOCK --chroot -- rpmbuild -bp "$MOCK_RPM_ROOT/SPECS/foobar.spec"

(For my use case, only the %prep stage is necessary.)

In other words,
- the bootstrap container is enabled, working around bug 1578942,
- the SRPM is copied into the *build* (not bootstrap) environment,
- the "--installdeps" mock action is replaced with
  - the "--install" action on "dnf" and "dnf-plugins-core"
    (note that for this, networking in the bootstrap container must be enabled!),
  - manual invocation of "dnf builddep" on the SRPM file in the *build* env.

Thanks.

Comment 25 Pavel Raiskup 2019-10-10 08:34:50 UTC
PR: https://github.com/rpm-software-management/mock/pull/372

Can be tested with mock-1.4.20-1.git.7.e59e7e9 from:
$ dnf copr enable praiskup/mock-fixes

Comment 26 Ben Cotton 2019-10-31 18:46:57 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 27 Fedora Update System 2019-11-01 14:15:59 UTC
FEDORA-2019-ad7ecf205b has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ad7ecf205b

Comment 28 Fedora Update System 2019-11-01 14:16:07 UTC
FEDORA-EPEL-2019-0549ec172d has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0549ec172d

Comment 29 Fedora Update System 2019-11-01 14:16:09 UTC
FEDORA-EPEL-2019-3687ce895a has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3687ce895a

Comment 30 Fedora Update System 2019-11-01 14:16:15 UTC
FEDORA-2019-755583cbdf has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-755583cbdf

Comment 31 Fedora Update System 2019-11-02 02:26:39 UTC
mock-1.4.21-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c6079af90e

Comment 32 Fedora Update System 2019-11-02 02:38:54 UTC
mock-1.4.21-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0549ec172d

Comment 33 Fedora Update System 2019-11-02 04:09:44 UTC
mock-1.4.21-1.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3687ce895a

Comment 34 Fedora Update System 2019-11-02 04:13:29 UTC
mock-1.4.21-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ad7ecf205b

Comment 35 Fedora Update System 2019-11-03 06:01:28 UTC
mock-1.4.21-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-755583cbdf

Comment 36 Fedora Update System 2019-11-05 04:15:12 UTC
mock-1.4.21-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 37 Fedora Update System 2019-11-06 12:50:43 UTC
mock-1.4.21-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 38 Fedora Update System 2019-11-10 01:07:06 UTC
mock-1.4.21-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 39 Fedora Update System 2019-11-17 04:22:42 UTC
mock-1.4.21-1.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report.

Comment 40 Fedora Update System 2019-11-17 04:26:26 UTC
mock-1.4.21-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.


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