Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: There is an error "error: unpacking of archive failed on file /usr/bin/newgidmap;5d4993be: cpio: cap_set_file" when installing shadow-utils package on fedora:31 (rawhide) container. ``` Upgrading : shadow-utils-2:4.6-15.fc31.armv7hl 82/376 Error unpacking rpm package shadow-utils-2:4.6-15.fc31.armv7hl error: unpacking of archive failed on file /usr/bin/newgidmap;5d4993be: cpio: cap_set_file ``` Version-Release number of selected component (if applicable): shadow-utils-2:4.6-15.fc31.armv7hl How reproducible: Steps to Reproduce: 1. Prepare below Dockerfile. ``` $ cat Dockerfile FROM registry.fedoraproject.org/fedora:31-armhfp RUN uname -m RUN rpm -q rpm --qf "%{arch}\n" RUN ARCH=$(rpm -q rpm --qf "%{arch}") && \ dnf -y --forcearch "${ARCH}" upgrade && \ dnf -y --forcearch "${ARCH}" install shadow-utils ``` 2. sudo dnf install qemu-user-static 3. podman build --rm -t my-fedora . Actual results: The installation is failed with below error message. ``` ... Upgrading : filesystem-3.12-2.fc31.armv7hl 15/376 Error unpacking rpm package filesystem-3.12-2.fc31.armv7hl error: unpacking of archive failed on file /proc: cpio: chown ... Upgrading : shadow-utils-2:4.6-15.fc31.armv7hl 82/376 Error unpacking rpm package shadow-utils-2:4.6-15.fc31.armv7hl error: unpacking of archive failed on file /usr/bin/newgidmap;5d4993be: cpio: cap_set_file ... Failed: filesystem-3.12-2.fc31.armv7hl shadow-utils-2:4.6-15.fc31.armv7hl Error: Transaction failed Error: error building at STEP "RUN ARCH=$(rpm -q rpm --qf "%{arch}") && dnf -y --forcearch "${ARCH}" upgrade && dnf -y --forcearch "${ARCH}" install shadow-utils": error while running runtime: exit status 1 ``` Expected results: The installation is succeeded. Additional info: This issue might happen on f30 or f29 and other architectures too. Other cases of the issue. https://travis-ci.org/junaruga/fedora-workshop-multiarch/jobs/568380684 > Failed: > shadow-utils-2:4.6-15.fc31.armv7hl Fedora 29 https://travis-ci.org/multiarch/fedora/jobs/552890901 > Failed: > shadow-utils-2:4.6-4.fc29.ppc64le Thanks for your help!
What kernel is the host running on? I do not think this is a bug in the package but rather the host kernel is something very old not supporting file setcaps or so.
My host's kernel is this version. ``` $ uname -r 5.1.18-300.fc30.x86_64 ```
Hmm is that a supported use-case to install armv7hl into a container on x86_64 host? The container won't be able to run anyway.
Dan Horák told me that this is using qemu-user to run. I suppose the bug should be reassigned there.
Yes, the use case is on QEMU (qemu-user). Before using my reproducer's Dockerfile, you can check if the arch container work on your environment, by below commands. ``` $ sudo dnf install qemu-user-static `` or if you already installed, then it does not work, ``` $ sudo systemctl restart systemd-binfmt ``` ``` $ cat /proc/sys/fs/binfmt_misc/qemu-arm enabled interpreter /usr/bin/qemu-arm-static flags: F offset 0 magic 7f454c4601010100000000000000000002002800 mask ffffffffffffff00fffffffffffffffffeffffff $ uname -m x86_64 $ podman run --rm -t registry.fedoraproject.org/fedora:31-armhfp uname -m armv7l ```
Most likely it's an emulation problem for things around capabilities, there is no such problem when run natively on armv7 (in a container I mean).
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
I'd say this is not really a bug in qemu, but a bug in rpm/dnf if the host does not support setting file capabilities. This is most easily reproduced in a podman container, which does not have CAP_SETPCAP (by default): $ podman run -it --rm fedora:rawhide bash -i and inside the container: dnf install --release=$(. /etc/os-release; echo $VERSION_ID) --installroot /tmp/test shadow-utils It fails with Installing : shadow-utils-2:4.8.1-4.fc33.x86_64 31/31 Error unpacking rpm package shadow-utils-2:4.8.1-4.fc33.x86_64 Running scriptlet: filesystem-3.14-3.fc33.x86_64 31/31 error: unpacking of archive failed on file /usr/bin/newgidmap;5f7aa891: cpio: cap_set_file error: shadow-utils-2:4.8.1-4.fc33.x86_64: install failed Running scriptlet: shadow-utils-2:4.8.1-4.fc33.x86_64 31/31
Reassigning to rpm because the message "...: cpio: cap_set_file" comes from RPM's internal cpio implementation. As to what to do about it, that's less clear. Ignoring the error / turning it into a warning is possible, but then you'll end up with files that are supposed to have capabilities not being labelled. In this case newgidmap has %caps(cap_setgid=ep). Presumably newgidmap doesn't work without this label. Or we could have an RPM/librpm option to turn this into a warning or disable capabilities, but that pushes the problem to all RPM users. In particular it would presumably be difficult to set this flag when using RPM from within another tool like DNF, mock, etc.
Well, ideally rpm would interrogate each filesystem involved for the features needed in a given transaction and bail out without starting at all in such a case, unless an explicit disabler for the feature is used. Much easier said than done though.
It's a tricky one. I'd like to add this is not an obscure corner case, we see this error quite frequently, and it is often reported in Bugzilla in different contexts (try search for: "cpio: cap_set_file" site:bugzilla.redhat.com)
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I tested the `registry.fedoraproject.org/fedora:36-armhfp` container from https://registry.fedoraproject.org/repo/fedora/tags/ now on host Fedora 36, and I confirmed it works without errors. Because the `dnf -y --forcearch "${ARCH}" install shadow-utils` was just skipped with "Nothing to do."? ``` $ cat /etc/fedora-release Fedora release 36 (Thirty Six) $ uname -m x86_64 $ rpm -q podman podman-4.1.0-1.fc36.x86_64 $ rpm -q qemu-user-static qemu-user-static-6.2.0-10.fc36.x86_64 $ rpm -q rpm rpm-4.17.0-10.fc36.x86_64 $ rpm -q dnf dnf-4.13.0-1.fc36.noarch $ cat Dockerfile FROM registry.fedoraproject.org/fedora:36-armhfp RUN uname -m RUN rpm -q rpm --qf "%{arch}\n" RUN ARCH=$(rpm -q rpm --qf "%{arch}") && \ dnf -y --forcearch "${ARCH}" upgrade && \ dnf -y --forcearch "${ARCH}" install shadow-utils ``` ``` $ podman build --rm -t my-fedora . ... Complete! Last metadata expiration check: 0:04:04 ago on Thu Jun 2 17:17:34 2022. Package shadow-utils-2:4.11.1-2.fc36.armv7hl is already installed. Dependencies resolved. Nothing to do. Complete! COMMIT my-fedora --> a08c9e7c94f Successfully tagged localhost/my-fedora:latest a08c9e7c94fff9821e17d2e65d2199f04e3545ef99fa36d7f038aa8fb9c8a13d $ podman run --rm -it my-fedora bash [root@f285d4400b18 /]# uname -m armv7l [root@f285d4400b18 /]# rpm -q shadow-utils shadow-utils-4.11.1-2.fc36.armv7hl [root@f285d4400b18 /]# rpm -q rpm rpm-4.17.0-10.fc36.armv7hl [root@f285d4400b18 /]# rpm -q dnf dnf-4.13.0-1.fc36.noarch ```
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.