Description of problem: Trying to build anything with rawhide i386 using mock locally results in failure due to tar being unable to set timestamps of extracted files, e.g. Finish: build setup for perl-Perl6-Caller-0.100-18.fc30.src.rpm Start: rpmbuild perl-Perl6-Caller-0.100-18.fc30.src.rpm Building target platforms: i686 Building for target i686 setting SOURCE_DATE_EPOCH=1573084800 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.eR7R1s + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf Perl6-Caller-0.100 + /usr/bin/tar -xof - + /usr/bin/gzip -dc /builddir/build/SOURCES/Perl6-Caller-0.100.tar.gz /usr/bin/tar: Perl6-Caller-0.100/Build.PL: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/Changes: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/Makefile.PL: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/MANIFEST: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/META.yml: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/README: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/lib/Perl6/Caller.pm: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/lib/Perl6: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/lib: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/t/00-load.t: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/t/10-caller.t: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/t: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/xt/pod-coverage.t: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/xt/pod.t: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100/xt: Cannot utime: Operation not permitted /usr/bin/tar: Perl6-Caller-0.100: Cannot utime: Operation not permitted /usr/bin/tar: Exiting with failure status due to previous errors error: Bad exit status from /var/tmp/rpm-tmp.eR7R1s (%prep) Version-Release number of selected component (if applicable): glibc-2.30.9000-17.fc32 How reproducible: Every time for me (F-30 x86_64 builder), but not seeming to affect koji builds? Excluding glibc-2.30.9000-17.fc32 so that mock picks up glibc-2.30.9000-16.fc32 from a local mirror I have makes this problem go away for me. Any ideas why this might be affecting me but not builds in koji?
I think this is a broken seccomp filter in systemd-nspawn. See bug 1769299, which is a similar issue.
Did glibc change the details of utime implementation? systemd-nspawn allows utime and friends by default. $ systemd-analyze syscall-filter @file-system|grep utime futimesat utime utimensat utimes
FWIW, perl-Perl6-Caller builds fine in mock here with glibc-2.30.9000-17.fc32.x86_64. But I have fairly old hardware, e.g. it doesn't support pkeys. I'm not saying that it's relevant, but it might be, if #1769299 is actually related.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #2) > Did glibc change the details of utime implementation? Yes, because utime is an obsolete system call. The current kernel interface is utimensat_time64. New 32-bit architectures do not even provide the utime system call. (In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > But I have fairly old hardware, e.g. it doesn't support pkeys. I'm not > saying that it's > relevant, but it might be, if #1769299 is actually related. The failure is visible with and without pkeys because applications expect ENOSYS and apply a fallback, but not EPERM. glibc will use utime if utimensat_time64 fails with ENOSYS, but not in the case of EPERM.
https://github.com/systemd/systemd/pull/13975
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > FWIW, perl-Perl6-Caller builds fine in mock here with > glibc-2.30.9000-17.fc32.x86_64. My failing builds were on i386 because they're using the koji buildroot and picked up the updated glibc, which isn't in my mirror for x86_64 yet. Is there something I can add in a systemd unit file to allow the additional system calls when mock (or anyone else) calls nspawn (as a workaround)?
mock doesn't use a unit file I think. Adding --system-call-filter=utimensat_time64 in config_opts['nspawn_args'] in /etc/mock/site-defaults.cfg should work.
I suppose you could tweak mock with these options: # Mock uses systemd-nspawn(1) by default. When use_nspawn is set to False, # simple os.chroot() is used instead. # config_opts['use_nspawn'] = True # Additional args for nspawn # config_opts['nspawn_args'] = ['--capability=cap_ipc_lock'] You probably have to switch to chroot mode because of this: “ Note that systemd-nspawn always implements a system call whitelist (as opposed to a blacklist), and this command line option hence adds or removes entries from the default whitelist, depending on the "~" prefix. ” So there does not seem to be a way to enable system calls that systemd-nspawn knows nothing about. 8-(
*** Bug 1771319 has been marked as a duplicate of this bug. ***
We have a related problem in Python. https://bugs.python.org/issue38692#msg357054 https://bugzilla.redhat.com/show_bug.cgi?id=1774417#c2 Is there a way to adapt the mock config to permit pidfd_open? I've tried to put this to my ~/.config/mock.cfg: config_opts['nspawn_args'] = ['--capability=cap_ipc_lock', '--system-call-filter=pidfd_open'] But it didn't help.
(In reply to Miro Hrončok from comment #10) > We have a related problem in Python. > > https://bugs.python.org/issue38692#msg357054 > https://bugzilla.redhat.com/show_bug.cgi?id=1774417#c2 > > Is there a way to adapt the mock config to permit pidfd_open? > > I've tried to put this to my ~/.config/mock.cfg: > > config_opts['nspawn_args'] = ['--capability=cap_ipc_lock', > '--system-call-filter=pidfd_open'] > > But it didn't help. Switching to chroot mode should help. systemd-nspawn in its current state is not useful for building packages. I will file a mock bug requesting this change.
> Switching to chroot mode should help. It does.
cap_ipc_lock is necessary to call mlock() above the limit specified with ulimit -l. Giving that privilege to the container payload would amount to allowing it to lock the host machine. I don't think this is a good idea. I would expect that the python test suite can pass with the default locked memory limit in place. pidfd_open is a new syscall that needed to be added to a whitelist, and it is now allowed with systemd-234.4-1-fc31. Does the build still fail with the updated systemd?
> Does the build still fail with the updated systemd? Yes.
This also needs an updated libseccomp. I started a build for rawhide and F31 now.
FEDORA-2019-bdf85066b7 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bdf85066b7
libseccomp-2.4.2-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-bdf85066b7
libseccomp-2.4.2-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
When I originally raised this bug I set the release to Rawhide because I thought it was an issue with the glibc update in Rawhide affecting mock builds. Since it's actually an issue with the build environment, this F-31 update is not going to fix things for me because I'm still on F-30 at the moment. At least I have the workaround of not using nspawn.