(In reply to Vít Ondruch from comment #0)

> no idea why this happens on my system while it seems that there are not
> issues in e.g. Koji

Anything special about your system? Do you run it e.g. inside Qemu or another virtualization?

It is Rawhide, but other than that, nothing I can think of. BTW this is where my mock configuration differs to default:

~~~
$ cat ~/.config/mock.cfg 
# By default a Yum/DNF update is performed before each rebuild
config_opts['update_before_build'] = False
# Prevent updates.
# https://github.com/rpm-software-management/mock/issues/701
config_opts['dnf_builddep_opts'] = ['--nobest']

# Sometimes the rpm/yum/dnf ecosystem on the host machine isn't really
# compatible with the rpm/yum/dnf ecosystem in mock chroot (the system we
# build for).  Typically when host is yum-based and target system is dnf-based.
# Such scenario may cause an error when preparing the target mock buildroot, or
# even worse an unexpected install transaction that is hard to detect.
# Therefore, with `use_bootstrap=True` default, we first install a minimal
# "bootstrap" chroot that only contains rpm/yum/dnf stack, and from that
# "bootstrap" chroot we initialize the target chroot.
config_opts['use_bootstrap'] = False

### unbreq plugin
# This plugin is able to detect unused BuildRequires from an RPM build based
# on file accesses during the build. It is disabled by default.
config_opts['plugin_conf']['unbreq_enable'] = True


# If you want to speed up Mock and you do not sync() during %check you can use
# https://github.com/rpm-software-management/mock/pull/1644
config_opts['nspawn_args'] += ['--suppress-sync=yes']
~~~

Or maybe if some env variable is somehow leaking or missing in the mock env. To me it sounds like if the tar was trying to call some shell functions and failed. Not sure ...

I can reproduce it with your config but not without it, which explains why we don't have more complaints like this.

Try commenting out the last line:
config_opts['nspawn_args'] += ['--suppress-sync=yes']

> To me it sounds like if the tar was trying to call some shell functions and failed.

tar certainly does not call shell functions. Those must be syscalls. I suspect it is related to the use of the openat2() syscall in tar starting in the last update.

(In reply to Pavel Cahyna from comment #3)
> I can reproduce it with your config but not without it, which explains why
> we don't have more complaints like this.
> 
> Try commenting out the last line:
> config_opts['nspawn_args'] += ['--suppress-sync=yes']

I suppose it is related to this comment about the use of this option in mock : https://github.com/rpm-software-management/mock/pull/1613#issuecomment-3421908652

"This broke the tests (inside a build) of bootc because the implementation of this in nspawn uses seccomp which defaults to turning off some things, in our case use of openat2(RESOLVE_IN_ROOT)."

Indeed, tar now uses openat2.

Reassigning to systemd, as systemd-nspawn is from this component (the systemd-container subpackage).

@praiskup just FYI if somebody else hits this issue. The '--suppress-sync=yes' feature is essentially unusable now :/

Thanks folks!

I had same option in mock.cfg and had same issue.

*** Bug 2447287 has been marked as a duplicate of this bug. ***