3 weeks ago, before I went on holiday, I could debug build problems by
logging into my koji build server and get into the mock chroot with
something like

su - kojibuilder -c "mock -v -r koji/slsbox-1.1-build-186-252 --shell"

Now when I try it, it fails with

Traceback (most recent call last):
File "/usr/sbin/mock", line 881, in <module>
main(retParams)
File "/usr/sbin/mock", line 759, in main
sys.exit(chroot.shell(options, cmd))
File "/usr/lib/python2.6/site-packages/mockbuild/backend.py", line 682,
in shell
cmd=cmd)
File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 402, in
doshell
return subprocess.call(cmdstr, preexec_fn=preexec, env=environ,
shell=True)
File "/usr/lib64/python2.6/subprocess.py", line 478, in call
p = Popen(*popenargs, **kwargs)
File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

I've done a mock clean and mock init, and the same thing happens. Anyone
seen anything like that before?


Moray.
"To err is human; to purr, feline."





--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On 05/25/2012 12:21 PM, Moray Henderson wrote:

3 weeks ago, before I went on holiday, I could debug build problems by
logging into my koji build server and get into the mock chroot with
something like

su - kojibuilder -c "mock -v -r koji/slsbox-1.1-build-186-252 --shell"

Now when I try it, it fails with


So mock init succeeds, but mock --shell fails? Perhaps the chroot is
lacking /bin/bash. Have you looked? Were there any unusual errors in
root.log?



Traceback (most recent call last):
File "/usr/sbin/mock", line 881, in<module>
main(retParams)
File "/usr/sbin/mock", line 759, in main
sys.exit(chroot.shell(options, cmd))
File "/usr/lib/python2.6/site-packages/mockbuild/backend.py", line 682,
in shell
cmd=cmd)
File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 402, in
doshell
return subprocess.call(cmdstr, preexec_fn=preexec, env=environ,
shell=True)
File "/usr/lib64/python2.6/subprocess.py", line 478, in call
p = Popen(*popenargs, **kwargs)
File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

I've done a mock clean and mock init, and the same thing happens. Anyone
seen anything like that before?

--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

> -----Original Message-----
> From: Mike McLean [mailto:mikem@redhat.com]
> Sent: 29 May 2012 17:03
>
> On 05/25/2012 12:21 PM, Moray Henderson wrote:
> > 3 weeks ago, before I went on holiday, I could debug build problems
> by
> > logging into my koji build server and get into the mock chroot with
> > something like
> >
> > su - kojibuilder -c "mock -v -r koji/slsbox-1.1-build-186-252 --
> shell"
> >
> > Now when I try it, it fails with
>
> So mock init succeeds, but mock --shell fails? Perhaps the chroot is
> lacking /bin/bash. Have you looked? Were there any unusual errors in
> root.log?

I think that it was Koji housekeeping removing the mock root as fast as I was building it. Do mock roots with failed builds last longer than successful ones? I never had this problem going into a mock root to investigate a failed build, but when I try to reinitialize an older root - even when the mock config is still available - Koji seems to find it and remove it almost immediately.

The "error" in root.log I was trying to investigate was "Could not downgrade policy file /etc/selinux/targeted/policy/policy.24" from SELinux. Looks like that is not really an error, just what happens when Policy is loaded while SELinux is disabled.


Moray.
“To err is human; to purr, feline.�







--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On 05/30/2012 08:14 AM, Moray Henderson wrote:

I think that it was Koji housekeeping removing the mock root as fast
as I was building it. Do mock roots with failed builds last longer
than successful ones? I never had this problem going into a mock
root to investigate a failed build, but when I try to reinitialize an
older root - even when the mock config is still available - Koji
seems to find it and remove it almost immediately.


Yes. successful buildroots are cleared almost immediately. Failed ones
remain for 4 hours by default. The mock configs remain for 24 hours, as
do the top level buildroot dirs[*]


For buildroots of successful tasks, I recommend replicating the
buildroot, by either:


1) Generate a new config with a command like:

koji mock-config --task X myroot

and use that config with mock

2) If the mock config generated by koji is still around, *copy* it
elsewhere (under /etc/mock rather than /etc/mock/koji, preferably change
the name). Also *edit* it to remove the commented metadata left by koji
at the beginning and change the "config_opts['root']" line to a
different string.


These steps will prevent kojid from removing (or even noticing) your
buildroot. As such, you will want to remember to clear it yourself when
finished.


[*] this is a workaround for a very nasty bug in older versions of rpm:
https://bugzilla.redhat.com/show_bug.cgi?id=192153
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys