Description of problem:
It has been a while since I ran mock to test some fedora package builds. I think It was August/September. since then I have updated both the host OS (including kernel) as well as the software on the container (where mock is installed)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install a fedora pakcager dev environment under a openvz VM (aka linux container)
2. try to run mock
DEBUG: Unsharing. Flags: 738328576
DEBUG: unshare(738328576) failed, falling back to unshare(67239936)
DEBUG: Unsharing. Flags: 67239936
ERROR: Namespace unshare failed.
successful mock run
Unfortunately I don't know if it was the kernel update or mock that caused the issue. I did a bunch of digging and didn't see anything in openvz bugzilla, RH bugzilla, mock and kernel release notes. Not finding anything on the unshare flags and if I can tune them via a mock config value
Following change is required to run mock in OpenVZ:
sed -i 's/|mockbuild.util.CLONE_NEWUTS//g' /usr/sbin/mock
As it doesn't seem to be critical this flag can probably be moved to extended_unshare_flags.
thank you very much. that worked great as a workaround.
Been a while sicne I used actual sed, was before GNU added the -i flag. was actually one of the big pushes for me to move to perl years ago for my admin editing (perl's -i flag)
FYI, If I move the flag to the extended_unshare_flags, it works as well. a diff for that change:
--- /tmp/mock 2013-01-17 09:52:07.000000000 -0800
+++ /usr/sbin/mock 2013-01-17 11:47:59.000000000 -0800
@@ -760,8 +760,8 @@
os.environ["HOME"] = chroot.homedir
# New namespace starting from here
- base_unshare_flags = mockbuild.util.CLONE_NEWNS|mockbuild.util.CLONE_NEWUTS
- extended_unshare_flags = base_unshare_flags|mockbuild.util.CLONE_NEWPID|mockbuild.util.CLONE_NEWIPC
+ base_unshare_flags = mockbuild.util.CLONE_NEWNS
+ extended_unshare_flags = base_unshare_flags|mockbuild.util.CLONE_NEWPID|mockbuild.util.CLONE_NEWIPC|mockbuild.util.CLONE_NEWUTS
except mockbuild.exception.UnshareFailed, e:
what kernel were you running on that failed with CLONE_NEWUTS?
Well that's odd. CLONE_NEWUTS was added back in 2006, three years before 2.6.32 was released. Does your kernel not have CONFIG_UTS_NS turned on?
I can move CLONE_NEWUTS to the extended flags but it seems odd that your kernel doesn't have it turned on.
From reading the docs on CLONE_NEWUTS, it sounds like it is what a container itself would use and since I am already running mock inside of an openvz container would that still be legal to do?
Created attachment 691288 [details]
move CLONE_NEWUTS from base flags to extended flags
I've got this patch in my current tree but I haven't tried it on older kernels yet. Please verify that it fixes your issues and it will go into the next mock release.
(In reply to comment #6)
> OpenVZ: 2.6.32-042stab068.8
> From reading the docs on CLONE_NEWUTS, it sounds like it is what a container
> itself would use and since I am already running mock inside of an openvz
> container would that still be legal to do?
Probably not. I think the patch I just posted will do the trick (It's essentially what Richard did in #c4).
Yup, that looks the same as what I did in comment #2.
mock-1.1.29-1.fc17 has been submitted as an update for Fedora 17.
mock-1.1.29-1.el6 has been submitted as an update for Fedora EPEL 6.
mock-1.1.29-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mock-1.1.29-1.el6'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
mock-1.1.29-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.29-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.