Bug 2447287 - Unpacking sources end with "/usr/bin/tar: *: Cannot open: Function not implemented"
Summary: Unpacking sources end with "/usr/bin/tar: *: Cannot open: Function not implem...
Keywords:
Status: CLOSED DUPLICATE of bug 2437037
Alias: None
Product: Fedora
Classification: Fedora
Component: tar
Version: 44
Hardware: aarch64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-03-13 10:19 UTC by Marcin Juszkiewicz
Modified: 2026-03-13 15:54 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-03-13 15:51:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Marcin Juszkiewicz 2026-03-13 10:19:26 UTC
I upgraded my AArch64 system from Fedora 43 to 44 recently. Cannot do any Fedora 44 builds using mock now.

Mock container starts, all build dependencies are installed etc. Then rpmbuild starts unpacking sources and fails:

```
/usr/bin/tar: linux-6.19.7/virt/kvm/vfio.c: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/kvm/vfio.h: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib: Cannot mkdir: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib/Kconfig: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib/Makefile: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib/irqbypass.c: Cannot open: Function not implemented
/usr/bin/tar: Exiting with failure status due to previous errors
```

Same srpm but for Fedora 43 unpacks fine:

```
+ cd kernel-6.19.7
+ /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/linux-6.19.7.tar.xz
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
```

Reproducible: Always

Steps to Reproduce:
1. fedpkg mockbuild -r fedora-44-aarch64

Actual Results:

```
/usr/bin/tar: linux-6.19.7/virt/kvm/vfio.c: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/kvm/vfio.h: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib: Cannot mkdir: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib/Kconfig: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib/Makefile: Cannot open: Function not implemented
/usr/bin/tar: linux-6.19.7/virt/lib/irqbypass.c: Cannot open: Function not implemented
/usr/bin/tar: Exiting with failure status due to previous errors
```

Expected Results:
```
+ cd kernel-6.19.7
+ /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/linux-6.19.7.tar.xz
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
```

Comment 1 Marcin Juszkiewicz 2026-03-13 10:43:35 UTC
Happens with any package, not only kernel.

And for kernel I can workaround it by building it for Fedora 43.

Comment 2 Pavel Raiskup 2026-03-13 14:28:00 UTC
Mock is using a tooling from the target distribution; namely rpmbuild.fc44 that is using xz.f44 (where I guess happened some change).

Comment 3 Richard W.M. Jones 2026-03-13 14:41:20 UTC
Function not implemented (ENOSYS) may indicate that kernel system calls are being filtered.
Is seccomp involved?  Cgroups / Containers?

The only recent change to xz I'm aware of affects only containers being run on a RHEL 9
kernel (which does not sound like it's involved here).  Also it has a very distinctive
error message, also not seen here.  For reference that would be:
https://bugzilla.redhat.com/show_bug.cgi?id=2407105

Comment 4 Richard W.M. Jones 2026-03-13 14:43:43 UTC
Also can you tell me the exact xz NVR where it was working vs failed, also the
exact kernel version, and any other relevant information about sandboxing, especially
things that might have changed between F43 and F44.

Comment 5 Marcin Juszkiewicz 2026-03-13 14:59:45 UTC
root.log of fc44 failed builds says:

DEBUG util.py:463:  xz-libs-5.8.2-2.fc44.aarch64
DEBUG util.py:463:  xz-5.8.2-2.fc44.aarch64
DEBUG util.py:463:  xz-devel-5.8.2-2.fc44.aarch64

working fc43 build (on same f44 host) says:

DEBUG util.py:463:  xz-libs-5.8.1-4.fc43.aarch64
DEBUG util.py:463:  xz-5.8.1-4.fc43.aarch64
DEBUG util.py:463:  xz-devel-5.8.1-4.fc43.aarch64

Kernel is self-built 6.19.7-300.fc43.pcie65.6.aarch64 (6.19.7 from Fedora kernel/f44 branch + two Ampere PCIE-65 patches, built in fedora-43-aarch64 mock).

Comment 6 Marcin Juszkiewicz 2026-03-13 15:28:02 UTC
tar-1.35-8.fc44.aarch64 vs tar-1.35-6.fc43.aarch64

Comment 7 Richard W.M. Jones 2026-03-13 15:29:06 UTC
I couldn't reproduce this on Fedora 43 / aarch64.  I'm updating my instance to
Fedora 44 now.

What is the version of mock where this fails?

Comment 8 Richard W.M. Jones 2026-03-13 15:30:13 UTC
This sure looks suspicious: https://src.fedoraproject.org/rpms/tar/c/5a186e814f50ab1c905d0d14273abc126e2e9509?branch=rawhide

Comment 9 Marcin Juszkiewicz 2026-03-13 15:30:51 UTC
$ rpm -qa|grep ^mock
mock-filesystem-6.7-1.fc44.noarch
mock-6.7-1.fc44.noarch
mock-core-configs-44.2-1.fc44.noarch

Comment 10 Pavel Cahyna 2026-03-13 15:42:16 UTC
Hi @mjuszkie 

are you using nspawn option --suppress-sync=yes ? If so, try removing it from Mock config. Please see bz2437037, in particular https://bugzilla.redhat.com/show_bug.cgi?id=2437037#c3 .

Comment 11 Richard W.M. Jones 2026-03-13 15:44:11 UTC
So we believe this works with tar on Fedora 43, and fails starting with tar on Fedora 44.
tar on Fedora 44 contains the openat2 patch (see above).  However it might still be
something else that is filtering out the openat2 system call, rather than a problem
with tar itself.

Comment 12 Pavel Cahyna 2026-03-13 15:50:45 UTC
Another thought: is your AArch64 virtualized? There was a related bug in Qemu : https://gitlab.com/qemu-project/qemu/-/work_items/3262

Comment 13 Marcin Juszkiewicz 2026-03-13 15:51:52 UTC

*** This bug has been marked as a duplicate of bug 2437037 ***

Comment 14 Marcin Juszkiewicz 2026-03-13 15:52:40 UTC
Thanks Richard and Pavel for help - it was mock option.

Pavel: no, it is bare-metal host.

Comment 15 Pavel Cahyna 2026-03-13 15:54:14 UTC
Thank you Marcin for the quick confirmation!


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